Bug#183814: libc6: getaddrinfo can't parse all forms of numeric ip addresses

[Greg Stark <gsstark@mit.edu>]

Russ Allbery <rra@stanford.edu> writes:

> gsstark <gsstark@mit.edu> writes:
> 
> > Package: libc6
> > Version: 2.3.1-10
> > Severity: normal
> 
> > The test program below shows a limitation of the getaddrinfo function,
> > it doesn't seem to parse numeric ip addresses that aren't formatted
> > using four separate dotted quads. This is a big regression as
> > traditionally this is how lots of networks specified their ip
> > addresses. Most standard programs do support this notation.
> 
> This is the intentional behavior of getaddrinfo according to POSIX as I
> understand it.  All of the new interfaces that were developed as part of
> the IPv6 efforts do not support the legacy IPv4 address formats such as
> omitting octets, specifying octets in octal, specifying octets in
> hexidecimal, specifying IP addresses as decimal numbers, and all the other
> bizarre things that inet_aton used to support.

That makes me sad. 

Actually skimming RFC 2553 (I don't have a copy of the posix spec) the only
description I see of the input is:

>  A non-NULL nodename string can be either a node name or a numeric host
>  address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex
>  address).

"a dotted-decimal IPv4 address" in the most general sense could easily be
taken to mean all the "bizarre" forms I mentioned. In reality they're not so
bizarre and there aren't lots of different variations just one.

Namely, a dotted decimal IPv4 address is a list of 1-4 decimal numbers where
each decimal number is taken to be an octet except for the last which is all
the remaining bits. 

That covers all the cases including the normal case of four dotted octets and
the degenerate case of a single decimal number.

I wonder if someone who has the POSIX spec can see if that change is really
mandated or if it's similarly vague about "a dotted decimal IPv4 address".

--
greg