On Jun 12, 2011, at 6:42 PM, Jimmy Hess wrote:
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.
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 too. 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 dual-stack.
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. Owen