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): kernel-2.6.12-1.1398_FC4 How reproducible: always 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.
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.org mailing list so that it can be discussed with the USAGI project and other IPV6 experts more thoroughly.
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. Reopening.
It looks like this patch: ftp://ftp.linux-ipv6.org/pub/usagi/stable/split/usagi-linux26-stable-20050714-2.6.10.diff.bz2 implements RFC3484.
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. Thank you.
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 no idea.
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. Thank you.
Seems to work fine on 2.6.15-1.1830_FC4.