Red Hat Bugzilla – Bug 166636
Wrong source IPv6 address selected for destination
Last modified: 2007-11-30 17:11:12 EST
Description of problem:
There is a host with normal and 6to4 IPv6 connectivity and
two global IPv6 addresses configured on eth0:
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0f:ea:61:98:cc brd ff:ff:ff:ff:ff:ff
inet 192.168.253.2/24 brd 192.168.253.255 scope global eth0
inet6 2002:5580:5ba8:1:20f:eaff:fe61:98cc/64 scope global dynamic
valid_lft 86397sec preferred_lft 43197sec
inet6 2001:5c0:8a70:0:20f:eaff:fe61:98cc/64 scope global dynamic
valid_lft 2591997sec preferred_lft 604797sec
inet6 fe80::20f:eaff:fe61:98cc/64 scope link
valid_lft forever preferred_lft forever
When trying to connect to site with global normal (i.e.2001:...) IP address
hosts chooses 6to4 source address and TCP connection is not established - it
is stuck in SYN_SENT state:
tcp 0 1 2002:5580:5ba8:1:20f::43588 2001:5c0:8a70::1:25 SYN_SENT
tcp 0 1 2002:5580:5ba8:1:20f::32945 2001:200:0:8002:203:47ff:80 SYN_SENT
Please note - this problem occurs on end node. Linux Box working as router to
IPv6 and 6to4 seems to work fine.
Adding route using ip route add ... src .. for 2001: and 2002: hasn't helped.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup linux box with normal and 6to4 connectivity
2. Try to connect to normal IPv6 site
3. If the above step works - try to connect to 6to4 site as
kernel seems to pick up the first IPv6 address configured
4. Step 3 or step 4 fails
Some connections from host with normal and 6to4 connectivity do
All connections from host with normal and 6to4 connectivity do
Kernel should choose normal global IPv6 source addrress for connections
to normal global IPv6 addrresses.
Kernel should choose 6to4 global IPv6 source addrress for connections
to 6to4 global IPv6 addrresses.
6to4 addresses are global, even the ifconfig ipv6 address listing
in your output indicates this
the source address selection algorithm specified by the RFCs makes
a distinction between scoping types (global, site local, etc.) but
not between different types of global addresses such as 6to4 ones
You can see the exact source address selection algorithm, which is
an implementation of what the RFCs require, in net/ipv6/addrconf.c
function ipv6_dev_get_saddr(). It walks the specified device (usually
the one for which the packet has been routed to), and picks the first
address on the device which matches the scope of the destination IPV6
address for the route.
Sorry, I really don't see this as a bug. It might be instructive for
you to take this up on the firstname.lastname@example.org mailing list so that
it can be discussed with the USAGI project and other IPV6 experts more
I cannot disagree more.
First of all it is a pity you hasn't refer to specific RFC.
Second: there is something in source address selection which prevents
connection establishemnt and there is no workaround (I mentioned I tried to
add routes with explicit src address and it didn't work and this alone may
justify treating this as a bug).
Now some pointers:
RFC3056 section 2.1 and discussion of point 3 in section 5.2. Please also
note that this RFC treats native IPv6 and 6to4 networks as independent routing
domains and this alone will cause routing failures if address from one
domain is used in the other.
RFC3484 section 5 rule 6 (which will alone choose 6to4 source for 6to4
destination and native source for native destination in default configuration)
and rule 8 which says: Use longest matching prefix.
It looks like this patch:
I reiterate my request for you to bring this up on the Linux network
developer mailing list so that it can be discussed with other Linux
IPV6 experts. I'd really appreciate you doing that, and it would
accelerate this bug being resolved.
Discussing the patch here is a dead end because the USAGI and upstream
folks need to be involved before we can put it into our tree.
SO this is in needinfo until the netdev mailing list thread is started.
Thanks a lot.
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
Judging from quick look in a code it is not fixed.
I filed bug on kernel for this (http://bugzilla.kernel.org/show_bug.cgi?id=5200)
to push it upstream and that all I can do as I don't have resources to push
discussion on kernel mailing list.
The bug in kernel bugzilla is still NEW for quite some time.
The current upstream 2.6.x kernel does have the RFC3484 source address
resolution fixes, it's in Linus's current GIT tree.
How likely it is that this will propagate into the FC4 kernel, I have
I'll do a 2.6.15 backport to FC4 shortly after its release.
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Seems to work fine on 2.6.15-1.1830_FC4.