Static vs SLAAC - Static expected to be preferred?

[Mark Smith]

Hi Benedikt,

I think the IETF 6man mailing list might be a better place to discuss
the mechanism - I presented the suggested mechanism here only to provide
some background.

So do you expect that if you configure a static address on a host it'd
be used in preference to any addresses acquired by more automated or
dynamic mechanisms, such as SLAAC or stateful DHCPv6?

Thanks,
Mark.


On Wed, 27 Apr 2011 12:48:20 +0000
Benedikt Stockebrand <me at benedikt-stockebrand.de> wrote:

> Hi Mark and list,
> 
> Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> writes:
> 
> > Suggested rule -
> >
> > Rule X: Prefer greatest preferred lifetime
> >    If the addresses SA and SB both have non-zero value preferred
> >    lifetimes (are "non-deprecated"), prefer the address with the
> >    greatest value preferred lifetime."
> 
> unless I'm mistaken this implies that in a setup with multiple
> advertising routers a host will choose the source address (without an
> explicit bind(2) in the client side application) according to the
> advertising router the host has last received a router advertisement
> from when initiating a TCP connection.
> 
> First off: In most practical cases I'd consider it good practice to
> have all routers advertise all prefixes for a subnet in a consistent
> manner, and in these cases the extra rule doesn't have any effect
> unless the lifetimes advertised are explicitly configured/manipulated;
> this appears to be fine with me if there's some benefit elsewhere from
> adding this rule.
> 
> But: In the---to my understanding more unusual---case where different
> routers advertise different prefixes, the behaviour will however be
> affected, possibly causing some "sometimes it works, sometimes it
> doesn't" behaviour that is rather tedious to track down and fix.
> 
> So your proposal may have some serious side effects.
> 
> 
> Cheers,
> 
>     Benedikt
> 
> -- 
> 			 Business Grade IPv6
> 		    Consulting, Training, Projects
> 
> Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/
>