[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 #21 from Tore Anderson <tore at fud dot no> 2012-07-31 18:34:09 UTC ---
(In reply to comment #19)

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

Very strange! If I purge my system of IPv6 addresses (ignoring the ::1 loopback
address and link-locals), resolving addresses using my getaddrinfo() test
program available at http://fud.no/gai.c (use the "-ac" parameter to make it
use AI_ADDRCONFIG), causes IN AAAA lookups to be suppressed. Looking at the DNS
traffic on the wire, only IN A lookups are seen. The same thing happens when
using Mozilla Firefox, which is also using AI_ADDRCONFIG for all other names
than "localhost" (plus some variants).

I'm running Fedora 17 with a completely stock glibc-2.15-51.fc17.x86_64.rpm.

However, during testing now I did notice that when I purge my system of IPv4
addresses, leaving only the 127.0.0.1 loopback one, IN A lookups are *not*
suppressed when AI_ADDRCONFIG is in use. That's certainly a (different) bug.

(In reply to comment #20)
> Ah, now I see what you mean by good old RFC 2553...
> 
> You're cheating, you cited from an obsolete RFC:

Excuse me?

You were saying that AI_ADDRCONFIG was a Âhack that had no useful purpose, at
least that is how I understood you. By showing you to the original definition
of it, I wanted to show you that it was a very good reason why it was invented
in the first place, that there actually was (and still is) a problem that it
attempted to solve.

Furthermore, I never hid the fact that RFC 2553 isn't the current one. I
pointed that out explicitly, in fact, by saying ÂRFC 3493 changed the
definition of getaddrinfo() from the original DNS-only definition in RFC 2553
[...]Â.

So I strenuously object to your accusation of me Âcheating here.

> DNS is now only as an example. This part of the new RFC is *wrong* and we
> should not implement it. The specification should be fixed then.

Yes, I agree.

The language in RFC 3493 is more general, I'm guessing the reason for changing
it in that way was so that it would stand up to changes in DNS itself (or even
the possible replacement of DNS with something else entirely). For example, RFC
2553 refers specifically to AAAA records, but after its publication, the (now
abandoned) A6 resource record had been defined in RFC 2874. A strict
interpretation of RFC 2553 would not cause A6 queries to be suppressed in the
same way as AAAA records, even though it is obivous that would have been the
*intention* of RFC 2553. The RFC 3493 language, on the other hand, would apply
equally to both AAAA and A6 records.

A strict interpretation of the new language in RFC 3493 does indeed mean that
AI_ADDRCONFIG lookups for IP address literals should fail if there are no
global address of the same address family configured on the node, even for link
locals and loopback addresses. Also that the "localhost" host name only resolve
to the address family from which there are global addresses, in the case of a
single-stack host (with a dual-stacked loopback interface).

When considering the original specification of AI_ADDRCONFIG and trying to
understand the problem it tried to solve, and what went with DNS between its
publication and that of RFC 3493, I am of the opinion that the problematic side
effects caused by the new language in RFC 3493 were entirely unintentional.

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.