Linux IPv6 source address selection rules are described here: http://www.davidc.net/networking/ipv6-source-address-selection-linux In case of a tie, "Linux chooses to use the latest address added". A very common tie is where a host has a SLAAC (Stateless address auto-configuration) address as well as one or more statically assigned ones in the same /64. The SLAAC address will almost always be the most recently "added" one, as it is renewed with every Router Advertisement on the network, and there will be a tie for all other rules. As a consequence, the kernel chooses this address by default for outgoing connections. This is usually not the preferred scenario; the static address will more likely have proper reverse DNS, be configured in ACL's, etc. This has been discussed on the ipv6-ops mailing list (ipv6-ops@lists.cluenet.de), and a better suggestion for a tie-breaker came out: the preferred lifetime of the address. SLAAC addresses will have a limited preferred lifetime (as defined by the router), static addresses will usually have an unlimited preferred lifetime (0). So it makes a lot of sense to take this preferred lifetime into account for source address selection (how is it otherwise "preferred"?). This could be added as rule #9 before using the most recently added as a final tie breaker? Geert
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 7 Feb 2011 16:15:16 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=28512 > > Summary: IPv6 SLAAC address preferred over static one as source > address > Product: Networking > Version: 2.5 > Kernel Version: 2.6.36 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV6 > AssignedTo: yoshfuji@linux-ipv6.org > ReportedBy: ghen@telenet.be > Regression: No > > > Linux IPv6 source address selection rules are described here: > http://www.davidc.net/networking/ipv6-source-address-selection-linux > > In case of a tie, "Linux chooses to use the latest address added". > > A very common tie is where a host has a SLAAC (Stateless address > auto-configuration) address as well as one or more statically assigned ones > in > the same /64. The SLAAC address will almost always be the most recently > "added" one, as it is renewed with every Router Advertisement on the network, > and there will be a tie for all other rules. > > As a consequence, the kernel chooses this address by default for outgoing > connections. This is usually not the preferred scenario; the static address > will more likely have proper reverse DNS, be configured in ACL's, etc. > > This has been discussed on the ipv6-ops mailing list > (ipv6-ops@lists.cluenet.de), and a better suggestion for a tie-breaker came > out: the preferred lifetime of the address. > > SLAAC addresses will have a limited preferred lifetime (as defined by the > router), static addresses will usually have an unlimited preferred lifetime > (0). So it makes a lot of sense to take this preferred lifetime into account > for source address selection (how is it otherwise "preferred"?). > > This could be added as rule #9 before using the most recently added as a > final > tie breaker? > > Geert
From: Andrew Morton <akpm@linux-foundation.org> Date: Mon, 7 Feb 2011 15:20:48 -0800 >> SLAAC addresses will have a limited preferred lifetime (as defined by the >> router), static addresses will usually have an unlimited preferred lifetime >> (0). So it makes a lot of sense to take this preferred lifetime into >> account >> for source address selection (how is it otherwise "preferred"?). This is debatable. One could just as easily say that an address with a shorter preferred lifetime has been revalidated more recently, and therefore is more likely to be uptodate, valid, and lead to a usable path. I think the lack of specification for the final tie-breaker in the RFC was intentional :-) The specification has to address this, and until the situation is more clear cut than it is now I don't see any benefit for changing Linux's behavior. Especially since there is a configuration based workaround which works for people in the short-term. But I'm willing to be convinced, and those wanting to convince me can post a patch for review to netdev@vger.kernel.org :-)
On Tue, Mar 29, 2011 at 17:20:00 -0700, David Miller wrote: > This is debatable. > > One could just as easily say that an address with a shorter preferred > lifetime has been revalidated more recently, and therefore is more > likely to be uptodate, valid, and lead to a usable path. There we're at "most recent" again. In practice, this will often be a SLAAC address, which will rarely be preferred over a staticly configured one. > I think the lack of specification for the final tie-breaker in the RFC > was intentional :-) > > The specification has to address this, and until the situation is more > clear cut than it is now I don't see any benefit for changing Linux's > behavior. Especially since there is a configuration based workaround > which works for people in the short-term. What workaround are you referring to? Geert
From: Geert Hendrickx <geert@hendrickx.be> Date: Wed, 30 Mar 2011 09:31:39 +0200 > What workaround are you referring to? The script posted at: http://www.davidc.net/networking/ipv6-source-address-selection-linux to mark the addresses as deprecated.
From: Geert Hendrickx <geert@hendrickx.be> Date: Wed, 30 Mar 2011 11:11:15 +0200 > On Wed, Mar 30, 2011 at 09:00:25 +0000, bugzilla-daemon@bugzilla.kernel.org > wrote: >> The script posted at: >> >> http://www.davidc.net/networking/ipv6-source-address-selection-linux >> >> to mark the addresses as deprecated. > > That requires you to know the SLAAC address (and thus the MAC address) in > advance, so not always applicable. It's also no longer "stateless auto > configuration" if you have to hardcode the address in your startup config. I said there was an existing workaround, I did not say it was perfect. And in that context it's reasonable for me to require real guidance from the IETF before we make a change.
On Wed, Mar 30, 2011 at 09:00:25 +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > The script posted at: > > http://www.davidc.net/networking/ipv6-source-address-selection-linux > > to mark the addresses as deprecated. That requires you to know the SLAAC address (and thus the MAC address) in advance, so not always applicable. It's also no longer "stateless auto configuration" if you have to hardcode the address in your startup config. Geert