Back in 2003, the sorting algorithm used by getaddrinfo() was defined in RFC 3484.  However, this document did not take into account (or foresee) the ubiquity of IPv4 NAT on today's internet.  This in turn causes some real operational problems that's hindering the deployment of IPv6 for content providers.

The problem scenario is the following:

An end user is located in a network numbered with private (RFC 1918) IPv4 addresses and transitional 6to4 (RFC 3056) IPv6 addresses.  The network is connected to the internet by a CPE/SOHO device implementing NAT for IPv4 and anycasted 6to4 (RFC 3068) for IPv6.

When the user attempts to connect to a server whose hostname has both IPv4 and IPv6 addresses published in DNS, an IPv6 connection using the transitional 6to4 service will be preferred.  This happens because the scope comparsion fails for IPv4, the RFC 1918 addresses are assumed to have site-local scope, which is smaller than the global scope of the server's IPv4 address.  For IPv6, both the server's and the client's (6to4) address have global scope.

Unfortunately, the operational reality is that a transitional technique such as 6to4 is much less reliable than IPv4.  The relay routers might be located far away from the optimal IPv4 path, and thus cause a significant latency increase, or they might not even work optimally (they're usually operated by voulenteering third parties on a best-effort basis), and finally some ISPs simply filter away all proto-41 traffic.  Transitional techniques are useful to give end users with IPv4-only service a real shot at accessing IPv6-only content, but it should never be preferred over IPv4 service when accessing dual-stacked content.

RFC 3484 even acknowledges this, by saying to «avoid the use of transitional addresses when native addresses are available».

An IETF draft document which describes the problem in a much more detailed manner than I have is available here:

http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel-00

There's also an IETF draft that aims to revise RFC 3484 in order to fix this problem (amongst others):

http://tools.ietf.org/html/draft-arifumi-6man-rfc3484-revise-02

Quoting from this document:

> 2.7.  To change private IPv4 address scope
>
>    As detailed in Remi's draft [I-D.denis-v6ops-nat-addrsel], when a
>    host is in NATed site, and has a private IPv4 address and
>    transitional addresses like 6to4 and Teredo, the host chooses
>    transitional IPv6 address to access most of the dual-stack servers.
>
>    This is because private IPv4 address is defined to be site-local
>    scope, and as in RFC 3484, the scope matching rules (Rule 2) set
>    lower priority for private IPv4 address.
>
>    By changing the address scope of private IPv4 address to global, this
>    problem can be solved.

A few other getaddrinfo() implementations have already made this change, for instance FreeBSD (cf. http://lists.freebsd.org/pipermail/cvs-all/2004-May/066752.html) and Microsoft.  Considering that RFC 3484 was written by Microsoft, I think this is an admission that this is a real problem with the original specification.

The glibc maintainers has shown willingness before to adjust the RFC 3484 getaddrinfo() implentation in order to better deal with operational realities, instead of blindly following the original specification to the letter:

http://people.redhat.com/drepper/linux-rfc3484.html

See under «The BIG Problem».  Indeed, the fundamental problem being worked here is the same as the one I'm describing - namely that RFC 3484 assumes that RFC 1918-based addresses cannot communicate with hosts on the global internet.

I have been doing some measurements of IPv6-related brokenness in the last few months, and the conclusion is that almost all of the problems are due to improper preference for transitional IPv6 connections.  In particular, Apple's Mac OS X suffers from the exact same problem as glibc, and I've explained the operational impact in more detail on Apple's IPv6 mailing list:

http://lists.apple.com/archives/ipv6-dev/2010/Mar/msg00003.html

You might also be interested in my February report available here:

http://thread.gmane.org/gmane.org.operators.ipv6/2934

Check the second message to see the impact of taking OS X out of the equation.  I've posted monthly brokenness reports to the ipv6-ops list in question for a while now, you'll find them easily by searching for posts by me in Gmane's interface.

A glibc user can work around the problem by adding the following lines to /etc/gai.conf:

scopev4 ::ffff:10.0.0.0/104 14
scopev4 ::ffff:172.16.0.0/108 14
scopev4 ::ffff:192.168.0.0/112 14

However, average end users with internet connectivity through NAT-ed RFC 1918-numbered networks cannot be expected to make such a change themselves.  They will likely just experience this as unexplained failures when connecting to certain (dualstacked) sites, possibly also realising that this is not a problem in alternative operating systems.  This is far from optimal, so I therefore request that glibc's default behaviour is changed according to the RFC 3484 revision draft by assigning the global scope to RFC 1918-based addresses.

Best regards,
Tore Anderson