>>>>> On Mon, 17 May 2004 09:18:23 -0700 (PDT),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> - remove "requirement" sentences like the following one
>> 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.
>> (Section 5.5.3 of RFC2462)
> I think I'm suggesting the same thing as Tim.
> Loosing the above setence means that implementations might not
^^^^^^^ you meant "Losing" here, didn't you?
> look for changes in the flag value (but perhaps instead only look
> at the flag in the first RA).
> So saying something like
> Hosts which invoke DHCPv6 based on the ManagedFlag need to
> not only look for this flag when booting, but also observe whether
> the ManagedFlag changes from FALSE to TRUE in a subsequent Router
> Advertisement.
Good point. Then how about the following approach?
- change the definition of ManagedFlag
From:
ManagedFlag Copied from the M flag field (i.e., the
"managed address configuration" flag) of the most
recently received Router Advertisement message.
The flag indicates whether or not addresses are
to be configured using the stateful
autoconfiguration mechanism. It starts out in a
FALSE state.
To:
ManagedFlag Copied from the M flag field (i.e., the
"managed address configuration" flag) of the most
recently received Router Advertisement message.
The flag indicates whether or not DHCPv6 is
available to obtain addresses. It starts out
in a FALSE state.
- and revise Section 5.5.3 as follows:
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, it indicates DHCPv6 becomes available for address
autoconfiguration. The details of how the host should react to
this change will be described in a separate.
(I'm assuming we'll have a separate document to describe the details.
But if we cannot agree on this path, we'll need to revise the proposed
text above accordingly.)
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
--------------------------------------------------------------------
