On 20-mei-2005, at 21:06, Ralph Droms wrote:
In some scenarios there is a danger in the following approach:
- hosts boots
- looks for DHCP server, doesn't find one
- Keeps looking every couple of minutes
Yes, this would clearly be harmful in cases where hosts both use
DHCPv6 and stateless autoconfiguration, but no DHCPv6 server is
available. This especially adds up when there are many hosts on the
subnet.
A client is free to use some other timeout (2 hours instead of 2
minutes?) if it chooses.
How is this useful? Either I want to know that a DHCPv6 server has
become available, so waiting 2 hours is way too long, or I don't
care, so why bother checking in the first place?
The situation where a server broadcasts its existence makes MUCH more
sense.
But the real question is: how do we know we want to use DHCPv6 in the
first place? Obviously in many cases the answer is simple: yes, I
want it all the time, or no, I never want it.
But suppose some networks adopt DHCPv6 in lieu of stateless
autoconfiguration for reasons that make sense to them (and work
elsewhere, such as shim6, _may_ make this a somewhat more likely
situation). It would then make sense for a laptop or similar client
to have both stateless autoconfiguration and DHCPv6 on board for
autoconfiguration. However, such a client wouldn't have any idea
about the availability of either mechanism or their preference. Since
presumably, DHCPv6 won't be available in many cases, an agnostic host
wouldn't want to wait for DHCPv6 to fail when stateless autoconfig is
available. On the other hand, some admins may strongly prefer hosts
to use DHCPv6, but provide stateless autoconfig as a fallback for
hosts that don't support DHCPv6. In that case, it would be better to
ignore stateless autoconfig altogether when DHCPv6 works. The real
problems start when DHCPv6 is preferred, but there is some kind of
failure. Obviously the host should use stateless autoconfig in the
mean time, but it would be useful if it were to switch to DHCPv6 as
soon as the server becomes available.
So what we really need is a mechanism that says:
- DHCPv6 isn't available so don't bother with it
- DHCPv6 is available, but use stateless autoconfig unless you can't/
won't
- DHCPv6 is available and equal to stateless autoconfig, use either
but no need to use both
- DHCPv6 is available and equal to stateless autoconfig, use both
- DHCPv6 is available and preferred, use it exclusively if you can
Something similar is probably needed for the O flag.
In addition, it would be useful to have some kind of flag that
indicates that the DHCPv6 server status has changed so hosts should
refresh their leases and other information.
Obviously all of this can't be accommodated with two bits in RAs. So
we can:
- forget the whole thing and let the implementers/admins figure it out
- hammer on it until it fits in the m and o bits
- come up with an RA/ND option that has room for all of this
(It would be cool to find a way to integrate DHCPv6 and RAs to some
degree, though. For instance, by allowing DHCP options in RA options.)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
