Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 14 May 2005 17:35:37 +0900

>>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

>>>> I can think of several possible resolutions:
>>>> 
>>>> 1. just say that it's host/network administrator's responsibility to
>>>> provide consistent parameters/configurations.  In this sense, the
>>>> combination of a) and b) above is just a configuration error.
>>>> This would be the most lightweight resolution for the authors:-),
>>>> but I personally think it's irresponsible.
>>> 
>>> I agree as well.  This is not good enough.
>> 
>> I think it's perfectly reasonable to assume that a configuration
>> mismatch is admin error and leave it at that - in this case, the RAs are
>> configured incorrectly, promising that a non-existent address assignment
>> service is available.

> That would be consistent if the presence of M-flag would only trigger 
> DHCPv6 for address assignment, but DHCPv6 would not be used to 
> configure anything else at all unless O-flag was also appropriately 
> set.

> Then the DHCPv6 and DHCPv6-lite would function in a similar fashion 
> from the network administrator's perspective.

> So, IMHO, either we must require O flag always for Information 
> Configuration (whether DHCPv6 full or lite) or support the 
> administrators who can't make out the subtle difference about the 
> appropriate configuration of the flags.  For that, guidance for full 
> DHCPv6 implementers to also try emulating DHCPv6 lite would probably 
> be sufficient.

I've been thinking about this issue for a while, and I now feel it may
require a more profound discussion than I originally thought...

Here are some background points:

- In original RFC2462, if ManagedFlag (host's variable corresponding
  to the M flag of RA) is TRUE, it implicitly means OtherConfigFlag is
  also TRUE (Section 5.2).  It would mean if we receive an RA with
  M=on (whether O=on or off), the receiving host would start the
  "stateful" protocol (which we now know is DHCPv6) for address
  configuration *and* the "stateful" protocol for configuration
  information excluding addresses (Section 5.5.3).

- In the past discussion about the M/O flag document, we clarified
  that the notion of "M" and "O" is quite independent.  That is, "M"
  means the "Host Configuration Behavior", which, more specifically,
  means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O"
  means the "Information Configuration Behavior", which means DHCPv6
  an Information-request/Reply exchange.  Unlike RFC2462, there is no
  implicit dependency between "O-Flag" (renamed from OtherConfigFlag
  to avoid confusion) and the M flag in this document.  So, for
  example, the host does not invoke the "Information Configuration
  Behavior" just because the M flag in an RA is ON.

I guess the slightly different sense led us to the current confusion
(or problem).

If we respect both the original sense of RFC2462 and our consensus
about the semantics separation of the M/O flags, I believe the right
solution is the following:

  - allow (or even require) running the Host Configuration Behavior
    and the Information Configuration Behavior concurrently. (note:
    this is a significant change from the current M/O document)
  - note that the same type of configuration information (e.g.,
    recursive DNS server addresses) can be obtained with those two
    behaviors, and that how to deal with possible inconsistency is
    beyond the scope of the M/O document.
  - also note that the network administrator should by default provide
    the Information Configuration Behavior when they provide the Host
    Configuration Behavior, in which case both the M and O flags
    should be set to ON in router advertisements.

With the last notice, I'm fine with the position of saying "it's
administrator's responsibility to ensure service consistency".

					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: Thomas Narten <[email-masked]>
Date: Tue, 24 May 2005 10:46:06 -0400

> solution is the following:

I think we should be careful NOT to get hung up on what the original
intent of the M/O bits were, but focus on what the right behavior
should be, given what we know now/today, and given the DHC protocols
we actually have.

The M/O bits were defined before we had DHCPv6 specified. I'd argue
that the M/O bits are a classic example of defining protocol/bits
before we really had a clear understanding of how they would be used,
what the semantics should be or what the actual protocols would be
that get invoked as a result of those bits.

Surprise, surprise, when one invents protocols/mechanisms in such
cases, we often get the details wrong.

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 25 May 2005 10:47:03 +0900

>>>>> On Tue, 24 May 2005 10:46:06 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> should be, given what we know now/today, and given the DHC protocols

In general, I agree (if I sound self-conflicting, note the "If" in the
cited part above).  In practice, however, it should also be noted that
one major push back argument in the similar discussion for rfc2462bis
a year ago was that we should not introduce incompatible changes to
existing implementations that assume the "original intent".

It seems to me that this is a typical case of tradeoff between "it's
never too late to do the right thing" vs "don't break compatibility".
In the previous discussion, the latter was preferred, and so we are
here.  If we can now prefer the former argument, I'm personally
willing to take it.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 May 2005 22:39:41 -0400

Regarding breaking backward compatibility - this compatibility affects
only clients, right?  Can we answer the question: exactly how would
existing clients (and I'll bet we can enumerate all the available
clients) be affected by a change in definition?  How would the observed
behavior of the clients be out-of-spec relative to the new definition?

I ask because I'd be willing to bet the observed behavior of existing
clients will still be in compliance with the new definition: when the M
bit is set, the client will attempt HCB and when the O bit is set the
client will attempt ICB.  When both are set, I'll bet the client tries
HCB, which is still compliant with a new definition of M bit as a hint.

- Ralph

On Wed, 2005-05-25 at 10:47 +0900, JINMEI Tatuya / 神明達哉 wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 25 May 2005 14:51:09 +0900

>>>>> On Tue, 24 May 2005 22:39:41 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> behavior of the clients be out-of-spec relative to the new definition?

It depends on the details of the "new definition".  For example, a
"radical" change like removing the flags altogether would break the
compatibility.  I cannot be more specific at the moment, since the
original message from Thomas did not show specific ideas...

					JINMEI, Tatuya