The stupidity of trying to "fix" DHCPv6

Ben Jencks ben at
Tue Jun 14 21:01:24 UTC 2011

On Jun 14, 2011, at 4:25 PM, Leo Bicknell wrote:

> In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote:
>> This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying.

> [snipped long explanation that you do in fact need DNS servers]
> So just like in IPv4, IPv6 requires DHCP to have a functioning end user
> box.  DHCP remains a hard requirement.  The odd part now is that in IPv4
> DHCP carries the default gateway, while in IPv6 land you must also run
> Router Advertisements on your router and have the host listen to them.
> The industry has taken a robust single protocol solution and turned it
> into a dual, co-dependent protocol situation.

I'm just not seeing how this actually adds more configuration overhead. Rather than looking at a protocol count, try looking at the number of actual items you need to configure and where they get configured. This is actually *smaller* in IPv6, because the DHCPv6 server doesn't need to know what the default gateways are anymore (I have no problem with a routing information option, but that's optional, not *needed*). The fact that the information is distributed over different protocols seems to make a lot of people really pissed off, but seems ancillary to the actual issues of what information is configured where and what options are available.

> The IETF is working on one solution, which is to add DNS information to
> the RA's!  So now you'll configure your routers to hand out DNS servers
> to clients, and then everything else (NTP servers, Domain Controllers,
> etc) in DHCP!

I agree, that's never seemed like a good idea.

> What I and others are suggesting is the other way around, how about we
> just put a default route in DHCPv6 like we did in v4, and forget all
> about RA's so we're back to a single protocol solution?
> Beyond that it is important to notice that the failure modes and attack
> vectors for RA's and DHCP are different.  I argue DHCP is "better", but
> I also realize that's a very subjective judgment.  That said, there
> are cases where people may prefer DHCP's robustness and/or failure
> modes, and cases where people might prefer RA's.

There are differences in failure modes, but I'd argue that's not enough justification to fragment the configuration options. If there are two overlapping ways to configure things, then I'd bet that all but the most mainstream or high-end implementations will have poor support for at least one. That was the one you chose? Too bad, you have to support both now. So much for the "operator choice" you keep arguing for.

> Lastly, there's a hidden bit here many people haven't dealt with
> yet in lab networks.  In IPv4 critical environments it's typical
> to use HSRP or VRRP to provide a single gateway across two routers.
> The IPv6 way to do this is to have both advertise RA's, possibly
> with different priorities.

Erm, I thought the IPv6 way to do it was to use IPv6 VRRP... I've heard of some vendor bugs on it, but it's implemented.

Multiple routers sending RAs can be useful, but not for the same kind of HA that VRRP is designed for.


More information about the NANOG mailing list