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