Currently, glibc's getaddrinfo()-implementation will prefer transitional IPv6 connectivity (e.g. 6to4) above RFC 1918/NAT-based IPv4. Unfortunately, unnecessary use of transitional IPv6 connectivity (which quite often does not work properly) is the single largest reason for client loss (end users being unable to connect) when dual-stacking web sites. See for example my measurements that are posted at <http://thread.gmane.org/gmane.org.operators.ipv6/3248>. This behaviour is holding back the entire IPv6 rollout for web site operators, as deploying it will currently cut of access to the site for a not insignificant amount of users.
The problem is that RFC 3484 did not take into account the existence of IPv4 NAT, assuming that RFC 1918-based IPv4 addresses is unable to communicate with hosts on the global internet. As we all know, this is usually not the case - most home broadband deployments involve a CPE device that does NAT, and the end users' devices are usually numbered using RFC 1918-based addresses.
Rémi Denis-Courmount has written about the underlying problems at length here:
http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel-00
There is also a current draft that attempts to fix the issue properly:
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.
In fact, both FreeBSD and Microsoft has already made this change. It is quite telling that it was Microsoft who authored RFC 3484 to begin with, so I regard that a clear admission that the RFC has problems in this regard.
I have requested that the upstream glibc make the change:
http://sourceware.org/bugzilla/show_bug.cgi?id=11438
However, the feedback I got from Ulrich Drepper was basically that while he agrees with me that there is a real problem here, he is reluctant to make the change before the standardisation process has finished. However, he do go on to suggest that the distributions could work around the problem in the meanwhile.
I request that Ubuntu do exactly that. Time is of the essence; some predict that we're running out of IPv4 addresses within a year (cf. http://ipv4depletion.com) and so we need to get the IPv6 rollout going as soon as possible. To do that, though, we first need to fix the operational issues that holds it back - and this is one of them.
Thanks for considering!
Tore
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://
There's also an IETF draft that aims to revise RFC 3484 in order to fix this
problem (amongst others):
http://
Quoting from this document:
> 2.7. To change private IPv4 address scope
>
> As detailed in Remi's draft [I-D.denis-
> 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://
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 willin...