Hi Tim, Hints Node Reqs I agree. Hints in others I never agreed to at all. That does not mean that is not the case but lets be clear here people are running agendas and that is a fact. DHCPv6 will be used by users and required. If we do draft language that states its MAY and we feel we have consensus that is fine but I will keep I-TOLD-YOU-SO cards on all who supported it when the market barfs on it :--). Seeing the mail I believe it was still for debate. Declare victory Tim and we can move on but don't be so naieve to believe the entire market is going to use stateless because we say so that will not happen. At this point I prefer completed drafts to RFC is my priority. Regarding the matrix m/o all are possible and should be supported.
/jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tim Chown > Sent: Thursday, August 19, 2004 8:31 AM > To: [EMAIL PROTECTED] > Subject: Re: M=1/O=0 is not valid in full 3315 ? > > Hi Jim, > > I thought we had reached a concensus that the O/M flags were > now only hints, as part of the IPv6 Node Requirements text > (in 4.5.5 and 5.2), and the 2462-bis update, under Section 5.2. > > On the requirement to implement stateless support in nodes, > it's only a MAY in the Nodes Requirements draft, but with a > health warning: > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- > 3315] is the standard stateful address configuration protocol; see > section 5.3 for DHCPv6 support. > > Nodes which do not support Stateful Address > Autoconfiguration may be > unable to obtain any IPv6 addresses aside from link-local addresses > when it receives a router advertisement with the 'M' flag (Managed > address configuration) set and which contains no prefixes > advertised > for Stateless Address Autoconfiguration (see section 4.5.2). > Additionally, such nodes will be unable to obtain other > configuration information such as the addresses of DNS servers when > it is connected to a link over which the node receives a router > advertisement in which the 'O' flag ("Other stateful > configuration") > is set. > > I recall the DHCP M/O flag processing text in the Nodes > Requirements draft in 5.2 was written in a way to avoid > stating must or may for the processing of M/O flags, so that > RFC2462-bis is the definitive guidance. > > I think Node Requirements is now rev 10 after IESG > feedback(?) so is pretty much final (but I may be wrong :) > > Tim > > On Thu, Aug 19, 2004 at 07:59:00AM -0400, Bound, Jim wrote: > > The key is the ongoing debate of stateless vs stateful and members > > working their agendas for their products. The bottom line is the > > users will use stateful and stateless and we need a way to > permit that > > and also inform implementors that both stateful and stateless are > > required for clients. That is the bottom line. How we say > it seems > > to be still a debate. > > /jim > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > > > Of Ralph Droms > > > Sent: Wednesday, August 18, 2004 7:01 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: M=1/O=0 is not valid in full 3315 ? > > > > > > Ignoring the issue of whether the service available when 0=1 is a > > > subset of the service available when M=1 for a minute... > > > > > > Practically speaking, even if we legislate that an RA is > not allowed > > > to have M=1/O=0 or M=1/O=1, in practice, at some point, some host > > > will receive an RA with one of those disallowed flag > settings. My > > > guess is that a client will > > > *not* ignore the input and log an error meesage. > > > Rather, the client will try to interpret the bits - perhaps > > > interpreting each bit as indicating availability of each servie > > > individually? - and make a good choice about using DHCP. > > > > > > Suppose a host has a local policy that it does not need to obtain > > > addresses through DHCP (e.g., it has manually assigned > addresses), > > > and receives the disallowed combination M=1/O=0. > > > If I were writing a client, I would have that client first try an > > > Information-Request exchange. If that exchange receives no > > > response, I would have the client send a Discover > message, without > > > asking for the assignment of any addresses. > > > > > > My recommendation is not to bother disallowing any specific > > > combinations of M/O bits and give simple guidelines to client > > > implementors... > > > > > > - Ralph > > > > > > On Wed, 18 Aug 2004, S. Daniel Park wrote: > > > > > > > (Just for easy tracking of this thread, I am slighly > changing the > > > > subject) > > > > > > > > As I described in this draft, 3736 is definitely subset of > > > 3315, thus, > > > > a host implementing 3315 can do both or either Stateful > DHCPv6 for > > > > configuring the IPv6 address and Stateless DHCPv6 for the other > > > > information. Also M=1/O=0 can be invalid state based on > > > admin policy. > > > > However, originally we tried to propose what scenarios with > > > M/O flags > > > > were possible. It means that we did not enforce any > > > specific scenario > > > > in this document because it can be easily done by admin policy. > > > > Thus, I (personally) would keep this combination in valid state. > > > > > > > > Besides, as jinmei indicated earlier as editor of 2462bis, > > > M flag (ON) > > > > indicated that the host (should) use the stateful protocol > > > for address > > > > autoconfiguration. This should mean the M flag (ON) indicates > > > > Solicit/Advertise/Request/Reply. > > > > > > > > > > > > > > > > - Daniel (Soohong Daniel Park) > > > > - Mobile Platform Lab. Samsung Electronics. > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- IETF IPv6 working group mailing list [EMAIL PROTECTED] > > > > Administrative Requests: > > > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > > > ------------------------------------------------------------------ > > > > -- > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative > > > Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [EMAIL PROTECTED] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
