Re: getaddrinfo(AF_UNSPEC,AI_PASSIVE) result order

[Godmar Back <godmar at gmail dot com>]

As an aside, I'm still left confused as to what the normative behavior
should be.  It's not immediately clear to me that the address
selection mechanism in RFC 3484 applies here (since it's a passive
address selection in preparation of a bind()/accept() call). It's also
not clear that Drepper's description for how one can implement a
single-socket accept on dual-stack machines is normative. Lastly, when
I had this issue, I looked at a few examples of widely used software
(sshd, for instance), and found that none of them relies on the
address order returned. They all do special casing for IPv6 (usually,
checking whether the address returned is an IPv6 address and coding
appropriately).

The interesting consequence would be that (in 2013) it remains tricky
to write portable code that runs on IPv4 only, IPv6 only, and
dual-stack machines; in addition, there appears to be no clear way to
write truly protocol-independent code (something that would work on
IPv8 - I assume they'll skip IPv7 again.)  I'm teaching this stuff,
and it's a bit embarrassing.

FWIW, other OS have similar embarrassments wrt IPv6. In Windows 7, for
instance, the client address selection is broken in that its default
address selection table gives ULA (fc00::/7) addresses a higher
preference than 6to4 (2002::/) addresses, which means that IPv6
doesn't work out of the box if you use a Cisco E4200 router that has
6to4 turned on (and also hands out ULA address to the devices on the
local network). That just as an aside if you ever wonder why your
Linux machines at home have IPv6 connectivity and your Windows boxes
do not.

 - Godmar


On Sat, Jun 8, 2013 at 6:52 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> Thanks for the pointers. So IPv6 address ordering is a known issue (I
> actually have seen it working properly on older glibc, so it's probably a
> regression), and it will be fixed for fedora 19 or soon? Is there a bug
> number so that I track it?
>
>
> Thanks,
> Dimitris
>
>
> On Fri, 7 Jun 2013, Godmar Back wrote:
>
>> See
>>
>> http://sourceware.org/ml/libc-help/2011-12/msg00000.html
>> http://sourceware.org/ml/libc-help/2013-03/msg00002.html
>>
>> On Fri, Jun 7, 2013 at 3:50 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
>>>
>>> Hello list,
>>>
>>> getaddrinfo(AF_UNSPEC, AI_PASSIVE) on my RHEL 6.3 system returns first
>>> 0.0.0.0 and second ::0. However according to RFC 3484, paragraph 10.3:
>>>
>>>     The default policy table gives IPv6 addresses higher precedence than
>>>     IPv4 addresses. This means that applications will use IPv6 in
>>>     preference to IPv4 when the two are equally suitable. An
>>>     administrator can change the policy table to prefer IPv4 addresses by
>>>     giving the ::ffff:0.0.0.0/96 prefix a higher precedence:
>>>
>>> The glibc resolver precedence is changed by tweaking /etc/gai.conf, which
>>> is
>>> empty on this system. As a result my application listens only to IPv4,
>>> even
>>> though IPv6 loopback works as expected:
>>>
>>> # ping6 ::1
>>> PING ::1(::1) 56 data bytes
>>> 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.237 ms
>>>
>>>
>>> What am I missing?
>>>
>>> Thanks,
>>> Dimitris
>>>
>>
>