[Bug network/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 #18 from Tore Anderson <tore at fud dot no> 2012-07-31 13:59:09 UTC ---
(In reply to comment #16)

> > If so, I disagree. 
> 
> Disagree with what exactly?

With the entire statement. To break it down a bit:

> This option is probably meant to guess whether we can sendto() data to this
> address

I disagree, I believe the purpose of AI_ADDRCONFIG was primarily to suppress IN
A and IN AAAA DNS lookups in the case when they are likely to be not useful.
Quoting from RFC 2553:

      - The AI_ADDRCONFIG flag specifies that a query for AAAA records
        should occur only if the node has at least one IPv6 source
        address configured and a query for A records should occur only
        if the node has at least one IPv4 source address configured.

> (for connect() it is not necessary as connect() immediately returns
> failure for nonroutable addresses)

I disagree again. One of the applications that will benefit the most from
AI_ADDRCONFIG is a web browser, which can use it to avoid generating IN AAAA
DNS queries when looking up hostnames, when running on an IPv4-only machine.
(Or avoid IN A lookups when running on an IPv6-only machine.) As you probably
are well aware, a web browser will be a heavy user of connect(), while rarely
if ever use sendto().

> But I can't think of *any* reason to use this hack

Disagree, as above, a web browser has a very good reason to use AI_ADDRCONFIG.

> when it's so easy to ask the system if the address is actually routable.

Again, disagreed. AI_ADDRCONFIG is useful when looking up names to IP
addresses. using DNS. Before knowing the IP address, it is impossible to ask
the system whether or not it is usable.

> The way I see it, the primary reason for using AI_ADDRCONFIG
> is to avoid making lookups from which any results cannot be used.
> 
> And it fails terribly, giving both false positives and false negatives
> and even breaking literal IP addresses.

As far as I can tell, AI_ADDRCONFIG works perfectly for (forward) DNS lookups,
which I belive is what it's primarily meant to do. If I remove all IPv6
addresses except ::1 and look up a name, no IN AAAA queries are sent. Or if I
remove all IPv4 addresses except 127.0.0.1, no IN A queries are sent.

RFC 3493 changed the definition of getaddrinfo() from the original DNS-only
definition in RFC 2553 to a more general one that resembles the one that is
included in glibc. However, the example described still revolves around forward
DNS IN A/AAAA lookups so I'm not quite sure if the change was a sensible one.
There was certainly not much operational experience with it at that point in
time.

> > 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 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.

> 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.

> *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.

> 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.  ;-)

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.