Bug 11438 - Please assign global scope to RFC 1918 addresses in getaddrinfo()
Summary: Please assign global scope to RFC 1918 addresses in getaddrinfo()
Alias: None
Product: glibc
Classification: Unclassified
Component: network (show other bugs)
Version: 2.12
: P2 normal
Target Milestone: ---
Assignee: Dmitry V. Levin
Depends on:
Reported: 2010-03-28 15:46 UTC by Tore Anderson
Modified: 2014-06-30 18:22 UTC (History)
4 users (show)

See Also:
Last reconfirmed:
fweimer: security-

Suggested patch (untested but obvious) (278 bytes, patch)
2010-03-28 15:46 UTC, Tore Anderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tore Anderson 2010-03-28 15:46:10 UTC
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 

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:


There's also an IETF draft that aims to revise RFC 3484 in order to fix this 
problem (amongst others):


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:


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:


You might also be interested in my February report available here:


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 

A glibc user can work around the problem by adding the following lines to 

scopev4 ::ffff: 14
scopev4 ::ffff: 14
scopev4 ::ffff: 14

However, average end users with internet connectivity through NAT-ed RFC 1918-
numbered networks cannot be expected to make such a change themselves.  They 
will likely just experience this as unexplained failures when connecting to 
certain (dualstacked) sites, possibly also realising that this is not a problem 
in alternative operating systems.  This is far from optimal, so I therefore 
request that glibc's default behaviour is changed according to the RFC 3484 
revision draft by assigning the global scope to RFC 1918-based addresses.

Best regards,
Tore Anderson
Comment 1 Tore Anderson 2010-03-28 15:46:59 UTC
Created attachment 4685 [details]
Suggested patch (untested but obvious)
Comment 2 Ulrich Drepper 2010-04-04 01:08:19 UTC
I don't want to make changes which haven't been decided.  Yes, there is a
problem.  I've documented the necessary changes in the gai.conf file.  It's easy
enough to install a file like that.  Distributions can do that.

I'm suspending the bug.  Change the state when any of the proposals are accepted.
Comment 3 Tore Anderson 2010-04-16 09:23:24 UTC
Hi Ulrich, and thanks for your feedback.  I've brought the problem up with a 
couple of major distributions (Fedora and Ubuntu), and they've both applied the 
change, so it will be part of both Fedora 13 and Ubuntu 10.04 LTS.

I've also just realised that the current practise of assigning non-global scope 
to rfc1918-addreses is more broken than what I first thought - if a host has 
only link-local IPv6 addresses in addition to (NAT-ed) RFC1918 IPv4 addresses, 
the link-local IPv6 address will be preferred for the outbound connection to a 
dual-stacked server with (both IPv6 and IPv4 addresses globally scoped).  I had 
to read rule 2 in RFC3484 many times before actually believing this is the RFC-
mandated behaviour.  But even if it is, it is obivously not the right thing to 

So I'm hoping that in light of this you might reconsider making the change prior 
to the completion of the IETF standardisation process.  I could attempt to 
persuade all the distributors to carry the change locally, but given the 
multitude of distributions out there I think it would be much more efficient to 
simply fix it in glibc centrally.

Thanks for your time!

Best regards,
Tore Anderson
Comment 4 Ulrich Drepper 2010-04-16 13:27:12 UTC
(In reply to comment #3)
> So I'm hoping that in light of this you might reconsider making the change prior 
> to the completion of the IETF standardisation process.

No, I won't.  I won't change something just to change it to something else if
the official decisions come out differently.
Comment 5 Tore Anderson 2012-09-11 09:30:18 UTC
(In reply to comment #2)

> I'm suspending the bug.  Change the state when any of the proposals are accepted.

Hi Ulrich,

RFC 6724 has just been published, obsoleting RFC 3484. It assigns global scope to RFC 1918 addresess.

As requested, I'm therefore changing the state of the bug.

Comment 6 Dmitry V. Levin 2012-09-11 17:42:32 UTC
There is a commit http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fedora/glibc-2.11.90-16-79-g1080954 in fedora branch that addresses this issue.
It is a part of fedora glibc package since glibc-2.11.90-17.
The current edition of the patch in fedora is http://pkgs.fedoraproject.org/cgit/glibc.git/tree/glibc-fedora-gai-rfc1918.patch

The irony is that this patch was made shortly after this bug was suspended by the same person who suspended it.  Unfortunately, that person in his commit gave no reference to this bug report.
Comment 7 Tore Anderson 2012-09-11 18:10:56 UTC
That's interesting. The reason why Fedora started carrying this patch in the first place, is because I submitted https://bugzilla.redhat.com/show_bug.cgi?id=577626.

Comment 8 law 2012-09-28 16:16:08 UTC
Patch installed.
Comment 10 Jackie Rosen 2014-02-16 16:55:35 UTC Comment hidden (spam)