Subject: Re: Proposed M&O bits text for RFC2461bis

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Apr 2006 15:34:20 -0400

Hi Ralph.

Revisiting this thread... I think your proposed text is fine. The only
question I have is that I assume you want to be consistent in
referring to "DHCPv6lite" or "RFC3736" (both are used in the text
below.)  Also, one nit (from my original text!)

Thomas

Ralph Droms <[email-masked]> writes:

> Second try, this time with new text on top and explanation below.

>    M :
>     
>         1-bit "Managed address configuration" flag.  When set, it
>         indicates that addresses are available via Dynamic Host
>         Configuration Protocol [DHCPv6].  When the M flag is set,
>         nodes SHOULD use DHCPv6 to obtain addresses (and associated
>         configuration information) to be assigned to the interface on
>         which the RA was received.  Note that when the M flag is
>         set, the setting of the O flag is irrelevant, since the DHCPv6
>         server will return all available configuration information
>         together with any addresses.

>     O :
>     
>         1-bit "Other configuration" flag.  When set, it indicates that
>         DHCPv6 for other configuration information [DHCPv6lite] is available
>         for delivery of other (non-address) information.  Examples of such
>         information are DNS-related information or information on other
>         servers within the network. When the O flag is set,

>          - If the M flag is also set, the O flag is irrelevant (as
>            described above) and the node SHOULD use DHCPv6 to obtain
>            addresses and associated configuration information.
>        
>          - If the M flag is not set, the node SHOULD use DHCPv6 as
>            described in RFC3736.

>        Note that if neither M nor O are set, the node SHOULD NOT not

s/NOT not/NOT/

>        request any information with DHCPv6.

> In the interest of simplicity and consistency (note that the protocol in
> question is referred to as DHCP or DHCPv6 through all of specifications [as
> well as in the original version of this text], not "DHC"), I suggest the
> text above.

> Comments on previous earlier text:

>    including addresses that are likely not available via stateless address
>    autoconfiguration.

> Deleted as it adds no discernible content to the text.

>    Clients SHOULD use DHC to obtain addresses (and associated
>    configuration information) as described in [ADDRCONF].

> S/Clients/The node/
> S/DHC/DHCPv6/
> Deleted reference to [ADDRCONF] (what part of [ADDRCONF] was referenced
>    here?)
> Added reference to interface on which RA was received for clarity

>    since the DHC server will return "other"

> S/DHC/DHCPv6/
> s/"other"/all available configuration information/

>    [DHCPv6lite] is available for autoconfiguration of other

> s/autoconfiguration/delivery/ because the configuration involves a server
>   and is not "autoconfiguration"

>    - If the M bit is also set, clients SHOULD use DHC to obtain
>      addresses (and associated configuration information) as
>      described above.

> Reworded for clarity
> - Ralph 

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Apr 2006 15:48:49 -0400

Thomas - thanks for the review of the proposed text.  Good catch on the "NOT
not" problem.

I used [DHCPv6lite] as a citation for compatibility with the previous revs
of the text, and the text RFC 3736 explicitly where I wanted to emphasize
that there is a specific way to use DHCP described in that RFC.

- Ralph

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Apr 2006 13:08:48 -0700

Thomas,

> below.)  Also, one nit (from my original text!)

With these clarifications, I think this text is fine.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Apr 2006 19:01:26 -0400

Thomas - [DHCPv6lite] has square brackets and is a citation.  RFC 3736
doesn't have square brackets, is the name of the document (not a citation)
and doesn't require an entry in the references.

I used RFC 3736 without brackets because I don't like the construct
"described in [DHCPv6lite]".

Doesn't much matter, really.  OK with me to replace "RFC 3736" with
"[DHCPv6lite]".

- Ralph

On 4/12/06 3:51 PM, "Thomas Narten" <[email-masked]> wrote:

>> I used [DHCPv6lite] as a citation for compatibility with the
>> previous revs of the text, and the text RFC 3736 explicitly where I
>> wanted to emphasize that there is a specific way to use DHCP
>> described in that RFC.
> 
> Not sure I follow this. Does that mean that in the references section
> you expect RFC 3736 appear twice? I'm sure the RFC editor will ask
> the same question....
> 
> I.e., what do you want to see in the final RFC? (Assuming we actually
> ever agree and ship the darn thing!!! :-)
> 
> Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Apr 2006 15:51:55 -0400

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 13 Apr 2006 17:37:45 +0900

>>>>> On Fri, 24 Mar 2006 10:18:32 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> Second try, this time with new text on top and explanation below.

I have several concerns about the proposed text (sorry for joining the
discussion at this late stage).

First, since rfc2462bis has removed the M/O related discussion as you
noted, we'll miss some of the details about how to use DHCPv6 in
conjunction with the M/O flags that RFC2462 originally described.  For
example, the old RFC states:

   [...] 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.

In the new set of 2461bis and 2462bis with the current proposal, it
will be unclear what the host should do in this case, and, in that
sense, simply saying 'SHOULD use DHCPv6' with removing the other
details seems a bit irresponsible for me.

Secondly, I'm not sure what a host that only implements DHCPv6lite
(and not the other part of RFC3315) should do when it receives an RA
with the both M and O flag being on.  Such a host may be just fine
with link-local addresses or with addresses configured in some other
way, and may simply want to get other configuration information by
DHCPv6lite.  I believe it's a valid scenario, but the current proposed
text is not clear on this to me.

In the almost-dead the M-O flag draft, I (we?) tried to solve these
issues, probably unsuccessfully.  If we prefer to leave these possible
issues open for 'simplicity' and let the users consider the solutions
(if necessary), I think I can live with that.  But I'd like to be sure
that the ignorance of the potential issues is our consensus.

Third, I tend to agree with Erik and Alain with the 'SHOULD'.  Also,
I'm concerned about the SHOULD in that it may sound it is at least
mandatory to "implement" the address configuration part of DHCPv6, and
the operators may set the M-flag to true without much considering the
case where there may be hosts that do not support address
configuration by DHCPv6.  It was actually our main concern in the
discussion for the 'IPv6 Node Requirements' document, and that's why
RFC4294 states as follows:

   Stateful Address Autoconfiguration MAY be supported.  DHCPv6
   [RFC-3315] is the standard stateful address configuration protocol;
   see Section 5.3 for DHCPv6 support.

   Nodes which do not support Stateful Address Autoconfiguration may be
   unable to obtain any IPv6 addresses, aside from link-local addresses,
   when it receives a router advertisement with the 'M' flag (Managed
   address configuration) set and that contains no prefixes advertised
   for Stateless Address Autoconfiguration (see Section 4.5.2).
   [...]

And finally, the following sentence sounds a bit strange to me:

>        Note that if neither M nor O are set, the node SHOULD NOT

since by saying 'Note that' it sounds like a consequence of the
behavior and requirement described so far, while this is actually an
independent requirement.  Also, I believe the 'are' in this sentence
should actually be 'is'.  It seems the 'are' is a leftover when it was
used in the context of 'both M and O' in an earlier version of the
proposal.

Now, assuming we have the consensus for the first and second concerns
of mine, I'd propose the following text:

========================= from here =========================
    M :
     
         1-bit "Managed address configuration" flag.  When set, it
         indicates that addresses are available via Dynamic Host
         Configuration Protocol [DHCPv6].  When the M flag is set,
         nodes that implement DHCPv6 SHOULD use it to obtain addresses
         (and associated configuration information) to be assigned to
         the interface on which the RA was received.  Note that when
         the M flag is set, the setting of the O flag is irrelevant,
         since the DHCPv6 server will return all available
         configuration information together with any addresses.

     O :

          - If the M flag is also set, the O flag is irrelevant (as
            described above) and nodes that implement the full set
            of the DHCPv6 protocol [DHCPv6] SHOULD use it to obtain
            addresses and associated configuration information.
        
          - If the M flag is not set, nodes that implement
            [DHCPv6lite] SHOULD use it as described in RFC3736.

        If neither M nor O is set, the node SHOULD NOT request any
        information with DHCPv6.

     This document does not specify further details about the usage of
     these flags, including the node's behavior on a value change of
     these flags.  If necessary, future versions of this document or a
     separate specification may clarify the details once operational
     experiences are sufficiently gained.
========================= to here =========================

The points are:

- clarify that the "SHOULD"s apply to the node 'that implement the
  corresponding DHCPv6 protocol', mainly to address my third concern
- wording change for the case of M=off and O=off to address my last
  concern
- add a new paragraph explaining some details are intentionally open
  in this specification, mainly to address my first and second
  concerns

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 13 Apr 2006 09:09:15 -0400

Jinmei:

This new text doesn't work for the "O" flag. It implies that only
dhcplite clients care about the O - this is not correct. *ALL* DHCPv6
capable clients need to honor the "O" flag - it just means that they
only do Information-Request (not Solicits).

>             [DHCPv6lite] SHOULD use it as described in RFC3736.

This should be (as Thomas/Ralph had):
          - If the M flag is not set, the node SHOULD use DHCPv6 as
            described in RFC3736.

Frankly, I thought the text that Ralph and Thomas worked out was
sufficient. I don't mind if the "Note that" is changed as you suggest.

However, in a re-read of that text (and your text), I think you're all
missing that with the M flag set, DHCPlite only clients should *ALSO* do
DHCPv6 (though they'll only get "other configuration information"). The
existing text implies to use DHCPv6 for addresses; not that all clients
that are capable of DHCPv6 (either 3315 or 3736) run DHCPv6.

Personally I've come to hate DHCPlite (3736) because it unnecessarily
complicates matters. To me, M-bit set means:
  - send SOLICIT if client's DHCPv6 implementation supports it (ie, RFC
3315), or
  - send INFORMATION-REQUEST if not (ie, RFC 3315 or 3736), or
  - do nothing if no DHCPv6 support.
If O-bit is set (and M-bit wasn't), send INFORMATION-REQUEST only or do
nothing if no DHCPv6 support.

And SHOULD is the correct terminology. If you or anyone else has good
reason not do so, then you're free to do so. SHOULD is *NOT* MUST. It
specifies the *DEFAULT* behavior which is what we're trying to do here.

It is amazing how difficult it has been to document two bits!

- Bernie

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, April 13, 2006 4:38 AM
> To: Ralph Droms (rdroms)
> Cc: Thomas Narten; Bob Hinden; IPv6 Mailing List
> Subject: Re: Proposed M&O bits text for RFC2461bis 
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 14 Apr 2006 20:26:28 +0900

>>>>> On Thu, 13 Apr 2006 09:09:15 -0400, 
>>>>> "Bernie Volz (volz)" <[email-masked]> said:

>           - If the M flag is not set, the node SHOULD use DHCPv6 as

I actually didn't intend to limit the applicability to
"DHCPv6lite-only" clients.  In fact, since [DHCPv6lite] is a subset of
[DHCPv6], nodes that implement [DHCPv6] should be included in "nodes
that implement [DHCPv6lite]".  But if my proposed text sounded so, I
don't mind using the original text here, or, more clearly:

  - If the M flag is not set, nodes that implement DHCPv6 (including
   ones only implement [DHCPv6lite]) SHOULD use it as described in
   RFC3736.

Actually, my main point was to clarify that this one:

applies to nodes "that implement full RFC3315".

> that are capable of DHCPv6 (either 3315 or 3736) run DHCPv6.

Sorry, I'm not really sure exactly which part of the original (and my)
text you are referring to...could you be more specific?

> nothing if no DHCPv6 support.

I have a sympathy for you here, in that I also thought things are
unnecessarily complicated due to the combination of M/O and
DHCPv6/DHCPv6lite and implication of the combination.  In my
understanding of the past discussion, however, others were not
convinced about the complexity and wanted to leave the "unseeable"
complexity open by preferring "simplicity", and they won the
discussion.  So, I don't think we can reach a different consensus even
if we restart the old discussion...

> specifies the *DEFAULT* behavior which is what we're trying to do here.

Well, while I said I agreed with some others about the SHOULD, I did
not actually oppose to the use of SHOULD; in fact, my proposed text
basically did not change the use of RFC2119 keywords.  I just
"clarified" (IMO) that some of the requirements only apply to those
nodes that implement specific protocols.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 Apr 2006 09:14:58 -0400

I think that trying to codify in the specification differences in behavior
based on which part of a specification a host implements is
counterproductive because it adds unnecessary complexity and over-specifies
the desired behavior.  We should describe the behavior assuming an
implementation of RFC 3315 without qualification.  It is up to the
implementor to decide how to behave if only part of the specification is
implemented.

RFC 2461/2 does not make any accommodation for a host that does not
implement stateless address autoconfiguration as specified in RFC 2462.
There may, indeed, be such hosts whose intended networking scenario will
never include stateless address autoconfiguration.  Similarly, we don't need
to add text to the description of the M/O flags to accommodate hosts that
don't implement parts of RFC 3315.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 19 Apr 2006 01:32:44 +0900

>>>>> On Fri, 14 Apr 2006 09:14:58 -0400, 

> don't implement parts of RFC 3315.

Now that this discussion seems to vary so much (again), I'm not sure
if it's reasonable to make a response now, especially about specific
wording, but anyway:

In general, I tend to agree that a protocol specification don't have to
(or should not?) care about which part of which protocol is
implemented.  In this case, however, we know a subset (RFC3736) of the
full DHCPv6 protocol (RFC3315) has been standardized and (at least to
me) there are pitfalls in the original RFC2461 specification for
nodes that only implement the subset, I think it is worthwhile to be
very specific even if it may sound noisy.

I know not all people are convinced about my concerns, but I think
many people at least see this one confusing:

>>>>> On Thu, 13 Apr 2006 17:37:45 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> text is not clear on this to me.

It's not clear to me, and I believe it's also unclear to other future
developers.  Moreover, it's not only unclear but also may cause
interoperability problems in that DHCPv6lite-only nodes may not be
able to perform the operation in this case, depending on the details
of the semantics.

Qualifications like "that implement DHCPv6 [RFC3315]" may sound
awkward and/or redundant for some people, but I believe at least they
don't harm.  And the qualifications will surely clarify things for
some other people (it works for me at the very least).  So, I still
prefer my proposal than the original one (if we need to choose either
of these two).

					JINMEI, Tatuya