Subject: Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 08 May 2004 23:39:20 +0900

>>>>> On Wed, 28 Apr 2004 12:16:15 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> I think the O flag (if we keep it!) should simply specify DHCPv6, with no
> implication about the way in which DHCPv6 is used.

> "Stateless DHCPv6" is simply a way to use some of the messages from the full
> specification in RFC 3315.  RFC 3376 is a guideline to the implementation of
> DHCPv6 that uses just Information-request/Reply messages.  A client can
> choose to use the Request/Reply or the Information-request/Reply message
> exchange to obtain other configuration information without address assignment.

Before going to further details, please let me clarify one thing about
RFC3736 (you should have meant RFC3736 by "RFC 3376" BTW).

In my understanding, RFC3736 defines a certain class of implementation
that is a subset of RFC3315, even though RFC3736 is basically a
"guideline".  Specifically, RFC3736 defines the implementation class
in its Section 5.

So, there can be four types of servers and clients:

A. servers that conform to RFC3315.  (These servers also conform to
   RFC3736)
B. clients that conform to RFC3315  (These servers also conform to
   RFC3736)
C. servers that only conform to RFC3736 (and do not implement the rest
   of RFC3315)
D. clients that only conform to RFC3736 (and do not implement the rest
   of RFC3315)

Is the above understanding correct?

					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: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 11 May 2004 00:42:20 +0900

(changing the subject)

>>>>> On Sat, 08 May 2004 23:39:20 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> B. clients that conform to RFC3315  (These servers also conform to
                                             ^^^^^^^should be "clients"

> Is the above understanding correct?

No responses...so, assuming the understanding is correct, I believe
the best protocol for the O flag is the subset of RFC3315 as defined in
RFC3736 (aka "stateless DHCPv6").  The rationale is as follows:

As long as we need to care about type D clients (which do not support
full RFC3315), servers must be configured to enable RFC3736, whether
they can also support full RFC3315 or not.

But then, I don't see the reason for leaving flexibility by specifying
a larger set (i.e., RFC3315) as the protocol for the O flag.

If we specify RFC3736 as the protocol,

- type A servers will be configured to act as RFC3736 servers (they
  may also act as full RFC3315 servers, but that doesn't matter here).
- type B clients will perform RFC3736 to get the "other" configuration
  information, as a subset of their full ability.
- type C servers will simply act as RFC3736 servers
- type D clients will simply act as RFC3736 clients

On the other hand, if we just specify RFC3315 as the protocol, we'll
be bothered about combination issues.  In the following discussion,
I'll call other configuration by request/reply exchanges "stateful
other configuration".

- type A servers will at least need to be configured to enable
  RFC3736, as explained above.  They may or may not enable the rest of
  RFC3315.
- type B clients may perform RFC3736 only, stateful other
  configuration only, or both.
  + if the client only tries RFC3736, it will be happy, since type A
    servers should act as RFC3736 servers (type C servers can of
    course serve for the client).
  + if the client only tries stateful other configuration, the
    configuration will fail when type A servers do not enable stateful
    other configuration or there are only type C servers.
  + if the client tries both RFC3736 and stateful other configuration,
    what happens depends on the ordering.  If it first tries RFC3736
    or performs both concurrently, it will be happy.  If it first
    tries stateful other configuration, the client can see a long
    delay before the configuration completes when type A servers do
    not enable stateful other configuration or there are only type C
    servers.
- type C servers will simply act as RFC3736 servers.  If there are
  type B clients that do not try RFC3736, the servers cannot serve for
  the clients.
- type D clients will simply act as RFC3736 clients.  The clients will
  be happy, since type A servers should act as RFC3736 servers (type C
  servers can of course serve for the client).

As shown above, a type B client can easily get stuck unless it is very
carefully configured; to be able to configure itself in all the
possible scenarios, the client will need to perform RFC3736 only,
tries RFC3736 first (which should succeed), or tries both RFC3736 and
stateful other configuration concurrently (at least the former should
succeed).  Then, why can't we simply specify RFC3736 as the protocol?

Meanwhile, leaving the flexibility may make sense if it has a clear
advantage comparing to specify RFC3736 clearly.  Regarding other
configuration information, however, I don't see such an advantage that
outweighs the complexity shown above.

Comments?

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 May 2004 12:39:53 -0400

Yes, your original analysis is correct...

Seems like the protocol associated with the 'O' bit should be RFC 3736;
there is no particular advantage to using the 4 message exchange of RFC 3315
for "other configuration information".  The only potential advantage would
be if there is ever a need for "other configuration information" that needs
atateful assignment; we've never found a need for such assignment in DHCPv4.

Although exactly where prefix delegation falls is a little unclear...

- Ralph

At 12:42 AM 5/11/2004 +0900, JINMEI Tatuya /

---

From: Stig Venaas <[email-masked]>
Date: Tue, 11 May 2004 09:40:45 +0200

> atateful assignment; we've never found a need for such assignment in DHCPv4.

I wouldn't rule this out completely. I think normally RFC 3736 will be
the reasonable thing to do. But if client for some reason wants some
stateful info it could still try to use RFC 3315 I think.

Just as examples, you could imagine client using RFC 3315 to get an IPv4
address or IPv6 multicast address. Or it could be none-address resources.

Note that I don't really want to discuss the need for IPv4 or multicast
address assignment here. But I'm not sure one should say that client always
must stick to the RFC 3736 subset.

Stig

---

From: Christian Strauf <[email-masked]>
Date: Tue, 11 May 2004 10:24:57 +0200

> stateful info it could still try to use RFC 3315 I think.
The problem is that if a clients tries stateful DHCPv6 by sending an IA 
option with the request while the server doesn't accept stateful DHCPv6 
(NoAddrsAvail), the exchange will fail and not even information options 
will be sent -- see parallel thread. In that case, the client MUST fall 
back to stateless exchanges if it wants to request information options.

Christian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 May 2004 13:43:10 +0900

>>>>> On Mon, 10 May 2004 12:39:53 -0400, 

> atateful assignment; we've never found a need for such assignment in DHCPv4.

Okay.

> Although exactly where prefix delegation falls is a little unclear...

I think prefix delegation is a kind of "managed address configuration"
(corresponding to the M flag), rather than "other configuration
information".  If a PD requesting router wants to get some "other"
configuration information like DNS recursive server addresses as well,
it can do that in the normal request/reply exchanges for prefix
delegation.  Note that only getting the "other" information does not
make much sense in this case, because the delegated site will almost
not be able to do anything meaningful without a global prefix.

And, in any event, I believe we can separate the PD case from this
particular issue for rfc2462bis since PD is not expected to be invoked
via RA.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 May 2004 13:58:48 +0900

>>>>> On Tue, 11 May 2004 09:40:45 +0200, 
>>>>> Stig Venaas <[email-masked]> said:

> address or IPv6 multicast address. Or it could be none-address resources.

I would say this kind of configuration information is out of scope of
the discussion for the O flag.  IMO, such information is rather
"managed" one corresponding to the M flag (of course, opinions on this
may vary because the meaning of the "other" configuration is not very
clear in RFC2462).

> must stick to the RFC 3736 subset.

We can always imagine any possibility.  Considering reality, however,
I would leave it for future extensions instead of including it in the
scope of the O flag.

First, as Ralph said, this is the reality from experiences of DHCPv4.
Secondly, the combination mess I explained in an earlier message would
be very likely to happen (even though it's just a "theoretical
analysis" right now:) whereas the possibility you raised is an
imaginary one at the moment as you yourself noticed.

					JINMEI, Tatuya