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

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 05 Nov 2004 12:50:15 +0900

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

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

I'm glad to hear your support.  I'd also appreciate comments from
others, either positive or negative, since the adoption or
non-adoption will also affect the next step of rfc2462bis regarding AD
comments.

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

Good points.  In fact, I thought this was highly controversial and
wanted to ask opinions from others.

But, I'd first like to clarify some things.  We intentionally avoided
using the term "stateful DHCPv6" and "stateless DHCPv6" because these
terms are very confusing as we discussed in this list before.  I'm
going to use the following new terms defined in Section 3 of the draft:

  Host Configuration Behaviour:
     configuring address and other config information through
     Solicit/Advertise/Request/Reply or Solicit/Reply (if rapid commit
     is enabled) exchanges. [Note: in this message, I'll forget the
     short-cut exchange with rapid commit for simplicity.]

  Information Configuration Behaviour:
     configuring other information excluding addresses through
     Information-request and Reply exchanges

Secondly, the part you cited is not related to the M/O flags.  Policy
1 means the host SHOULD perform the Host/Information Configuration
Behaviour *regardless of* the M/O flags.

But your main point still stands, and I agree this is a problematic
case.  I'd first note I don't think it's a true-or-false thing; we're
just going to define the most reasonable behavior, and this is its
first step.  The background of this statement is the dependency
described in Section 6, which was originally stated in RFC2462, that
if we invoke Host Configuration Behaviour we basically should not
invoke Information Configuration Behaviour.

As you pointed out, I don't think this restriction is always
reasonable.  But when we wrote revision 01, we basically tried to
follow the original sense of RFC2462, and we could not find a better
behavior.  Hence the current statement.

But if we (the wg) can agree on being more flexible, I can think of a
better approach.  For example, if a host which sets M-Policy to 1
cannot get any Advertisement to Solicit messages for some period, it
may make sense to fall back to Information Configuration Behaviour as
you indicated.

One possible problem of this approach is that RFC3315 requires the
client to send Solicit forever, until it gets an Advertise or Reply,
by specifying MRC and MRD being 0 (Section 17.1.2 of RFC3315).  So, at
least protocol-wise, the fall-back behavior does not (or may not)
conform to the RFC.

But, if we can also agree on modifying RFC3315 and RFC3736 a bit, I
can even think of a bit smarter approach:

  - DHCPv6 servers that only support Information Configuration
    Behaviour should also support the Advertise message and the IA_xxx
    options, but it always return an empty Advertise message to
    Solicit with a status code being NoAddrsAvail.  (This is a
    modification to RFC3736)
  - If a DHCPv6 client that supports both Host/Information
    Configuration Behaviours only receives such an Advertise message,
    it MAY fall-back to Information Configuration Behaviour.  (This is
    a modification to Section 17.2.1 of RFC3315, which requires the
    client ignore such Advertise).

Although the first modification requires additional implementation
complexity to DHCPv6 servers that only conform to RFC3736, the
resulting behavior is still "stateless", and in that sense, should be
lightweight.  So I think it's acceptable.

Anyway, there is no doubt that we need further discussions on this
point.  I'm open to other ideas.

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

I think I said this before, but anyway, personally I'm not really sure
if it's a good idea to mention such an implementation-specific thing
in a document describing protocol behaviors.  However, I don't oppose
to that idea now that this is in an Appendix.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 5 Nov 2004 13:19:15 -0500

All,
      The feedback received (both on the list and off) indicates
a consensus to adopt this work by the WG.  The next version
should be published as an IPv6 WG document.

      The working group now needs to ensure this document
documents sufficiently the use of the M&O bits.

Regards,
Bob & Brian
IPv6 WG co-chairs

On Oct 26, 2004, at 10:15, Brian Haberman wrote:

> All,
>      This is a consensus call on whether the IPv6 WG should adopt:
>
> 	Title		: Consideration M and O Flags of IPv6 Router Advertisement
> Regards,
> Bob & Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 23:19:46 +0200 (EET)

Ralph, there's something that probably bears discussion in dhcwg 
here..

>     Information-request and Reply exchanges

For full clarity, I'd suggest s/Reply/Information-reply/ above, as I 
think it was what you meant.

> invoke Information Configuration Behaviour.

I'm not sure if I followed this background statement.  My assumption 
has always been that 'host configuration behaviour' would always also 
include information config as well; a "less specific prefix" in a way 
:).  But I may have missed some earlier consensus or did not read too 
carefully.  (There would certainly be no way to stop Full DHCPv6 
client from getting back all the ancillary information in addition to 
the addresses, right?)

> behavior.  Hence the current statement.

OK..

> may make sense to fall back to Information Configuration Behaviour as

Hmm, not maybe as good as I'd hope, but that's a start..

> least protocol-wise, the fall-back behavior does not (or may not)

Not necessarily: there is nothing in the spec which would prevent 
sending *additional* messages, e.g., an information-request, and in 
parallel, also continue sending Solicits forever, right? :-)

I'd guess that would be the 'easiest' solution to this particular 
problem.  Would the client get any feedback from the server if the 
server did not support solicit, which could be used to trigger sending 
a parallel information-request, or is the timeout the only option?

> lightweight.  So I think it's acceptable.

These might be acceptable as well, but then there could still be 
implementations which do not deal with this, and you'd have to depend 
on both ends getting it correct; it would be best if just one end 
would be enough, like above.

> point.  I'm open to other ideas.

Certainly.  Perhaps this could be brought up in DHC wg as well?  It 
seems that the most important discussion in this WG is what we 
consider the RFC2462 interpretation of M/O behaviour to be, and if 
it's inappropriate, whether we'd like to modify it.

> to that idea now that this is in an Appendix.

I share the concerns, but being in the appendix, and already comparing 
the situation to something else (which may not be comparable in many 
situations), the text seems called for..

-- 
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 06 Nov 2004 07:50:35 +0900

Just to clarify some things quickly:

>>>>> On Fri, 5 Nov 2004 23:19:46 +0200 (EET), 

> think it was what you meant.

No, it's surely "Reply".  According to RFC3315, the response to
Information-request is also a Reply message, and there is no
Information-reply defined.

> client from getting back all the ancillary information in addition to 

Your assumption is correct.  More clearly, when we exchange
Solicit/Advertise/Request/Reply messages, we usually get some IPv6
addresses allocated as well as other configuration information such as
recursive DNS server addresses.  In our draft we call it "Host
Configuration Behaviour".

On the other hand, when we exchange Information-request/Reply
messages, we only get "other" configuration information.  We call it
"Information Configuration Behaviour".

Are we synchronized so far?  If so, which part of the background
didn't you follow?

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Sat, 6 Nov 2004 08:39:47 +0200 (EET)

> Information-reply defined.

Sorry for misremembering (and not checking).

> Are we synchronized so far?  If so, which part of the background

When I read the draft, it struck that it tried to specify Host 
Configuration Behaviour as excluding Information Configuration 
Behaviour.  That is, when both O and M flags would be set, and the 
policy would be appropriate, the host would try to run *both* Host and 
Information config behaviour, even if information config behaviour is 
already (implicitly) included in host config.

There is of course one corner case here: if a node running host 
configuration behaviour would omit separate information configuration 
behavior, in case there was no "full DHCPv6" server in the network, 
the host would not get even the Information Configuration unless 
DHCPv6 falled back to sending an information-request in some manner 
(such as we discussed).

Thus it seemed that in the current draft's specification, there were 
some (typically unnecessary) steps when both M and O flags are set and 
the policies set in a certain way, depending on how the DHCP specs are 
to be implemented to fall back when the server would only support 
information configuration.

Does that clarify?