Pending acceptance upstream when this gets RFC'd:
http://sourceware.org/bugzilla/show_bug.cgi?id=11438

--- posix/gai.conf~	2010-04-20 13:05:50.197813000 +0200
+++ posix/gai.conf	2010-04-20 13:08:46.472675000 +0200
@@ -66,3 +66,68 @@
 #scopev4 ::ffff:172.16.0.0/108   5
 #scopev4 ::ffff:192.168.0.0/112  5
 #scopev4 ::ffff:0.0.0.0/96       14
+
+
+# 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.
+
+scopev4 ::ffff:10.0.0.0/104 14
+scopev4 ::ffff:172.16.0.0/108 14
+scopev4 ::ffff:192.168.0.0/112 14