The sorting algorithm used by getaddrinfo() is defined by RFC 3484. The purpose of the algorithm is to make sure the best possible source and destination address pair is chosen as the first to try, when a client is establishing a connection to a remote server. This is especially important when servers that have several addresses to choose from, e.g. both an IPv4 and an IPv6 one. One of the stated goals of the RFC is to «avoid the use of transitional addresses when native addresses are available», which makes a lot of sense - transitional connectivity is inherently less reliable than the native connectivity it runs on top of. Unfortunately, there is a shortcoming in the RFC that makes it fail to attain that goal, in some situations commonly found on today's internet. This is the situation where a end user station has a private IPv4 address (from a RFC 1918 prefix), as well as a transitional IPv6 address (e.g. using anycasted 6to4 as defined in RFC 3068). RFC 3484 makes the assumption that RFC 1918-based addresses are unable to communicate with hosts on the global internet, and are therefore assigned a site-local scope. As you're no doubt aware - use of IPv4 NAT is extremely commonplace on today's internet, which makes this assumption incorrect. To the RFC 3484 authors' defence, though, it probably made sense at the time of writing (Feb 2003), but in any case it have created an operational problem on today's internet - in the situation described above, the end user station will prefer to use IPv6/6to4 connectivity to connect to the remote server, instead of native IPv4/NAT, and if 6to4 then does not work - which is quite common - the IPv6 connection attempt have to time out before the client application falls back to IPv4. Applications that are latency-sensitive and make use of many connections (HTTP in particular) will be rendered unuseable. This in turn causes web site operators to postpone deploying IPv6 - nobody wants to make their web site unavailable for potential readers. I have been doing measurements of such client loss (end users being unable to access a web site with both IPv4 and IPv6 addresses, while having no problems with a IPv4-only one) in the last few months, and at the time of writing over 60% of all client loss is attributable to Mac OS X, because it too suffers from this exact problem. See: http://thread.gmane.org/gmane.org.operators.ipv6/3248 Rémi Denis-Courmont have described the problem at length here: http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel-00 And the IETF is working on revising RFC 3484 to fix this problem (amongst others), see: http://tools.ietf.org/html/draft-arifumi-6man-rfc3484-revise-02 The proposed solution for the problem (section 2.7) is to simply assign the global scope to RFC 1918 adresses. It is also well worth mentioning that getaddrinfo() in Microsoft Windows, which could very well be considered the reference implementation of (the Microsoft-authored) RFC 3484, is already doing exactly this. So does FreeBSD's implementation. I have requested the glibc upstream to do likewise, see: http://sourceware.org/bugzilla/show_bug.cgi?id=11438 However, he declined to apply the patch and thus diverge from the RFC-mandated behaviour. However, he acknowledged the problem, suggesting that the distributors making the change locally until the IETF has finished its standardisation process. Fedora and Ubuntu have already done so: https://bugzilla.redhat.com/show_bug.cgi?id=577626 https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/555210 IPv4 exhaustion is on the horizon, and you'll be seeing more and more web sites deploying IPv6 in the near future. To ensure that your users (those that do not have native IPv6 connectivity) will be able to access these sites as reliably as before, you will need to make this change as well - as soon as possible. I hope that you will! It can either be done by modifying getaddrinfo.c, or by shipping the /etc/gai.conf file - I will attach patches shortly. Best regards, Tore Anderson
Created attachment 228287 [details, diff] Assign global scope to RFC 1918 addresses in getaddrinfo.c This patch will assign the global scope to RFC 1918 addresses, by #if 0-ing them out of the "scopeentry" struct in getaddrinfo.c, thereby changing the compiled-in default setting. This is the approach taken by Fedora and Ubuntu. The diff applies to glibc git HEAD.
Created attachment 228291 [details, diff] Assign global scope to RFC 1918 addresses in gai.conf This alternative approach will assign the global scope to RFC 1918 addresses by uncommenting the necessary lines in gai.conf, instead of modifying the compiled-in default settings. For it to work, /etc/gai.conf must be installed by default. Please be aware that I have not checked if Gentoo does that or not. The diff applies to glibc git HEAD.
OK, since upstream has suggested distros do this, and Fedora has gone this route (the glibc maintainers there work closely with the upstream glibc maintainers), i dont have a problem with these patches. otherwise, my comment would have been the same as drepper's -- i agree it looks like a bad state, but i'm not an expert on things and i dont like going against published standards. i'm going the route of pure gai.conf modification so that end users can easily see the incoming changes via etc-update, and can easily change things on the fly. i.e. your alt2.patch.
glibc-2.11.1 ebuild should include the gai.conf change
