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

Reply via email to