[Bug libc/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 #3 from Tore Anderson <tore at fud dot no> 2011-07-07 09:19:32 UTC ---
(In reply to comment #2)

> How does getaddrinfo() know that the name to be looked-up isn't supposed to map
> to a link-local IPv6 address that will be reachable?

A link-local address on its own is not very useful. You'll need an interface ID
to make it unambigous, and as far as I know, DNS/getaddrinfo() cannot supply
this
information. Try for example adding "mycomputer IN AAAA
fe80::21c:c4ff:fe47:d3f9"
in DNS, and then do "ping6 mycomputer" - it'll fail with ÂInvalid argumentÂ.

> Interestingly enough, I seem to have the opposite problem - it appears that for
> 2.12, as shipped with Maverick anyway, that the presence of a link-local IPv6
> address is not sufficient to allow "::1" (or other IPv6 addresses, for example
> " fe80::21c:c4ff:fe47:d3f9" which happens to be the link-local IPv6 address on
> my system's eth0 interface) to be resolved when AI_ADDRCONFIG is set - which I
> consider a bug :)

You could make the exact same argument about loopback addresses as well:

ÂHow does getaddrinfo() know that the name to be looked-up isn't supposed to
map to a loopback IPv6 address that will be reachable?Â

However, the spec for AI_ADDRCONFIG is very clear that loopback addresses
should
be ignored. So, for example, if you're looking up "localhost" on a machine that
has no IPv4 network connectivity using AI_ADDRCONFIG, it might make sense to
get
back 127.0.0.1, but the spec is very clear: you should not.

>From this it is easy to infer the true purpose of AI_ADDRCONFIG - avoid looking
up addresses that it is highly unlikely that you can make use of. Loopbacks and
link-locals are corner cases since they're always present regardless of
external
connectivity, and link-locals is even more of a corner-case than loopbacks as
a name cannot resolve to a usable link-local address (with an interface id).
Therefore link-locals should be ignored when determining external connectivity
by AI_ADDRCONFIG, just like loopbacks are.

That said, I cannot reproduce the behaviour you're seeing on my Fedora 15
workstation:

$ ip -6 address list ; ./gai-test -ac localhost
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::21d:60ff:fe48:f59e/64 scope link 
       valid_lft forever preferred_lft forever
[         0us] -ac seen, using AI_ADDRCONFIG from now on

[         0us] begin gai_and_connect(localhost)
[+      560us] getaddinfo(localhost) done
[+       15us] dest = ::1 (AF_INET6)
[+        8us] about to connect()
[+       61us] connect() suceeds
[+       39us] dest = 127.0.0.1 (AF_INET)
[+        7us] about to connect()
[+       49us] connect() suceeds
$ 

If I remove the link-local address, however, the ::1 isn't returned, as
expected:

$ sudo ip -6 address flush dev eth0; ip -6 address list ; ./gai-test -ac
localhost
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
[         0us] -ac seen, using AI_ADDRCONFIG from now on

[         0us] begin gai_and_connect(localhost)
[+      509us] getaddinfo(localhost) done
[+       13us] dest = 127.0.0.1 (AF_INET)
[+        8us] about to connect()
[+       57us] connect() suceeds
[+       40us] dest = 127.0.0.1 (AF_INET)
[+        6us] about to connect()
[+       39us] connect() suceeds
$ 

> > For what it's worth, both Microsoft Windows and Mac OS X appear to disregard
> > link-local IPv6 addresses for AI_ADDRCONFIG purposes, with no apparent ill
> > effects.
> 
> Perhaps no-one is attempting to actually do link-local IPv6 communication yet.

Link-local communication is absolutely essential to the IPv6 protocol, without
it Neighbour Discovery, Router Advertisements/Solicitations, and Duplicate
Address Detection cannot work. So pretty much everyone is doing link-local
communication, but it's used on a lower level than getaddrinfo().

Apple is also using link-local addressing for other stuff (i.e. management of
their Airport/TimeCapsule wireless routers), as far as I know, but
getaddrinfo()
isn't involved there either.

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.