I think Jinmei-san suggested deleting the whole notion of an internal-to-the-implementation ManagedFlag and OtherConfigFlag. I extrapolated from that suggestion that the host would (in a stateless way) base its behavior on the most recently received values for M/O (which, I guess, means the implementation really does need ManagedFlag and OtherConfigFlag). So, as soon as the M/O bits transition to set, the host would begin using DHCPv6.
The host behavior when the M/O flags transition from set to unset is a little less clear. In the case of the O flag, the host will stop using DHCPv6 for other configuration information. Should it also stop using the configuration information it received through DHCPv6?
Similarly, when the M flag transitions from set to unset, should the host stop using any addresses obtained through DHCPv6? Or should the host simply not try to extend the lifetimes of any assigned addresses?
- Ralph
At 09:18 AM 5/17/2004 -0700, Erik Nordmark wrote:
Overall your proposal is good.
> - 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 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.
> > - remove Section 5.5.2 of RFC2462 (that mandates performing the > > "stateful" protocol when no RAs)
Restating that to not be a requirement also makes sense. I think the section should become more of a note which points out that in the absense of any routers hence router advertisements, stateless address autoconfiguration isn't available and that a host MAY wish to use DHCPv6 in this case.
It would presumably make sense to clarify in that section that even if this is done the host continues to operate the stateless protocol i.e. the reception of a router advertisement (with A-flag in one or more prefix option) in the future will trigger stateless. This is to make it more clear that the absense of a router while booting must not automatically "turn off" the stateless protocol.
Erik
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
