Re: Brokenness of specs w.r.t. client behavior with M&O bits

[Ralph Droms <[e-mail]>]

I'd like to encourage serious and thoughtful conversation about this  
topic.  Thomas is right (I know he's right, because I agree with him)  
that the current text in various RFCs is unclear.  Even if it does not  
conflict with the previous consensus about how to deal with the M/O  
flags, the text does not completely describe that consensus in a way  
that implementors can use to guide development and admins can know  
what to expect from DHCPv6 clients.

This topic was also considered in an earlier thread discussing draft- 
cha-ipv6-ra-mo-00.txt.

The previous consensus about M/O flags, as I understand it, is  
described in the text Thomas quotes form RFC 4861; those flags  
indicate the existence of DHCPv6 service and nothing more.  My  
recollection is that there was no consensus on guidance to hosts about  
what to do with that information from the M/O flags, so (in response  
to Thomas' first question) an implementor is free to build any  
behavior into the DHCPv6 client including "always", "only if M or O  
flag is set", "never".  In my opinion, the existing text needs to be  
extended to completely explain that previous consensus; for example,  
by adding "Note: The DHCPv6 client behavior in response to the receipt  
of M and O flags is unspecified." somewhere in RFC 4861.

It may also be the case that we want to reconsider our previous  
consensus, to give an explicit answer to the question about when to  
run DHCPv6.  draft-cha-ipv6-ra-mo-00.txt gives one possible  
redefinition for those bits.  We have other suggestions ranging from  
"ignore M/O and always run DHCPv6" to "revert to RFC 246[12] and  
disallow DHCPv6 if M/O flags aren't set".  In my opinion, the former  
suggestion sounds perfectly reasonable as a way to simplify the specs  
and the implementations - I have heard it the necessary APIs to get  
the status of M/O flags to a userland DHCPv6 client may not exist in  
some OSes.  The latter makes sense if there is a compelling reason to  
guarantee there is no DHCPv6 traffic on a link.

- Ralph

On Oct 13, 2008, at Oct 13, 2008,11:40 AM, Thomas Narten wrote:

> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------