> 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.
I think the intent is not to prescribe "begin using" but merely to make it clear that the transition means that DHCPv6 is now available whereas before the transition it was not available.
I agree; the flag indicates DHCPv6 is available and the spec will not prescribe host behavior based on the availability of 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?
And the higher-level question is whether it is important to recommend a particular host behavior in those cases.
Yes.
I think one can make the case that life is easier for the network administrator if all implementations behave the same during these transitions, but given that we don't seem to want to prescribe that DHCPv6 is trigger by the "on" transitions, perhaps it doesn't make sense to try to prescribe behavior for the "off" transitions?
No, it doesn't make sense to prescribe the behavior in RFC 2462bis. Would it be useful to discuss alternatives and capture that discussion in a BCP?
I think what is apparent is that after an "off" transition it isn't useful for a host to try to renew information (addresses or others) that it has received from DHCPv6, since the flags being "off" means that the DHCPv6 service (the full or the stateless, respectively) isn't available.
Yes ... sending more DHCPv6 message when the flag is off probably doesn't make sense. There might be some question about what the host does with the information previously obtained through DHCPv6.
Perhaps we should make this statement in the document.
It might even be something explicitly non-prescriptive like "This document does not prescribe how a host behaves in response to the M/O flags."
Erik
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
