[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.txt

On Fri, 29 Oct 2004, Soohong Daniel Park wrote:
   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.

I think this missed the point; maybe I didn't articulate it well enough.

I'm not concerned about how nodes configure addresses, but rather how nodes get the other information.

The text above could be read so that a full DHCPv6 client would not get addresses (obviously!) and neither other information (that would be surprising, but I could imagine why this could happen) from a stateless DHCPV6 server. The question is, does it really not get 'other information', and if so, this calls for several other actions. If not, the draft needs to be revised for clarity.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6