The stupidity of trying to "fix" DHCPv6

Owen DeLong owen at
Tue Jun 14 02:24:34 UTC 2011

On Jun 12, 2011, at 6:42 PM, Jimmy Hess wrote:

> On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell <bicknell at> wrote:
>> DHCP today uses an exponential backoff if there is no response, I don't
>> see why that can't be kept in IPv6.  Plus I wonder how long users would
>> keep on machines that get no useable network connectivity.
>> I really think the number of broadcast packets is a total non-issue.
> Rather than deem it a non-issue; I would say The impact of broadcast packets
> depends on the network they are transmitted over.
> If you have a Layer 2 domain with 50000 hosts on it;  the number of per-host
> broadcast packets will be much more important  than  if you have a broadcast
> domain with 1000 hosts.
If you have a layer 2 domain with 50,000 hosts on it, you probably did something
very wrong in your network design to begin with. Likely you already have issues
with forwarding table exhaustion on your L2 switching infrastructure.

> This could have been (but was unfortunately not) mitigated in the v6 specs by
> adding options to DHCPv4 to configure IPv6 address and gateway  at the same
> time IPv4 configuration is received,  in lieu of using v6 based
> protocols for config;

Doing so would have created a situation where it was virtually impossible to run
IPv6 without IPv4. Clearly not a desirable outcome.

> Requiring configuration to be grabbed _two_ times per host is inefficient -- ONE
> DHCP discovery for every host on the LAN (either RA+DHCPv6 or DHCPv4) would
> be more efficient.

Only if you assume that the world will never move beyond dual-stack to IPv6 monostack.
This is an inherently bad assumption for a variety of reasons. What you are asking
would be akin to asking for a DHCPv4 option to hand out IPX and Appletalk addresses

It doesn't make sense for a wide variety of reasons even though you are correct that
for a very narrow set of cases, it could provide a slight increase in efficiency.

> If v6 hosts are dual stack, and v4 information is already pulled from
> DHCP.... how much
> sense does it really make to need a second discovery process to find a v6 server
> to config the host,  particularly when there exists possibility of
> conflicting options;  DHCP
> can config some non-interface-specific things such as time zone,  hostname, etc.

Just like v4 hosts, there are two classes of v6 hosts.

Dual stack and mono-stack. The difference is that today, v4 mono-stack is
much more common than v4 dual-stack and v6 dual-stack is much more
common than v6 mono-stack. There will come a day (possibly many
years from now) where v6 mono-stack will be more common than v6

> There is a potential for greater issues on networks where the number
> of broadcasts
> may not have been an issue for IPv4;    the IPv6 broadcast messages
> have a larger
> payload,  because there are 96 more bits in an IPv6 address than an
> IPv4 address.

Unlikely that this would become a significant issue in the real world.
The low frequency of requests, exponential backoff, and relatively
small number of likely simultaneously affected hosts all add up to a very very low
probability of significant bandwidth being used in this process.
It's not like anyone does DHCP on a DS0.

> The broadcasts for configuring IPv6 are incurred _on top_   of the broadcasts
> already existing for IPv4 on a dual stack network,  since IPv6 hosts
> still have to config
> IPv4 simultaneously.

Only if they need IPv4.

Also, remember, the IPv6 packets aren't broadcasts. They are multicast
and would go to the IPv6 All DHCP Servers Multicast group, not the
All Nodes multicast group.


More information about the NANOG mailing list