>>>>> On Mon, 17 May 2004 15:04:17 -0400,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
>> > 3. (optionally) make a separate document (standard or BCP) on how to
>> > interact the protocols with these flags
> Can you give some examples of what conditions or interactions might be
> included in such a document?
It's just a rough sketch, but I'm currently thinking about a document
that describes
- how a host that implements DHCPv6 should behave. The host would
have an internal (conceptual) variable, controlling the policy about
autoconfiguration, which should have at least three values:
1: it should invoke DHCPv6 for address autoconfiguration regardless
of the content of receiving RAs or the existence of RAs
2: it should invoke DHCPv6 for address autoconfiguration if and only
if it sees an RA changing the M bit from unset to set
3: it should not invoke DHCPv6 for address autoconfiguration
regardless of the content of receiving RAs or the existence of
RAs
- same thing for a host that implements the "stateless" subset of
DHCPv6 (RFC3736) for other configuration information.
The details can change based on further discussion, of course. But at
the moment, I'd like to know if we can start editing rfc2462bis with
an expectation that we'll have some separate document like above.
And,
> What about the situation if the 'M' flag transitions from set to not set? I
> don't have a good answer off the top of my hear...perhaps this situation is
> an example of what should go into the BCP document you suggest?
Yes, probably.
BTW: RFC2462 currently says the transition from set to unset means
"nothing":
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.
(Section 5.5.3)
Personally, I don't think this behavior makes much sense, but of
course we'll need to be careful if we try to change this (in the "BCP"
document, or wherever) since it may have an effect on existing
implementations.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
