Ralph: Let's review where the consensus stands (though I'm not sure how much "past" history I'm including here and that may alter my preception of what I think this consenus means).
The M/O flags indicate the availability of DHCPv6 service for address assignment and other configuration information, respectively. The IPv6 specifications make no requirements on the behavior of DHCPv6 clients in response to the values of the M/O flags received in RAs. A way that this could be restated as: If the M flag is set, a DHCPv6 client MAY run (stateful) DHCPv6. If the O flag is set, a DHCPv6 client MAY run (stateless) DHCPv6. A (statless/stateful) DHCPv6 client MAY run regardless of the state of the M/O flags. Thus, from a newtwork administrator's view: If a network is using stateful DHCPv6, set the M (and O) flags. If a network is using stateless DHCPv6, set just the O flag. If a network is not running DHCPv6, don't set either of the flags. In all cases, what actually happens on the network with respect to DHCPv6 is indeterminate. The RFC 2462 text was technically just as unspecific: Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). And, later: On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, i.e., the change in the value of the ManagedFlag has no effect. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. There are "should" statements, not SHOULD. (RFC 2462 used RFC 2119 terminology in plenty of other places.) So the existing IETF consensus is really no different than was stated in RFC 2462 (though in a lot less words). I think it changed a "should" to "may", but that's not the same as changing a SHOULD to a MAY. However, it is interesting that RFC 2462 also stated: If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [DISCOVERY]. This seems to be major change in RFC 4862 as it provides a "may" in this case: Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [RFC4861]. Thus, my answers to your questions ... 1 is YES. While in many ways I'd prefer to deprecate the bits (they've caused so much debate), after the debate and working to put this email together, I think the consensus is fine. 2 is a YES, but whether to clarify the existing text is in my mind the key question. Just the fact that we're having this debate I think says a lot about the need to clarify this. I think the issue with the existing wording is that it requires a lot more thought than I think it should (such as reading through this lengthy debate). There's no easy answer for network administrators as to how they need to set the bits and for client implementers on whether they should or should not pay attention to them. And, clearly the bits are NOT deprecated. In my view, I believe encouraging implementers to use the M & O bits is a good thing (the RFC 2462 "should") but a client's local policy should be able to override that (always on, never on, or "use M&O" if possible). What client vendors ship the default as is up to them as it depends on the target customer/market. I also understand that there are complexities around integrating M/O clear to set transitions in many stacks or even finding out the state of these bits on an interface. I fear without this encouragement that the bits would eventually become completely useless and thus effectively deprecated. (It is a lot easier just to have a two way toggle - run or don't.) Thus, if we DON'T want to add clarifications somewhere (new I-D?), I think we should just move to deprecate the bits. Finally, this consensus does not prevent additional work, such as draft-cha-ipv6-ra-mo-00.txt, though obviously that work can't impose any requirements (MAY/SHOULD/MUST) on implementations to use the M/O bits - it can give guidance on what a DHCPv6 client that does use the bits may want to do if the flags transition in certain ways. Whether clients implement that is up to them (as is whether they pay any attention to the M/O bits in the first place). Perhaps this work should just be extended or reframed to provide the motivations for DHCPv6 clients to use the bits. - Bernie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralph Droms (rdroms) Sent: Friday, October 17, 2008 7:22 AM To: IPV6 List Mailing; DHC WG Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits I've been tracking this discussion about the M/O flags, which seems to be going in several different directions. I thought it might be useful to try to get some agreement on what needs to be done so we can focus on coming to consensus on a course of action. It also seems like a small group of participants has gone pretty deep into some technical details, which might be irrelevant depending on the consensus of the IETF. Here's a quick, informal survey to assess consensus about how to proceed. Please reply to the list so we can focus our discussion. Thanks. 1. Is the following text an accurate summary of the previous IETF consensus on the definition and use of M/O bits: The M/O flags indicate the availability of DHCPv6 service for address assignment and other configuration information, respectively. The IPv6 specifications make no requirements on the behavior of DHCPv6 clients in response to the values of the M/O flags received in RAs. 2. Does the IETF choose to continue to accept this consensus or should the definition of client behavior in response to the M/O flags be revisited? 2. YES: Is that consensus adequately described in the IPv6 RFCs or should the IPv6 RFCs be revised in some way to describe the consensus requirements? 2. NO: How does the IETF want to change this consensus and how should the change process be conducted? There have been some suggestions for changes to the current consensus behavior: * Deprecate the M/O flags; require that future DHCPv6 clients ignore the M/O flags; require that routers send RAs with M/O flags set to 1 * Revert to previous definitions and behaviors in RFC 286* * draft-cha-ipv6-ra-mo-00.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------