[Bug 555210]

[MikeFrysinger]

for reference:
http://sourceware.org/git/?p=glibc.git;a=commit;h=115411772b189e9e41a97618816edd66f0a9a620

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/555210

Title:
  Please assign global scope to RFC 1918 addresses in getaddrinfo()

Status in The GNU C Library:
  Fix Released
Status in “eglibc” package in Ubuntu:
  Fix Released
Status in “eglibc” source package in Lucid:
  Fix Released
Status in “eglibc” package in Debian:
  Fix Released

Bug description:
  Currently, glibc's getaddrinfo()-implementation will prefer
  transitional IPv6 connectivity (e.g. 6to4) above RFC 1918/NAT-based
  IPv4.  Unfortunately, unnecessary use of transitional IPv6
  connectivity (which quite often does not work properly) is the single
  largest reason for client loss (end users being unable to connect)
  when dual-stacking web sites.  See for example my measurements that
  are posted at <http://thread.gmane.org/gmane.org.operators.ipv6/3248>.
  This behaviour is holding back the entire IPv6 rollout for web site
  operators, as deploying it will currently cut of access to the site
  for a not insignificant amount of users.

  The problem is that RFC 3484 did not take into account the existence
  of IPv4 NAT, assuming that RFC 1918-based IPv4 addresses is unable to
  communicate with hosts on the global internet.  As we all know, this
  is usually not the case - most home broadband deployments involve a
  CPE device that does NAT, and the end users' devices are usually
  numbered using RFC 1918-based addresses.

  Rémi Denis-Courmount has written about the underlying problems at
  length here:

  http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel-00

  There is also a current draft that attempts to fix the issue properly:

  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.

  In fact, both FreeBSD and Microsoft has already made this change.  It
  is quite telling that it was Microsoft who authored RFC 3484 to begin
  with, so I regard that a clear admission that the RFC has problems in
  this regard.

  I have requested that the upstream glibc make the change:

  http://sourceware.org/bugzilla/show_bug.cgi?id=11438

  However, the feedback I got from Ulrich Drepper was basically that
  while he agrees with me that there is a real problem here, he is
  reluctant to make the change before the standardisation process has
  finished.  However, he do go on to suggest that the distributions
  could work around the problem in the meanwhile.

  I request that Ubuntu do exactly that.  Time is of the essence;  some
  predict that we're running out of IPv4 addresses within a year (cf.
  http://ipv4depletion.com) and so we need to get the IPv6 rollout going
  as soon as possible.  To do that, though, we first need to fix the
  operational issues that holds it back - and this is one of them.

  Thanks for considering!

  Tore

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/555210/+subscriptions