diff --git a/glibc-gai-private4.diff b/glibc-gai-private4.diff new file mode 100644 index 0000000..8dfc671 --- /dev/null +++ b/glibc-gai-private4.diff @@ -0,0 +1,74 @@ +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 diff --git a/glibc.changes b/glibc.changes index c4a2441..20c8e7d 100644 --- a/glibc.changes +++ b/glibc.changes @@ -1,3 +1,8 @@ +------------------------------------------------------------------- +Tue Apr 20 13:15:19 CEST 2010 - pbaudis@suse.cz + +- Consider private IPv4 addresses as global-scope in gai.conf [bnc#597616] + ------------------------------------------------------------------- Wed Mar 24 13:04:12 CET 2010 - pbaudis@suse.cz diff --git a/glibc.spec b/glibc.spec index 15375f2..41721df 100644 --- a/glibc.spec +++ b/glibc.spec @@ -133,6 +133,7 @@ Patch60: ld-prelink-unique.diff Patch61: glibc-ppc64-vdso-time.diff Patch62: nptl-ppc64-vdso-timedwait.diff Patch63: glibc-getnprocs.diff +Patch64: glibc-gai-private4.diff Patch500: ARM_glibc-2.10.1-local-eabi-wchar.diff Patch501: ARM_glibc-2.10.1-local-hwcap-updates.diff Patch502: ARM_glibc-2.10.1-local-lowlevellock.diff @@ -357,6 +358,7 @@ rm nscd/s-stamp %patch61 -p1 %patch62 -p1 %patch63 -p1 +%patch64 %ifarch %arm armv5tel armv7l %patch500 %patch501