Bug 5200 - Wrong source IPv6 address selected for destination
Summary: Wrong source IPv6 address selected for destination
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV6 (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Diego Calleja
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-07 06:14 UTC by Tomasz Kępczyński
Modified: 2006-07-30 10:08 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.12
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Tomasz Kępczyński 2005-09-07 06:14:40 UTC
Distribution:         Fedora Core 4
Hardware Environment: x86_64

Problem Description:

This problem has been filed on FC4 and is reported here as upstream fix
(ie. in kernel) is needed.
Original report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166636

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
quick code review of vanilla 2.6.13 kernel shows that the problem also
is there

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.
Rules for IPv6 source address selection are described in RFC3056. For now
it looks like kernel picks the first address with the same scope as
destination found on outgoing interface.
It looks like USAGI project has this implemented in this patch:
ftp://ftp.linux-ipv6.org/pub/usagi/stable/split/usagi-linux26-stable-20050714-2.6.10.diff.bz2
Comment 1 Andrew Morton 2005-09-07 13:27:07 UTC

Begin forwarded message:

Date: Wed, 7 Sep 2005 06:14:45 -0700
From: bugme-daemon@kernel-bugs.osdl.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 5200] New: Wrong source IPv6 address selected for destination


http://bugzilla.kernel.org/show_bug.cgi?id=5200

           Summary: Wrong source IPv6 address selected for destination
    Kernel Version: 2.6.12
            Status: NEW
          Severity: normal
             Owner: yoshfuji@linux-ipv6.org
         Submitter: tomek@jot23.org


Distribution:         Fedora Core 4
Hardware Environment: x86_64

Problem Description:

This problem has been filed on FC4 and is reported here as upstream fix
(ie. in kernel) is needed.
Original report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166636

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
quick code review of vanilla 2.6.13 kernel shows that the problem also
is there

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.
Rules for IPv6 source address selection are described in RFC3056. For now
it looks like kernel picks the first address with the same scope as
destination found on outgoing interface.
It looks like USAGI project has this implemented in this patch:
ftp://ftp.linux-ipv6.org/pub/usagi/stable/split/usagi-linux26-stable-20050714-2.6.10.diff.bz2

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Comment 2 Diego Calleja 2006-07-30 10:08:40 UTC
Already fixed as noticed in the RH bugzilla, so I'm closing this one aswell

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