Sorry for being too late response.
> 1) This document doesn't seem to take a stance what happens
> when/if the host
> has multiple routers (whether on the same or different
> interfaces), and some
> of them have O/M bits set and some others not. Would that lead to a
> set-unset-set-unset loop, with triggering? If heard on another interface,
> should that affect how DHCPv6 is run?
Suggestion:
It seems a rather general issue on the inconsistent RA parameters
from multiple routers, thus I wrote simple text as Appendix section.
Appendix A: Handling of M/O flags from multiple routers
This document does not take a hard stance what happens when a host
has multiple routers, and inconsistent information (different M/O
flags configuration) is learned from different routers. Originally,
the basic documents [RFC2461]/[RFC2462] already described
"Configuration Consistency" described in Section 5.6 of [RFC2462] and
a host will simply handle the inconsistent M/O flags of RA in the
same manner. if the inconsistent M/O flags of RA is reached to a
host frequently (e.g., mobile environment for supporting fast
movement detection when attaching a new network) it can occurs
complex consideration as an erroneous case, however this case is not
closely related to this document (rather general issue on the
inconsistent RA parameters from multiple routers) since other
configuration parameters such as MTU size and hope lime is also
possible to be learned from this inconsistency, and besides, it is
administrator's responsibility to ensure the consistency among RA
parameters from multiple routers in the same single link as described
in Section 5.6 of [RFC2462]. So authors remain "Handling of M/O
flags from multiple routers" as out of scope of this document.
Hopefully, it will be more clarified in the basic documents (or seperate
one) as well than now.
> 2) The treatment of M/O flag "transitions" and the initial state after a
> reboot is not 100% unambiguous.
>
> In section 6.0 you said:
>
> The host should reset these flags depending
> on the information received in RAs when the host is rebooting.
>
> ...
>
> Policy 2: The host SHOULD invoke Stateful DHCPv6 for address
> autoconfiguration (along with other configuration information)
> if and only if it sees an RA changing the M bit from unset to set.
>
> ==> but in previous sections, you used the wording "from unset to set";
> this requires that there is, in fact a transition -- that these are always
> initialized to zero.
Suggestion:
The host SHOULD *update* these flags depending on the information
received in RAs when the host is rebooting.
IMO, it does not mean *initialized status is always zero*.
> The latter wording ("RA changing the M bit") is also confusing because
> "M bit" has typically been considered as a property of the routing
> advertisement, not a global variable of the node.
Suggestion:
Policy 2: The host SHOULD invoke Stateful DHCPv6 for address
autoconfiguration (along with other configuration information) if and only
if it receives an RA containing the M bit ON.
Let me know your view on this.
Thanks
- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
