Hi
> If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour
> for address and other configuration information, regardless of the
> change of the state variables. The host SHOULD NOT invoke
> Information Configuration Behaviour regardless of O-Policy. Note,
> however, that if the available DHCPv6 servers only provide the
> service for the Information Configuration Behaviour, the host will
> even not be able to configure other configuration parameters than
> addresses. Thus, it is generally inadvisable to set M-Policy to 1,
> unless there is a particular reason to do so.
>
> ==> is it really true that if a full DHCPv6 client is initiated, and
> the server is 'stateless', the DHCPv6 client doesn't get back the
> stateless information?
>
> That would seem to be a big problem for DHCPv6 deployment if servers
> are stateless, and I think someone has claimed that this shouldn't be
> a problem.
>
> If the text you wrote is correct, that would mean that to get robust
> behaviour, the host would have to either rely that the capabilities of
> the DHCPv6 servers match those that are advertised in the route
> advertisements, or to always just "prepare for the worst" by firing
> off a parallel information-request as well.
>
> And then it would seem to make sense for prudent DHCPv6 implementers
> to do everything they can to ensure they'll receive information-reply
> from stateful servers as well.. because that's better than nothing,
> and better than relying on how the bits in RAs have been configured!
A node that performs Information Configuration Behaviour (is newly defined
in this document instead of stateless DHCPv6) MUST have obtained
its IPv6 addresses through some other mechanism. So if the node
is supposed to perform Information Configuration Behaviour without
IPv6 addresses, it is a problematic situation (further, IMO, it is a rare
environment). That is why we said *inadvisable* in this document.
IMO, it does not occur severe problems since RFC3736 is just a subset
of the full DHCPv6 service, thus a full DHCPv6 client (as you said) can do
both or either Host Configuration Behaviour for configuring the IPv6 address
and Information Configuration Behaviour for the other information.
> - minor issue wrt inconsistent M/O information:
>
> If the host frequently receives inconsistent M and O flags of Router
> Advertisement (e.g., in a mobile environment for supporting fast
> movement detection), it may need complex consideration on an
> erroneous case. However, this case is not closely related to this
> document; rather, it is a general issue on the inconsistent Router
> Advertisement parameters from multiple routers. In fact, other
> configuration parameters such as the MTU size and the hop limit are
> also possible to be inconsistent in different Router Advertisements.
>
> ==> actually M/O is IMHO a bit worse than these two, because these are
> just internal variables, typically implemented in the kernel, and
> toggling back and forth between them is not a problem.
>
> Presumably, initiating DHCPv6 requires running a non-trivial user-land
> process. Hence, I'd dare to say that the transitions are a bigger
> problem with M/O flags, as has already been discussed a bit in
> security considerations.
>
> Thus I'd like to see some further text, e.g. 1-2 sentences, describing
> why M/O transitions are a bigger problem than other inconsistent
> information.
If required, your concern will appear in the revision.
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
--------------------------------------------------------------------
