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

["Templin, Fred L" <[e-mail]>]

Hi Lorenzo,

I respect your taking the time to post this useful critique, and expect that others
with a deeper background in the DHCPv6 architecture would want to respond in
detail. Thank you for sharing your thoughts.

For myself, In my environment I have mobile node clients with many routers
on the link – each of which implements the DHCPv6 relay and/or server. The
link is NBMA, meaning that multicast is not supported natively, so that the
client has to send the DHCPv6 Solicit to one or a couple of routers via LL
multicast to L2 unicast mapping. The client gets the exact same service
regardless of which router or routers it picks.

As long as the client remains on the link, it can continue to maintain the
prefix delegations it has received from its routers, and can even change to
a different set of routers if it thinks that would give better service. This is
true even if the client’s L2 addresses change, which is signaled by sending
unsolicited NAs to the routers the same as specified in RFC4861.

Again, this is just what I am doing in my environment and it gives a very
satisfactory service. What my draft is proposing is a unification of IPv6 ND
and DHCPv6 to give the best functions of both stateless and stateful
auconfiguration in a single unified package. And, if DHCPv6 would not
be suitable for supporting the stateful function, then we would have to
define something new that is.

Thanks - Fred

From: Lorenzo Colitti [mailto:[e-mail]]
Sent: Monday, November 20, 2017 10:48 PM
To: Templin, Fred L <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

On Tue, Nov 21, 2017 at 6:40 AM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
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.

As generally implemented and deployed, I think the main things that are wrong with DHCPv6 are as follows. Note that these are not necessarily limits imposed the protocol itself, but they are definitely limits imposed by the implementations and how people typically deploy them. As such, the following are not required to be true, but are only true in practice in the vast majority of deployments.

  *   In stateful form:

     *   Inability to support multiple sources of information (the client picks the first lease it gets).
     *   Very difficult to update devices when network changes because it's fundamentally based on leases and renews and RECONFIGURE is not (widely) implemented.
     *   Makes possible stateful address assignment of individual IP addresses. It's really not a good idea to rely only on this for IP addressing, but there are decades of operational practice around it in IPv4 and old habits (and legacy deployed systems) die hard.
     *   Typically deployed using relays and centralized assignment, which is very unsuited to topology changes.

        *   If all you have is a central addressing server, you don't want to bother that server with constant topology updates from all over the network so it can update the hosts.
        *   Also, if the topology changes enough, the server might even be unreachable from some hosts.

  *   In stateless form:

     *   Very hard to update devices when anything changes on the network. The minimum in the stateless DHCPv6 RFC is 10 minutes, which is *way* too long for certain types of networks like mobile hotspots.
The inability to update hosts with new network information is a crucial weakness because it forces networks to appear to hosts as if they never change. But networks change all the time. If you can't update the hosts on a timely basis about a changes, either you never change the network, or you have an outage, or you lie to the hosts. So we end up with things like VRRP and NAT to ensure the host never sees the network change.

NAT, of course, is the ultimate way of never changing anything - you could deploy IPv4 by assigning every host on every network 192.168.1.2 (gateway and DNS server 192.16.1.1) and just NATing everything with layer-2 aware NAT.