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

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

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.
Perhaps we should make this statement in the document.

  Erik


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to