Static vs SLAAC - Static expected to be preferred?

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


Hi Mark and list again,

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

> That's true. Privacy addresses seem to be covered by rule 7, which
> refers to them as temporary addresses, with non-privacy addresses
> referred to as public addresses. By default is says to prefer public
> addresses, unless overridden by an application via an API, or if
> privacy is enough of a concern, then it is acceptable to prefer privacy
> addresses over public addresses.

unfortunately, last time I checked no such API existed.  Instead at
least the various Unixen (Linux, BSD, IIRC Solaris) I gave a try had a
global kernel configurable to change that default behaviour.

The reasoning in RFC 3484 for defaulting to the permanent addresses is
that long-running connections will break when they use a temporary
address that becomes invalid.  One might argue that a protocol that
can't deal with a connection failure every week or so is itself
broken, but with privacy extensions entering the arena at such a late
time this decision does have its merits.

Without a standardized API a somewhat heavy-handed option is to have
the application do an explicit bind(2) on the socket.  This is
feasible but either requires the application to deal with things it
shouldn't bother with (likely including routing sockets, which aren't
readable to non-privileged users in some implementations), or needs
another knob to manually (mis-)configure.

In a different context than the one you (Mark) are concerned with this
becomes particularly annoying: One-way UDP traffic, like syslog or
assorted multicast based protocols---think source-specific multicast
here.


Finally: In the scenarios I've seen with customers I frequently advise
to put servers and clients in separate networks and only provider
router advertisements in the subnets with clients.  Where applicable
that makes the entire issue moot; in those cases you mentioned (SOHO,
private end user networks), how likely is it to have two "competing"
routers connected there?


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