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 --------------------------------------------------------------------
