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: "tore at fud dot no" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 31 Jul 2012 13:59:09 +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 #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.