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

Hi Mark,

The router doesn’t need to implement DHCPv6 server; it can implement DHCPv6
relay, or it can not implement DHCPv6 at all and it will continue to work the way it
always has.

Your argument about  having to update router firmware when a new DHCPv6
option is specified is no different than the case when a new IPv6 ND option is
specified – both are applications, and updates to either would need to be
accommodated. With this proposal, we get a unified stateless/stateful service
that can natively handle all IPv6 autoconfiguration services now and into the
future.

Thanks - Fred

From: Mark Smith [mailto:markzzzsmith@gmail.com]
Sent: Tuesday, November 21, 2017 11:19 PM
To: Sander Steffann <sander@steffann.nl>
Cc: Templin, Fred L <Fred.L.Templin@boeing.com>; dhcwg@ietf.org; v6ops@ietf.org; 6man@ietf.org
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

On 21 Nov. 2017 10:34 am, "Sander Steffann" <sander@steffann.nl<mailto:sander@steffann.nl>> wrote:
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,

So how often do you want to upgrade router firmware? Everytime you want to deploy an application that uses a new DHCPV6 option?

What do you do when the router vendor says, "we're never going to implement that new DHCPV6 option in that router model, we don't have enough customers any more for that model to justify all the development and testing time". Never deploy the application?

What do you do if the router before says, "that DHCPv6 option is on our implementation road map, we're expecting to implement it in 6 months time."? Wait six months before you deploy the application?

Pushing layer 4+ configuration options into ND creates a dependency on router firmware for application deployment that doesn't exist today in either ND or DHCPV6.

Another example of this trap. Remember that NTP amplification DoS from 3 or 4 years ago? One place I'm aware of were using their PE routers to also provide customers with NTP time, and the router implementation was vulnerable. From memory, the vendor took around a week to release a fix. Then the next 6 to 8 weeks were spent organising high impact change controls because router firmware upgrades either required reboots or there was a hazard of one. The number of PE routers was in the 10s, imagine time and effort, and vulnerability exposure time if there were 100s or 1000s of PE routers providing NTP time to customers.

Compare that to if the NTP service/application was not "in" the network, not "in" the routers' control planes, and as service reachable over the network. Only patches to the NTP servers would have been necessary, and there would have been far fewer of those.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------