I don't know what is complex here this is all obvious today with current wording. Even if DHCPv6 is used for addresses, statless is still required as a note too. This is not an implementation problem I see at all.
Of those speaking how many of you when writing your code got stuck and that might help this discussion? This has been going on to long. Our specs need to work whether someone uses them or not that is not our job here. thanks /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Iljitsch van Beijnum > Sent: Monday, May 23, 2005 8:48 AM > To: Ralph Droms > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: Re: meta thoughts on m/o bits > > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
