v6 & DSL / Cable modems

Sat Feb 7 18:51:35 UTC 2009

On Sat, Feb 07, 2009 at 07:51:36PM +1300, Nathan Ward wrote:
> I'm not sure, but you seem to be implying that you need to configure hosts 
> to tell them to use RA or DHCPv6 to get addresses. My apologies if this is 
> not your intention.

Close, but it is worth clearing up.

> RA messages are always going to be sent by routers and received by hosts, 
> even if DHCPv6 is being used for address assignment.

Most clients "default out of the box" to accept RA, getting a single
address within each prefix indicating automatic address assignment.
The ones that do support DHCPv6 will also initiate DHCPv6 services
based on RA M and O flags.  There are some bugs here and there, but
it mostly works.  This is all well and good, you are right on these
points.

However, Jack was referring to a practice of "temporary address"
assignments.  In this configuration, a client has one "permanent" (for
as long as they are on that wire) address they use (per prefix,
because that is how IPv6 multihomes, so they say) for general purpose
and reachability from the outside world ("dial in").  They also have a
range of "temporary" addresses which are in a state of preferred use,
unpreferred use, or validity-timer expiration (again, per prefix, for
multi-homing).

Each temporary address is allocated based on a re-hash of a previously
used seed, and half of the seed bits are not used in the public
address (so outsiders can not easily predict what the client's next
address will be).

The theory is that these temporary addresses enhance privacy, as
the client seems to hop from address to address.  This seems to ignore
application context hints such as cookies and keys embedded in URL's,
so to my thinking the point of this is to enhance privacy for
spammers or illegal file sharers.

Anyway.

So far as I am aware, this is default behaviour only on certain
versions of Mac OSX, and must be explicitly enabled on all others.
Manually, on the console.  RA does not dynamically distribute this
behaviour; the client has to choose it.  Usually it is a sysctl or
a registry variable or the like.

Conversely, with DHCPv6, clients that support "normal" and "temporary"
addresses simply always ask for them; this indicates they possess
support.  The service determines which type of address to actually
provide (one, the other, both, with multiple bindings in either).  In
this way, all is automated from a central point.

The philosophies of design of these two systems are entirely at odds.

In RA the client determines what configuration it seeks, placing its
own arbitrary demands upon the network, but still heeds some of its
vague handwaving.  In DHCPv6, the client submits to the network's
will, but still has some of its own vague handwaving choices.

It is Marxism (turned Socialism) vs Fascism at its root.

I hope I have not spent my year's worth of NANOG tolerance for DHCP
related discussions with the above.  :)

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090207/e82e1e3d/attachment.sig>