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

["psimerda at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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.