Linux source address selection vs. EUI-64

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Sat Nov 13 23:07:15 CET 2010


On Sat, 13 Nov 2010 21:07:26 +0100
Geert Hendrickx <ghen at telenet.be> wrote:

> On Sat, Nov 13, 2010 at 01:35:48PM -0600, Frank Bulk wrote:
> > If in the physical world a network administrator would assign a /64 per
> > network segment (the prefix shouldn't be longer) for one or more servers or
> > workstations in a broadcast domain, then it should hold that each customer
> > in a virtual environment should have at least a /64, no smaller, for 1 to n
> > servers.  
> > 
> > For all the customers in a virtual environment to share one /64 and then use
> > a /96 out of it for their own address space suggests that the hosting
> > provider is still thinking in IPv4 terms.
> 
> 
> I don't see the problem here since everything is inside one broadcast domain,
> no routing involved, and everything within my own /96 is statically assigned
> so I don't need a /64 to guarantee uniqueness of addresses.
> 
> 
> Anyway, this thread is diverging from the original question; how can I make a
> statically assigned address take preference over an auto-configured address on
> a Linux host?
> 
> Disabling SLAAC is one option, but not the preferred one.
> 

I don't think there is any other option at the moment.

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, and as static IPv6 addresses have infinite preferred
and valid lifetimes, they should always win. I've experimented, and
that isn't what is happening. As you've said, the most recent address
seems to be used, regardless of the preferred lifetime value. That
surprised me, because the fundamental purpose of the preferred lifetime
is to indicate how long an address should be preferred to be used, if
all other things are equal. I think the largest value preferred lifetime
should always win. Resorting to the most recently configured could be a
reasonable tie-breaker when there are multiple candidate addresses left
which have equal preferred lifetimes.

The RFC3484 rules don't seem to say much about address lifetimes other
than avoid deprecated addresses.




> 
> 	Geert
> 
> 
> -- 
> Geert Hendrickx  -=-  ghen at telenet.be  -=-  PGP: 0xC4BB9E9F
> This e-mail was composed using 100% recycled spam messages!


More information about the ipv6-ops mailing list