[Bug libc/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes

["tore at fud dot no" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12377

--- Comment #6 from Tore Anderson <tore at fud dot no> 2011-07-08 15:16:58 UTC ---
(In reply to comment #4)
> > From this it is easy to infer the true purpose of AI_ADDRCONFIG - avoid looking
> > up addresses that it is highly unlikely that you can make use of. Loopbacks and
> > link-locals are corner cases since they're always present regardless of
> > external
> > connectivity, and link-locals is even more of a corner-case than loopbacks as
> > a name cannot resolve to a usable link-local address (with an interface id).
> 
> Isn't that why there is the "%ifname" convention for the "name" one is passing
> to getaddrinfo()?  So it can fill-in the desired/required scope?  I have
> distinct recollections of using that frequently with netperf when running IPv6
> tests using link-local addressing (though with IPv6 addrs as strings passing to
> getaddrinfo()).

The %ifname convention has nothing to do with getaddrinfo(), it's interpreted
by the application. When passing it to getaddrinfo() you'll get this result:

tore@wrath:~$ ./gai-test "sourceware.org%eth0"
[         0us] begin gai_and_connect(sourceware.org%eth0)
[+    99007us] getaddrinfo(sourceware.org%eth0) failed: Name or service not
known
[+       18us] socket() failed

Which, on the wire, shows up as:

17:09:57.165199 IP 192.168.1.42.42753 > 195.159.0.100.domain: 26635+ A?
sourceware.org%eth0. (37)
17:09:57.165215 IP 192.168.1.42.42753 > 195.159.0.100.domain: 30258+ AAAA?
sourceware.org%eth0. (37)
17:09:57.185490 IP 195.159.0.100.domain > 192.168.1.42.42753: 26635 NXDomain
0/1/0 (112)
17:09:57.185929 IP 195.159.0.100.domain > 192.168.1.42.42753: 30258 NXDomain
0/1/0 (112)                                                                     

> My situation under Maverick does seem odd.  Running my test program under gdb I
> single-stepped through make_request() and while the "ifam" showed a family of
> 10 (PF_INET6) on some of the passes through the loop looking at the netlink
> returns, it never hit the path that set seen_ipv6 to true.  I pulled the eglibc
> sources and lifted __check_pf() and make_request from them, and after a modicum
> of massaging to get them to compile on their own, a test program calling those
> *did* set seen_ipv6.

Probably the Ubuntu guys have done some patching on their own to get around the
problem with unwanted AAAA lookups hitting broken DNS server.

(In reply to comment #5)
> Perhaps there is different behaviour based on OS X version?
> 
> I put my test program into the hands of some OS X users, and on their systems
> where there were only IPv4 and link-scope IPv6 addresses, the setting of
> AI_ADDRCONFIG did not preclude resolving the likes of "::1" or a link-scope IP
> address (so presumably "::1" was not special cased).  One of them is known to
> be running 10.6.8, the other I don't have their revision information.

I don't have a Mac OS X machine handy right now, but it could be that they only
apply AI_ADDRCONFIG logic when looking up names in DNS, and that any address
found in another name service (such as /etc/hosts) will be returned by
getaddrinfo() regardless of AI_ADDRCONFIG. I know for certain that
AI_ADDRCONFIG will suppress AAAA DNS lookups on Mac OS X if there's only
loopback and link-locals present, though.

Tore

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.