nanog mailing list archives
Re: The stupidity of trying to "fix" DHCPv6
From: Jimmy Hess <mysidia () gmail com>
Date: Sun, 12 Jun 2011 20:42:33 -0500
On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell <bicknell () 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 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. 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. -- -JH
Current thread:
- The Business Wisdom of trying to "fix" DHCPv6, (continued)
- The Business Wisdom of trying to "fix" DHCPv6 Cutler James R (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Matthew Reath (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Daniel Roesen (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Iljitsch van Beijnum (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Leo Bicknell (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Ingo Flaschberger (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Iljitsch van Beijnum (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Matthew Palmer (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Leo Bicknell (Jun 12)
- Re: The stupidity of trying to "fix" DHCPv6 Jimmy Hess (Jun 12)
- RE: The stupidity of trying to "fix" DHCPv6 Kelly Setzer (Jun 13)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 13)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 13)
- Re: The stupidity of trying to "fix" DHCPv6 Leo Bicknell (Jun 13)
- RE: The stupidity of trying to "fix" DHCPv6 Kelly Setzer (Jun 13)
- Re: The stupidity of trying to "fix" DHCPv6 Joel Jaeggli (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 16)
- Re: The stupidity of trying to "fix" DHCPv6 Ricky Beam (Jun 13)
- Re: The stupidity of trying to "fix" DHCPv6 Joel Jaeggli (Jun 13)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 14)