[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 Tue, 26 Oct 2004, Brian Haberman wrote:
    This is a consensus call on whether the IPv6 WG should adopt:

Title : Consideration M and O Flags of IPv6 Router Advertisement
Author(s) : S. Park, et al.
Filename : draft-daniel-ipv6-ra-mo-flags-01.txt
Pages : 12
Date : 2004-10-25

as a WG document.  Comments and opinions can be sent to the
mailing list and/or the chairs.  We will accept comments on this
call until 11/05/2004.

I think this is valuable clarifying work, and a good starting point for the work. I think it's worth adopting.

A couple of comments on the draft for improvement:

- just a question on how full DHCPv6 client works with stateless DHCPv6 server:

  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!

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

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