Bug#468801: libc6: RFC3484 scoping rules should only affect IPv6, not IPv4
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
Reply to: