Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

[Sander Steffann <[e-mail]>]

Hi,

> This document therefore proposes a unification of IPv6 ND and DHCPv6 where
> the two functions work together as if they were one. This is accommodated by
> a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By working
> together as one function, IPv6 ND and DHCPv6 can supply requesting nodes with
> all link-specific autoconfiguration information and any managed address/prefix
> delegations in a single round trip message exchange.

Interesting way of doing this. I have thought about combining ND and DHCPv6 before, but more as a different distribution mechanism: ND for pushing options to all clients on the network, and DHCPv6 for clients requesting specific options for themselves. Just to make it possible to use both mechanisms for all options (MAP/DSLite/etc options in RA would be nice).

What you are doing is another way of looking at it. If I understand correctly you're basically keeping the full functionality of DHCPv6 but using RS/RA as a transport instead of UDP. I wonder what the speed benefit of that would be in practice. Also compared to "impatient" systems that send out DHCPv6 a request before even receiving an RA.

> I would ask these discussion lists to consider what is it that you really don't
> like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way
> the acronym rolls off your tongue when you speak it. Maybe it has an onerous
> stigma of being stateful. But, then I would also ask you to consider what a
> replacement would look like. Because, I think any suitable replacement
> would have to essentially duplicate what DHCPv6 already does.

In my opinion DHCPv6 is fine. I implemented a server and it is a *lot* cleaner to implement than DHCPv4. Just plain UDP on link-local and multicast sockets :)  Especially the stateless version is very easy to implement. It's not the ultimate configuration protocol, and for certain things distributing information via RA is a much better fit to the way the network is run. But DHCPv6 has its place and its role, and in certain environments (DHCPv6-PD in ISP networks, DHCPv6 in enterprise etc) it does what the network and system operators need.

The main problem with DHCPv6 as an operator has been dealing with DUIDs when the link-layer address in the DUID is based on a different interface than the interface sending the DHCPv6 request. Mostly because the requesting interface's MAC address has always been used with DHCPv4 and is often printed on the outside of the device. But these days LDRA and DHCPv6 relays can tell the DHCPv6 server what the MAC address of the requesting interface was, and we can use that to identify the client (in addition to its DUID). With vendors starting to implement this relay option this is mostly a solved problem now.

Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure support. That could be used to take away some of the complaints against DHCPv6 (and any client-initiated configuration protocol) that there is no way for the network to inform the client of changes.

I see no need to replace it with something else that would indeed need to duplicate its functionality.

Cheers,
Sander