Hi, The current practise of scoping RFC 3484-addresses as site-local is causing real operational problems on today's internet, and is inhibiting the rollout of IPv6 on the content side:
Consider a setup where an end user has his computer on a LAN with RFC 1918-based private IPv4 addresses (using NAT to connect to the global internet), as well as 6to4-based IPv6 addresses (or could be Teredo for that matter). In this case, when a web server is dual-stacked, getaddrinfo() will sort the 6to4-based IPv6 connectivity above the NAT-based IPv4 one. Transitional IPv6 tunneling like 6to4 is inherently less reliable than the IPv4 connectivity it runs on top of, so if the user has non-working transitional IPv6 connectivity (quite common), he will experience a dual-stacked web site as being simply down, or extremely slow (as all connection attempts over IPv6 needs to time out before the browser falls back to IPv4). Since web site operators are usually interested in having as many visitors as possible, the prospect of actually making the site unavailable for a not insignificant amount of users are keeping them from deploying IPv6 altogether. Rémi has documented the problem in detail here: http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel-00 There's currently a draft out that aims to correct this shortcoming (amongst others) in the original RFC: http://tools.ietf.org/html/draft-arifumi-6man-rfc3484-revise-02 Quote: > 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. It's worth nothing that FreeBSD and Microsoft appears to already have changed their getaddrinfo() implementations accordingly. Considering that the original RFC was written by Microsoft to begin with, this is in my opinion a clear admission that this is a shortcoming of the RFC. I have submitted a bug about the problem to the upstream glibc maintainers: http://sourceware.org/bugzilla/show_bug.cgi?id=11438 The feedback I got was basically that while he agrees there is a real problem here, he is reluctant to make the upstream change until the standardisation process is finished. However, he goes on to suggest that the distributors should work around the problem locally in the meanwhile. Because this bug is causing real operational problems that are holding back the IPv6 rollout, and with less then a year's worth of IPv4 addresses left in the IANA pool (cf. http://ipv4depletion.com/), it is really starting to become urgent to get these operational issues fixed ASAP. I therefore hope that Debian can help out by implementing the suggested change, either by shipping the /etc/gai.conf file by default, or by modifying the getaddrinfo.c sources, so that RFC 1918-based addresses are treated as globally scoped by default. Best regards, -- Tore Anderson -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
