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).
> - If the M flag is not set, nodes that implement
> [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 PROTECTED]
> [mailto:[EMAIL PROTECTED]
> 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
>
> >>>>> On Fri, 24 Mar 2006 10:18:32 -0500,
> >>>>> Ralph Droms <[EMAIL PROTECTED]> 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
> > request any information with DHCPv6.
>
> 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 :
>
> 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 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 PROTECTED]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
