This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug network/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes
- From: "psimerda at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 31 Jul 2012 15:01:01 +0000
- Subject: [Bug network/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes
- Auto-submitted: auto-generated
- References: <bug-12377-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12377
--- Comment #19 from Pavel Åimerda <psimerda at redhat dot com> 2012-07-31 15:01:01 UTC ---
> > > words, if there is no IPv4 connectivity, avoid making "IN A" lookups.
> >
> > This is exactly what AI_ADDRCONFIG doesn't do.
On my system it edits the list of addresses *after* doing any sort of parsing
and optional lookup. And AF_UNSPEC with AI_ADDRCONFIG without IPv4 and IPv6
connectivity does not do the same thing to IPv6 addresses as with IPv6
connectivity.
I can test this for you when it's fixed. But also *please* document the exact
expected behavior and its purpose in the manpage.
> On my system, it does exactly this on my system. I don't see any IN A queries
> sent to the DNS server when I only have 127.0.0.1 configured on my system, only
> IN AAAA.
If it was only doing this, I would have *no* objections.
> > It breaks various non-DNS cases.
>
> With that I agree completely. I don't see any good reason to apply
> AI_ADDRCONFIG logic in other cases than when using DNS. For what it's worth, I
> believe that Mac OS X still implements getaddrinfo() only when doing forward
> DNS IN A/AAAA lookups (in other words the original RFC 2553 specification). I
> can try to get that confirmed if you're interested.
Then we have a way out. It should be done only for DNS (or for a list of
global-address-only methods that would only include DNS for the beginning).
> > *None* of my objections was DNS-related. All were about either literal
> > addresses, /etc/hosts names or possible link-local NSS plugins.
>
> Ok - I think we're kind of in agreement, then - perhaps talking about two
> different use cases, really. I see AI_ADDRCONFIG as only useful for DNS
> ("forward" DNS, i.e. IN A/IN AAAA). However, in that case, it is also *very*
> useful. However, for it to be useful in the IPv4-only host case (which is
> presently the most important one, given the amount of defective resolvers
> embedded in IPv4-only home gateways that choke on IN AAAA queries), you'll also
> need to disregard the automatically configured link-local IPv6 addresses on the
> host when deciding whether or not to suppress the IN AAAA query or not,
> otherwise you'll pretty much never do it.
Then of course yes. You can guess that contacting DNS-resulted IPv6 addresses
without a global/site IPv6 address is not necessary.
> > That said, if bug 14413 was resolved, you could do this sort of black magic
> > entirely in nss-dns.so. Without it, it's really hard to implement a
> > working implementation of AI_ADDRCONFIG.
> >
> > Maybe you could just specialcase DNS, it's a hack but certainly not worse
> > than what we're doing now.
>
> A hack, perhaps...or simply a return to the good old original RFC 2553
> specification. ;-)
It specifies the getaddrinfo(), that's the bug 14413 I mentioned above. If you
strictly follow the spec, you're afaik not ignoring link-local. In this case,
the specifications deserves a fix too.
I'm already trying to do this with RDNSS:
See http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-00
But, this is orthogonal to the solution of the current problem.
--
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.