forked from pool/glibc
This commit is contained in:
Petr Baudis
Git OBS Bridge
parent
67f6df3eb9
commit
de4358c978
74
glibc-gai-private4.diff
Normal file
74
glibc-gai-private4.diff
Normal file
@ -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
|
||||||
@ -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
|
Wed Mar 24 13:04:12 CET 2010 - pbaudis@suse.cz
|
||||||
|
|
||||||
|
|||||||
@ -133,6 +133,7 @@ Patch60: ld-prelink-unique.diff
|
|||||||
Patch61: glibc-ppc64-vdso-time.diff
|
Patch61: glibc-ppc64-vdso-time.diff
|
||||||
Patch62: nptl-ppc64-vdso-timedwait.diff
|
Patch62: nptl-ppc64-vdso-timedwait.diff
|
||||||
Patch63: glibc-getnprocs.diff
|
Patch63: glibc-getnprocs.diff
|
||||||
|
Patch64: glibc-gai-private4.diff
|
||||||
Patch500: ARM_glibc-2.10.1-local-eabi-wchar.diff
|
Patch500: ARM_glibc-2.10.1-local-eabi-wchar.diff
|
||||||
Patch501: ARM_glibc-2.10.1-local-hwcap-updates.diff
|
Patch501: ARM_glibc-2.10.1-local-hwcap-updates.diff
|
||||||
Patch502: ARM_glibc-2.10.1-local-lowlevellock.diff
|
Patch502: ARM_glibc-2.10.1-local-lowlevellock.diff
|
||||||
@ -357,6 +358,7 @@ rm nscd/s-stamp
|
|||||||
%patch61 -p1
|
%patch61 -p1
|
||||||
%patch62 -p1
|
%patch62 -p1
|
||||||
%patch63 -p1
|
%patch63 -p1
|
||||||
|
%patch64
|
||||||
%ifarch %arm armv5tel armv7l
|
%ifarch %arm armv5tel armv7l
|
||||||
%patch500
|
%patch500
|
||||||
%patch501
|
%patch501
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user