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

From: Brian Haberman <[email-masked]>
Date: Tue, 26 Oct 2004 10:15:18 -0400

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

Regards,
Bob & Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2004 20:23:52 +0300 (EEST)

Hi,

> mailing list and/or the chairs.  We will accept comments on this

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 29 Oct 2004 17:02:14 +0900

Hi

> 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.
 
> why M/O transitions are a bigger problem than other inconsistent 

If required, your concern will appear in the revision.

Thanks. 

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Oct 2004 11:58:29 +0300 (EEST)

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