This is the mail archive of the
mailing list for the glibc project.
[Bug libc/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes
- From: "tore at fud dot no" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 8 Jul 2011 15:17:30 +0000
- Subject: [Bug libc/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
--- 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
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
[+ 18us] socket() failed
Which, on the wire, shows up as:
17:09:57.165199 IP 192.168.1.42.42753 > 220.127.116.11.domain: 26635+ A?
17:09:57.165215 IP 192.168.1.42.42753 > 18.104.22.168.domain: 30258+ AAAA?
17:09:57.185490 IP 22.214.171.124.domain > 192.168.1.42.42753: 26635 NXDomain
17:09:57.185929 IP 126.96.36.199.domain > 192.168.1.42.42753: 30258 NXDomain
> 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.
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.