OK, I'm going to wade back into this and say that I believe we've botched things. Let's take a typical client implementor, who looks at, say, RFCs 4861, 4862 and/or RFC 3315 (the DHCPv6 spec).
Question: just when are they supposed to invoke DHCPv6? All the time? Only if the M or O bits are set? This simply isn't clearly defined. This is broken and teh IETF really needs to make a recommendation. Background: RFC 3315 (the DHCPv6 spec) says: IPv6 Stateless Address Autoconfiguration [17] specifies procedures by which a node may autoconfigure addresses based on router advertisements [13], and the use of a valid lifetime to support renumbering of addresses on the Internet. In addition, the protocol interaction by which a node begins stateless or stateful autoconfiguration is specified. But, the two references above point to RFCs 2461 and 2462, which have been obsoleted. In theory, implementors should be able to look in RFC 4861 and 4862 instead to get the proper guidance. Unfortunately, they won't find clear guidance. RFC 4861 (the ND spec) talks about what to do with the M&O bits, but only from a router's perspective, i.e., it includes configuration knobs for setting the bits in outgoing RAs. That is all fine, but doesn't address what a client implementation should do. The text does say (in the context of defining the bits): M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. But this is very general, and doesn't provide clear guidance to an implementor. RFC 4862 is completely silent on what to do. It only says (in the "changes" section): o Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences. ManagedFlag and OtherConfigFlag were removed accordingly. (Note that this change does not mean the use of these flags is deprecated.) This is broken. Implementors should be able to look at the (current) specifications and get clear advice on what to do. And, are we saying, in fact, that RFC 2461 has not _really_ been obsoleted and implementors should look at the older RFCs for guidance? I hope not! Oh, and the Node Requirements specification isn't much better. draft-ietf-6man-node-req-bis-01.txt: says: 6.2.1. 5.2.1. Managed Address Configuration The method by which IPv6 nodes that use DHCP for address assignment can obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the \'M' flag set is described in Section 5.5.3 of RFC 4862. (RFC 4862 says no such thing actually!) In addition, in the absence of a router, those IPv6 nodes that use DHCP for address assignment MUST initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of RFC 4862. Those IPv6 nodes that do not use DHCP for address assignment can ignore the 'M' flag in Router Advertisements. Again, RFC 4862 simply doesn't say the above. It uses "may" language, and even that is indirect: 5.5.2. Absence of Router Advertisements 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]. So, I think we have made a mess of things and we need to fix things. I will assert that the fundamental problem we have is that we have not yet agreed on when a client should invoke DHCP. Our options are: 1) We could ignore/deprecate the M&O bits and simply have any client that implements DHCP invoke DHCP without even bothering to see what the M&O flags say. I.e, the way DHCPv4 works today. IMO, this approach would work fine. Indeed, it has the advantage that the client won't do the wrong thing due to misconfigured routers sending out M&O bits with the wrong setting. The main downside is that operators would have no way of signalling to clients that DHCP isn't available and they shouldn't waste resources trying to invoke it. In the past, there has been endless(?) debate about how significant the "waste" would be. 2) We could restore the M&O bits, and tie DHCP invocation to the settings of those bits. This is what 2461/2462 did, and was the original model. But, there is still a number of choices to be made here: a) Treat the M&O bits as SHOULDs, meaning exactly that. If the bits are set, one SHOULD invoke DHCP, but it is NOT a MUST requirement. If one choses (for whatever reason) not to honor the bits, so be it, but it is not a protocol violation per se. This is the approach 2462 took, though it used lower case shoulds. b) Treat the M&O bits as MUST. You MUST invoke DHC if they are set, and it is a protocol violation to not do so (if you have implemented DHC, i.e., you have a non-complient DHCP implementation). c) One could also say one MUST NOT invoke DHCP *unless* the M&O bits are set. Some people/operators wanted such behavior because they wanted a way of indicating that no DHCP servers are present, and that clients shouldn't waste network resources invoking DHCP (this was asserted to be a potential issue on some types of wireless WANs). Others argued that a robust client would be foolish to rely on the proper settings of those M&O bits, as it could lead to (unncessary) failures if routers were misconfigured, but DHCP servers were available. [this leads back to the call for option 1) above] In summary, the current specs are not clear on when a client should invoke DHCPv6 and when not. That is broken and should be fixed. I also suspect that it it less important *which* approach we adopt, than that we do actually choose one and document it. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------