Static vs SLAAC - Static expected to be preferred?

Benedikt Stockebrand me at benedikt-stockebrand.de
Thu Apr 28 23:04:48 CEST 2011


Hi Mark and list,

Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> writes:

> Hi Benedikt,
>
> I think the IETF 6man mailing list might be a better place to discuss
> the mechanism -

sure, but right now I already find it difficult enough to sort of keep
up with ipv6-ops (though I do intend to show up in Quebec).

> 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?

If that's the point, then it may be more reasonable to modify your
rule to only distinguish between "infinite" and "finite" preferred
lifetimes; that would effectively prevent the "flapping" of source
addresses.  And even then I'm not entirely sure if this is a good
move, because in the event of a renumbering it makes statically
configured nodes (commonly servers in the naive sense) more
susceptible to using a stale address for outbound traffic.

But from a more general perspective I have a rather strong hunch that
this entire question needs a more exhaustive investigation of all
possible combinations -- which is a bit of work, but may help to avoid
missing that one combination where the algorithm blows up in someone's
face.

That said, the RFC3484 algorithms are inherently heuristic in nature,
so there may be no perfect solution---at least not if we want to stick
with the existing socket API, rather than somehow testing all source
and destination address combinations (and if so, in which order?).


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/



More information about the ipv6-ops mailing list