Description of problem: When creating an IPv6-in-IPv4 tunnel, "ip link set $dev up" is not assigning the "local" address from a previous "ip tunnel add" command, but instead is assigning *all* the local IP addresses from existing interfaces, including lo. Version-Release number of selected component (if applicable): iproute-2.6.28-3.fc11.i586 How reproducible: Always Steps to Reproduce: 1. ip tunnel add tun6to4 mode sit remote 0.0.0.0 local 1.1.1.2 2. ip link set tun6to4 up 3. ifconfig tun6to4 Actual results: tun6to4 Link encap:IPv6-in-IPv4 inet6 addr: ::172.16.9.7/96 Scope:Compat inet6 addr: ::127.0.0.1/96 Scope:Unknown Expected results: tun6to4 Link encap:IPv6-in-IPv4 inet6 addr: ::1.1.1.2/128 Scope:Compat Additional info: I discovered the problem attempting to set up a 6to4 tunnel, but I would suspect it would have implications for other cases as well. The example above uses tun6to4 as the device name, but it could be anything. To illustrate the point better, I've used an IPv4 address that does *not* correspond to one on a physical device. If there are two or more physical interfaces, all their IPv4-compatible (deprecated in favor of IPv4-mapped BTW) addresses are assigned, plus the address for lo (::127.0.0.1), as the local tunnel endpoint address. Also note that the netmask has changed from /128 to /96. My points of comparison for the behavior of /sbin/ip are F9 (iproute-2.6.27-1.fc9.i386) and RHEL5 (iproute-2.6.18-9.el5).
Ok, I have tested this on rawhide with old kernel kernel-2.6.27.15-170.2.24.fc10.x86_64 is it working as you expected. With new kernel kernel-2.6.29-0.258.rc8.git2.fc11.x86_64 it's failing.
After discussion with ifconfig maintainer you should definitely use ip instead of ifconfig ;-) Every new thing in kernel could be incorrectly interpreted by ifconfig. There was some work on tunnels lately, so it could be bug in kernel. I suppose you should use something like: ip -4 tunnel show
Okay. Using ip instead of ifconfig for the last step ... 1. ip tunnel add tun6to4 mode sit remote 0.0.0.0 local 1.1.1.2 2. ip link set tun6to4 up 3. ip addr show dev tun6to4 Actual: link/sit 0.0.0.0 brd 0.0.0.0 inet6 ::172.16.9.7/96 scope global inet6 ::127.0.0.1/96 scope host Expected: link/sit 1.1.1.2 brd 0.0.0.0 inet6 ::1.1.1.2/128 scope global F11: kernel-2.6.29-0.258.rc8.git2.fc11.i586 vs. F9: kernel-PAE-2.6.27.19-78.2.30.fc9.i686 RHEL: kernel-2.6.18-128.1.1.el5 Out of curiosity, I also tried kernel-2.6.29-0.66.rc3.fc11.i586 from the "DVD." It didn't work any better than 258.
http://bugzilla.kernel.org/show_bug.cgi?id=12868 reports On Saturday 21 March 2009, Bjørn Mork wrote: > This is fixed by commit 1b1d8f73a44fe1796a73a97ebcb08cad18b97f07 > currently in davem's net-2.6 tree. Here's looking forward to a Fedora kernel with it.
That patch was merged before 2.6.29 was released, so this should be fixed in the next kernel build.
I got impatient and snagged kernel-2.6.29-2.fc11.i586 out of koji. (I figured the alternative was to wait another week until the beta would be released.) I can verify that the bug is fixed. I'll close this report when a kernel with the fix hits rawhide.
Fixed in rawhide kernel-2.6.29-16.fc11. Closing.