This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


http://sourceware.org/bugzilla/show_bug.cgi?id=12377

--- Comment #13 from Pavel Åimerda <psimerda at redhat dot com> 2012-07-29 08:30:36 UTC ---
I have done some new tests (still with glibc-2.15-51.fc17.x86_64):

AF_UNSPEC + AI_ADDRCONFIG: In this case AI_ADDRCONFIG doesn't seem to work at
all
(read doesn't remove *any* addresses). It is useless. It's against the manpage
and RFCThis is the default (plus
the also useless AI_V4MAPPED as in bug 14415).

AF_INET + AI_ADDRCONFIG: In this case AI_ADDRCONFIG does exactly what's written
down in the RFC 3493 (and almost what is in the manpage). That means it breaks
'localhost', 'localhost4' and '127.0.0.1' and it would break any other address
assigned to the loopback interface. I haven't tested IPv6 link-local addresses.

AF_INET6 + AI_ADDRCONFIG: Same as above. Breaks 'localhost', 'localhost6' and
'::1'. With some new addition, it also breaks link-local addresses
(e.g. fe80::21f:3cff:fe1b:9e5e%wlan0) and would also break names pointing to
them if getaddrinfo was implemented in nsswitch (bug 14413).

AF_INET6 + AI_ADDRCONFIG + AI_V4MAPPED (+ AI_ALL): Same behavior as above,
broken localhost for both IPv6 and mapped IPv4.

From http://tools.ietf.org/html/rfc3493#section-6.1

  If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only
  if an IPv4 address is configured on the local system, and IPv6 addresses
shall
  be returned only if an IPv6 address is configured on the local system.

This is a stupid way and cannot work. Even the authors new it, that's why
there's something added at the and of the paragraph.

  The loopback address is not considered for this case as valid as a configured
  address.

But this assumes you never need to use the usual addresses on the loopback
(which is wrong) and that you never add more addresses to the loopback e.g.
for testing (which is also wrong). And it also assumes you never have
non-global addresses on other interfaces (which is also wrong, you
have IPv6 link-local and you could have IPv4 link-local).

This option is probably meant to guess whether we can sendto() data to this
address (for connect() it is not necessary as connect() immediately returns
failure for nonroutable addresses). But I can't think of *any* reason
to use this hack when it's so easy to ask the system if the address is actually
routable.

$ ip route get 2001:db8:1:1::1
$

You see, this address is *not* routable. But even if you try to fool it:

# ip route add default via fe80::23:45ff:fe67:8901 dev eth0

$ ip route get 2001:db8:1:1::1
2001:db8:1:1::1 from :: via fe80::23:45ff:fe67:8901 dev eth0  src
fe80::12:34ff:fe56:7890  metric 0
    cache

You can still easily detect the problem as the dst address is global and src
address is link-local. So there's actually no guessing needed when the
information is right at your hand.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]