implementing dhcpv6

[David W. Hankins]

On Wed, Nov 04, 2009 at 02:31:52PM -0500, Chuck Anderson wrote:
> The idea of RA is to colocate the routing configuration information 
> (prefixes, gateways) with the actual routers.  You already have to 
> configure this information in the router in order to correctly route, 
> so why not have the router also hand this information to clients?  
> There is less chance of error.

The answer is that the routers, and RA's principle of operation,
does not have any of the information about which clients are to be
conferred which configuration.  This includes assigning addresses
and making clients selectively aware of both prefixes and gateways.

Configuration includes the information RA confers.  You do want to
deliver different configuration to different clients sometimes.

But RA's are simple broadcasts to all clients, not unicasts to
individual clients to confer client-specific configuration such as
DHCPv* does.

Amazingly, the "solution" to this problem is to locate RA in your
switches, so that the switch may fabricate per-port specific
broadcasts, presuming a 1:1 ratio of client system with port
assignment.

But mostly it brings us full circle on the "because routers know
better" often quoted argument for RA:  If RA on the routers is
because routers know better, are we doing RA on the switches because
switches know best?

I think the clients' operator knows best, and that isn't the router
operator de facto; it's whoever runs the office's DHCP server(s).

The truth is that the IETF is enamored with creating a fertile
environment for an endless sea of middle-ware, conferring upon
themselves the unalienable right to value-add.  DHCPv6 is sadly
not an exception, it is also slightly complicated out of a desire
to support middle-men, but this is less confusing since for security
DHCPv4 often relies on these in-the-middle devices (which the IETF has
found impossible to standardize), and on the whole, being an
implementer of both, I'd say DHCPv6 comes out ahead of the game in
terms of handling the compromises of simplicity and feature additions.

In the pursuit of this value-add, RA was designed to mimic Appletalk
according to the records (because clearly we have a great deal of
operational experience and success with building global,
interconnected Appletalk networks?) at the expense of ignoring all we
learned from IPv4, and complicating the operational (for the
operators) and functional (for the clients) implementation.

But that's humans for you.

> You also gain the property of fate-sharing.  So if a router goes down, 
> it no longer advertises itself as an available router for the link.  
> Clients will automatically choose another router on the link (perhaps 
> one that had a lower preference initially).

Unfortunately, RA's router timer is in the order of seconds.  Because
you don't want your clients losing routers within a second due to
edge timing (where the TTL is decremented once a second at the start
of each second, a router advertising 0.8 seconds into this second will
have their route revoked 0.2 seconds later, and may only be
braodcasting their presence 3 times a second (0.3 seconds)), this
means you are probably using some number of seconds greater than or
equal to 2 at very bare minimum (many router implementations enforce a
minimum of 3, refusing to take a smaller configuration).  I believe
the defaults are often ~1800 seconds.  That is not a typo, one
thousand, eight hundred seconds, that's half an hour.  The default.

If you're not tweaking the values on all your ports individually, you
are asking your clients to share fate with their routers in 30 minute
blocks.

But that's the sort of thing the current IETF loves.  They love to
imagine people fine tuning the network, fully aware of every cog and
gear and how to come by the best set-points for them.  Because that
creates a job for men in the middle.  You either have to optimize
every knob yourself or ultimately pay someone to do it.

Compare with VRRP which can provide fault tolerance on millisecond
scale without coupling configuration fate with functional fate (if
you lose your RA, you lose prefix configuration, which means some
clients cannot reach others on the same wire even though they all have
valid addresses from DHCPv6...without the prefix these clients can't
find a route to try ND).


Anyway, you asked the question, and I don't think I've ever recorded
my answers on dhcp-users@, so this is meant to be a brief summary.
It's my opinion that RA will go the route of IPv4 ICMP Router
Discovery in the fullness of time, and I'm trying to prepare us for
that.  Mostly, I just think history repeats itself.

DHCPv6 without RA is the future.  The only question is if we're going
to get there with IETF consensus or without it.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20091105/c61a47e4/attachment.bin>