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