RE: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

["Bernie Volz (volz)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
[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
--------------------------------------------------------------------