Linux source address selection vs. EUI-64

[Mark Smith]

On Mon, 15 Nov 2010 15:09:22 +0000
Tim Chown <tjc at ecs.soton.ac.uk> wrote:

> 
> On 13 Nov 2010, at 23:06, Mark Smith wrote:
> 
> > On Sat, 13 Nov 2010 23:50:54 +0100
> > "Steinar H. Gunderson" <sesse at google.com> wrote:
> > 
> >> Den 13. november 2010 23:07 skrev Mark Smith
> >> <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> følgende:
> >>> I'd expected that when there were multiple equal candidate source
> >>> addresses on an interface, the largest preferred life time would become
> >>> the tie-breaker
> >> 
> >> If so, would a privacy address ever get picked?
> > 
> > In the presence of a static address with infinite lifetimes, I'd think
> > not. The purposes of privacy addresses and static addresses seems
> > mutually exclusive.
> 

I'm reconsidering this. Conceptually they are mutually exclusive, until
you consider the direction of connection. Privacy addresses as sources
for outbound connections and static addresses as targets for inbound
connections seems valid, although probably a bit rare.

> Well, for source address selection the default should be the privacy address if available, ahead of any static address.     If that's not the desired behaviour, privacy address generation should be disabled.
> 

I agree that would work. However I think it would be better to avoid
treating privacy addresses as anything special in address selection
rules (generally, less "special cases" is always better I think). If a
static address has a preferred lifetime set to zero, instead of
infinite, and a valid lifetime of infinite, then I'd think the privacy
addresses (or any others with a preferred lifetime >0) would be chosen
before the static as a source address, if largest perferred lifetime is
used as the tie-breaker. That would allow static addresses for incoming
and privacy addresses outgoing connections to co-exist.

Regards,
Mark.

> The static address would be the one DNS-advertised as a destination address for new connections to the host.
> 
> Tim