[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Changed in: glibc Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/555210 Title: Please assign global scope to RFC 1918 addresses in getaddrinfo() To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/555210/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Changed in: glibc Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/555210 Title: Please assign global scope to RFC 1918 addresses in getaddrinfo() To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/555210/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Launchpad has imported 5 comments from the remote bug at http://sourceware.org/bugzilla/show_bug.cgi?id=11438. If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. On 2010-03-28T15:46:10+00:00 Tore Anderson wrote: 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. A few other getaddrinfo() implementations have already made this change, for instance FreeBSD (cf. http://lists.freebsd.org/pipermail/cvs-all/2004- May/066752.html) and Microsoft. Considering that RFC 3484 was written by Microsoft, I think this is an admission that this is a real problem with the original specification. The glibc maintainers has shown willingness before to adjust the RFC 3484 getaddrinfo() implentation in order to better deal with operational realities, instead of blindly following the original specification to the letter: http://people.redhat.com/drepper/linux-rfc3484.html See under «The BIG Problem». Indeed, the fundamental problem being worked here is the same as the one I'm describing - namely that RFC 3484 assumes that RFC 1918-based addresses cannot communicate with hosts on the global internet. I have been doing some measurements of IPv6-related brokenness in the last few months, and the conclusion is that almost all of the problems are due to improper preference for transitional IPv6 connections. In particular, Apple's Mac OS X suffers from the exact same problem as glibc, and I've explained the operational impact in more detail on Apple's IPv6 mailing list: http://lists.apple.com/archives/ipv6-dev/2010/Mar/msg3.html You might also be interested in my February report available here: http://thread.gmane.org/gmane.org.operators.ipv6/2934 Check the second message to see the impact of taking OS X out of the equation. I've posted monthly brokenness reports to the ipv6-ops list in question for a while now, you'll find them easily by searching for posts by me in Gmane's interface. A glibc user can work around the problem by adding the
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
I agree with Gro-Tsen. I have better IPv6 connectivity than IPv4, and while IPv6 is preferred for most connections, if they are hosted on a 6to4 (2002::/16) host, then IPv4 is used. Some applications can force IPv6 (i.e. ssh -6, or telnet -6), but others cannot (i.e. Firefox or Chromium). Strange thing is that even though I'm *not* on a 6to4 connection, and even if the *destination* host has 6to4, then IPv4 is preferred. That logic doesn't sound right to me. If *I* had a 6to4 connection as the source IP, then maybe preferring IPv4 to 6to4 would make sense, but not for the destination. -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Jeremy, RFC 3484 specifies the following priorities («IPv6» here implies non- 6to4) - it does not matter which is the source and which is the destination: 1) IPv6 - IPv6 2) 6to4 - 6to4 3) IPv4 - IPv4 4) 6to4 - IPv6 These haven't changed. However, if you want #4 to be sorted above #3, you can easily accomplish that by disabling the special casing of 2002::/16 by adding the following lines to gai.conf: label ::1/128 0 label ::/0 1 #label 2002::/16 2 label ::/96 3 label :::0:0/96 4 label fec0::/10 5 label fc00::/7 6 label 2001:0::/32 7 precedence ::1/128 50 precedence ::/0 40 #precedence 2002::/16 30 precedence ::/96 20 precedence :::0:0/96 10 If you also want Teredo-based connectivity to be preferred above IPv4, comment out the line with 2001:0::/32 as well. Tore -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Gro-Tsen, native IPv6 is still preferred over native IPv4 in Lucid, as it always has. What changed in Lucid is that non-native IPv6 (6to4 and Teredo), is now always less preferred than native IPv4 (even when behind a NAT). I can assure you that having better and more reliable connectivity through 6to4/Teredo than through IPv4 is not typical Your suggested change is correct, uncommenting those lines in /etc/gai.conf will revert back to the pre-Lucid behaviour where non- native IPv6 will be preferred over IPv4. It should not have any other consequences, no. You can confirm how the getaddrinfo() algorithm sorts the available addresses by using e.g. getent ahosts www.ripe.net - the address first listed will be the preferred one. Tore -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
How can I revert to the previous (pre-Lucid) behavior? (I have much better connectivity through IPv6 than through a painfully NATed IPv4. I assume this is fairly typical, in fact.) Is it just a matter of uncommenting the following lines in /etc/gai.conf or will this have undesired side effects? scopev4 :::169.254.0.0/112 2 scopev4 :::127.0.0.0/1042 scopev4 :::10.0.0.0/104 5 scopev4 :::172.16.0.0/108 5 scopev4 :::192.168.0.0/112 5 scopev4 :::0.0.0.0/96 14 -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Changed in: eglibc (Debian) Status: Confirmed = Fix Released -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Bug watch added: Sourceware.org Bugzilla #11438 http://sourceware.org/bugzilla/show_bug.cgi?id=11438 ** Also affects: glibc via http://sourceware.org/bugzilla/show_bug.cgi?id=11438 Importance: Unknown Status: Unknown ** Bug watch added: Debian Bug tracker #468801 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468801 ** Also affects: eglibc (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468801 Importance: Unknown Status: Unknown -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Changed in: glibc Status: Unknown = Incomplete -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Changed in: eglibc (Debian) Status: Unknown = Confirmed -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
This bug was fixed in the package eglibc - 2.11.1-0ubuntu6 --- eglibc (2.11.1-0ubuntu6) lucid; urgency=low [ Kees Cook ] * [BZ #11333], Handle unnecessary padding in getdents64. LP: #392501. [ Matthias Klose ] * Apply from the 2.11-x86 branch: - Fix bugs in strcmp-sse4.S and strcmp-ssse3.S (H.J. Lu). LP: #563291. - Fix bugs in memcpy-ssse3. LP: #560135. * Assign global scope to RFC 1918 addresses in getaddrinfo(). Thanks Tore Anderson. LP: #555210. * Re-enable the local-ipv6-lookup patch. Addresses #417757. -- Matthias Klose d...@ubuntu.com Sun, 18 Apr 2010 00:05:05 +0200 ** Changed in: eglibc (Ubuntu Lucid) Status: Fix Committed = Fix Released -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Branch linked: lp:ubuntu/eglibc -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
The functionality appears to work exactly as expected, thanks! However the comment to the gai.conf file didn't get correctly added, I think. I think the Fedora people patched a newer version of the upstream file, so the additional comment about this being the default in Fedora/Ubuntu should have been added below a recently added upstream comment about the RFC1918/3484 problems. If you understand what I mean. :-) Anyway - the relevant parts of the gai.conf file in Fedora now looks like this: # scopev4 mask value #Add another rule to the RFC 3484 scope table for IPv4 addresses. #By default the scope IDs described in section 3.2 in RFC 3484 are #used. Changing these defaults should hardly ever be necessary. #The definitions in RFC 1918 are equivalent to: # #scopev4 :::169.254.0.0/112 2 #scopev4 :::127.0.0.0/1042 #scopev4 :::10.0.0.0/104 5 #scopev4 :::172.16.0.0/108 5 #scopev4 :::192.168.0.0/112 5 #scopev4 :::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: # #scopev4 :::169.254.0.0/112 2 #scopev4 :::127.0.0.0/1042 #scopev4 :::0.0.0.0/96 14 # #This is what the Red Hat setting currently uses. This is more accurate, except that the comment The definitions in RFC 1918 are equivalent to: is a thinko, it should instead read The definitions in RFC 3484 are equivalent to:. Tore -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Also, come to think of it, it's a bit confusing that the first comment still says: # By default the scope IDs described in section 3.2 in RFC 3484 are # used. Changing these defaults should hardly ever be necessary. ...when changing those defaults is exactly what's being done by the patch to getaddrinfo.c. So perhaps they should simply be removed. Tore -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Hi, as requested, here's a diff to the gai.conf file in your ppa .deb that makes the comments a bit more correct. ** Patch added: gai.conf-vs-ppa.patch http://launchpadlibrarian.net/44415358/gai.conf-vs-ppa.patch -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Changed in: eglibc (Ubuntu Lucid) Importance: Undecided = Medium -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
** Also affects: eglibc (Ubuntu Lucid) Importance: Undecided Status: New ** Changed in: eglibc (Ubuntu) Status: New = Fix Committed ** Changed in: eglibc (Ubuntu) Milestone: None = ubuntu-10.04 ** Changed in: eglibc (Ubuntu Lucid) Status: New = Fix Committed ** Changed in: eglibc (Ubuntu Lucid) Milestone: None = ubuntu-10.04 -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
a test package is available at deb http://ppa.launchpad.net/ubuntu-toolchain/ppa/ubuntu lucid main please could you check for the fix? -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210] Re: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Just a little update here: Fedora has commited the change and it'll be part of F13. See https://bugzilla.redhat.com/show_bug.cgi?id=577626. I have tested their patch (attached) and it works as expected. It would really be fantastic if this could be commited to Ubuntu as well, hopefully it's not too late for inclusion in the LTS due soon... Best regards, Tore ** Bug watch added: Red Hat Bugzilla #577626 https://bugzilla.redhat.com/show_bug.cgi?id=577626 ** Patch added: Patch commited to Fedora 13 http://launchpadlibrarian.net/43251601/glibc-gai-rfc3484.patch -- Please assign global scope to RFC 1918 addresses in getaddrinfo() https://bugs.launchpad.net/bugs/555210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
