Bug 166636 - Wrong source IPv6 address selected for destination
Wrong source IPv6 address selected for destination
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-08-24 01:09 EDT by Tomasz Kepczynski
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-19 00:32:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomasz Kepczynski 2005-08-24 01:09:52 EDT
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 brd 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):

How reproducible:

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
   on interface
4. Step 3 or step 4 fails
Actual results:
Some connections from host with normal and 6to4 connectivity do
not work.

Expected results:
All connections from host with normal and 6to4 connectivity do
not work.

Additional info:
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.
Comment 1 David Miller 2005-08-25 19:54:59 EDT
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 netdev@vger.kernel.org mailing list so that
it can be discussed with the USAGI project and other IPV6 experts more

Comment 2 Tomasz Kepczynski 2005-09-02 06:36:14 EDT
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.

Comment 3 Tomasz Kepczynski 2005-09-02 06:56:46 EDT
It looks like this patch:
implements RFC3484.
Comment 4 David Miller 2005-09-02 16:12:12 EDT
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.
Comment 5 Dave Jones 2005-11-10 15:29:21 EST
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.

Thank you.
Comment 6 Tomasz Kepczynski 2005-11-11 08:02:36 EST
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.
Comment 7 David Miller 2005-11-11 16:51:27 EST
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
no idea.
Comment 8 Dave Jones 2005-11-12 01:38:29 EST
I'll do a 2.6.15 backport to FC4 shortly after its release.
Comment 9 Dave Jones 2006-02-03 02:27:38 EST
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.

Thank you.
Comment 10 Tomasz Kepczynski 2006-02-05 10:03:39 EST
Seems to work fine on 2.6.15-1.1830_FC4.

Note You need to log in before you can comment on or make changes to this bug.