> - 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. This might be tricky to implement. A potential problem would be how to get the M information that arrives in the kernel space to a program like DHCPv6 that runs in the user space (on many operating systems).
It would be easy to integrate this behaviour in a DHCPv6 client if that client would listen to RAs and read M/O bits itself. You could then store the policy information 1-2 in the DHCPv6 client's configuration while policy 3 would be covered by not starting the DHCPv6 client at all. Same goes for RFC3736-like behaviour. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
