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

[Lorenzo Colitti <[e-mail]>]

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