The stupidity of trying to "fix" DHCPv6
mysidia at gmail.com
Mon Jun 13 01:42:33 UTC 2011
On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell <bicknell at ufp.org> 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.
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;
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.
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.
There is a potential for greater issues on networks where the number
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
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
More information about the NANOG