Bug 28512

(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

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

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