File glibc-gai-private4.diff of Package glibc
--- posix/gai.conf~ 2010-05-12 04:10:58.087661000 +0200 +++ posix/gai.conf 2010-05-12 04:14:40.638820000 +0200 @@ -67,11 +67,66 @@ #scopev4 ::ffff:192.168.0.0/112 5 #scopev4 ::ffff:0.0.0.0/96 14 # -# For sites which use site-local IPv4 addresses behind NAT there is -# the problem that even if IPv4 addresses are preferred they do not -# have the same scope and are therefore not sorted first. To change -# this use only these rules: +# 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 +# comparison 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:169.254.0.0/112 2 -#scopev4 ::ffff:127.0.0.0/104 2 -#scopev4 ::ffff:0.0.0.0/96 14 +scopev4 ::ffff:10.0.0.0/104 14 +scopev4 ::ffff:172.16.0.0/108 14 +scopev4 ::ffff:192.168.0.0/112 14
