Subject: RE: Discussion: Names and semantics of messages

From: Kim Kinnear <[email-masked]>
Date: Thu, 19 Oct 2000 16:26:17 -0400

At 03:48 PM 10/19/00 -0400, Bernie Volz wrote:
>I do think I agree with your summary and level of disagreement.
>
>My views:
>
>- Keep the message names as they are in the DHCPv6 draft. The message
>formats and meanings are different and thus I think the message names should
>be as well. 

         I would agree if the question was just about the message
         names, but as I read Ralph's email the issue is also
         about semantics:

Arguments for using names and semantics from RFC2131/RFC2132 include:
                               ^^^^^^^^^
* DHCPv6 draft message semantics are close to RFC2131 message
    semantics
* no compelling reason to change
* reusing RFC2131 names and semantics captures knowledge base
    from DHCPv4 design, deployment and operation
         
         If indeed the semantics are similar enough that we can
         make them essentially identical (or a clean extension),
         then we would be foolish indeed to make them needlessly
         different.

         Reusing the existing RFC2131 semantics (and thus the
         names) would yield enormous dividends across a wide swath
         of the industry, from tech support to sniffer vendors,
         from training to marketing -- to say nothing of making
         the implementation job much more straightforward.

         If we *can* reuse (and perhaps extend cleanly) the
         existing RFC2131 semantics (and thus the names) we *must*
         consider doing it!  I think the discussion should be
         centered on whether we *can* do this.

         Cheers -- Kim

[...]

>- Bernie Volz
>
>-----Original Message-----
>From: Ralph Droms [mailto:[email-masked]]
>Sent: Thursday, October 19, 2000 3:33 PM
>To: DHCPv6 discussion list
>Subject: Discussion: Names and semantics of messages
>
>
>We discussed the following issue from the 8/31 phone conference without 
>much progress towards consensus:
>
>          22. Messages and semantics
>              * Rename messages and change semantics to match RFC2131
>              * Use message exchanges from RFC2131
>              * Change formats to optimize message size and carry IPv6
>                addresses
>          30. Why 'extensions' and not 'options'?
>
>Arguments for leaving the names and semantics as they are in the current 
>DHCPv6 draft include:
>
>* these names correspond directly to names Neighbor
>    Discovery (RFC2462) messages
>* DHCPv6 draft messages don't look or act anything
>    like RFC2131/RFC2132 messages
>* Merged DHCPv4-DHCPv6 ("DHCPng") is future work
>
>Arguments for using names and semantics from RFC2131/RFC2132 include:
>
>* DHCPv6 draft message semantics are close to RFC2131 message
>    semantics
>* no compelling reason to change
>* reusing RFC2131 names and semantics captures knowledge base
>    from DHCPv4 design, deployment and operation
>
>So, there is my summary of the current position of the discussion.  Once we 
>have agreement about this level of, well, disagreement, we can pick up the 
>discussion.
>
>I'm not sure "options" vs. "extensions" has been discussed in any mailing 
>list e-mail.
>
>- Ralph

---

From: Jim Bound <[email-masked]>
Date: Sun, 22 Oct 2000 22:17:18 -0400

Kim,

>Arguments for using names and semantics from RFC2131/RFC2132 include:

I agree and the semantics of solicit, advertise are completely different
than OFFER and I think also has optimizations over DHCPv4.

They are not similar or even close semantically or their behavior.

Not if the semantics are different and that will cause pain in fact if
they are different they should be different.  And they are not the same.

I don't agree.  What we have designed will work as messages and within a
transaction based architecture which dhcpv6 is.  Also I would argue our
objective is to get a draft out and I think a bit more than it will feel
better is a reason to change the dhcpv6 messages.

I would like to hear technical and architectural reasons why some other
message type than the ones we have will work better.  

regards,
/jim

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Oct 2000 17:36:01 -0400

Before I respond to Jim's comments, let me make it clear that I am writing 
as a technical contributor, not as document editor.  Also let me point out 
that, as technical contributor, I may chime in with opinions that differ 
from Jim and Mike's.  Regardless of those inputs, I will make every effort 
in my role as document editor to capture the consensus of the WG.

>They are not similar or even close semantically or their behavior.

We need to consider the fundamental requirements of the client-server 
message exchanges over and above their definition in the current DHCPv6 
draft spec.  Certainly, there are differences between the semantics (and 
names) of the DHCPv6 messages and the RFC2131 messages.  But, are those 
differences inherent in the

>they are different they should be different.  And they are not the same.

Jim, we disagree about this point.  In an earlier message to this list 
(Subject: Re: Design team teleconference, 8/31, Date: Thu, 14 Sep 2000), I 
wrote:

>For example, the DHCPv6 Solicit message now acts pretty much like the
>DHCPv4 DHCPDISCOVER message (allowing for differences in the message
>formats).  The Advertise message acts pretty much like a DHCPOFFER, except
>the Advertise doesn't include any offered parameters.  is there a reason
>for the difference or could we include parameters in the DHCPv6 message and
>call it a DHCPOFFER?

I've walked through the other DHCPv6 messages and am prepared to defend 
(although I haven't written down the details) the claim that we can reuse 
the DISCOVER/OFFER/REQUEST/ACK messages in DHCPv6.

>message type than the ones we have will work better.

For me, the question is not whether some other set of messages will work 
better; rather, the question for me is whether we need to redesign the 
DHCPv4 messages and exchanges.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Tue, 24 Oct 2000 00:20:38 -0400

>differences inherent in the

Not sure if my mail trashed the last part of your sentence?  I will
respond to parts below as the last part of this could say different
things.

>the DISCOVER/OFFER/REQUEST/ACK messages in DHCPv6.

The solicit below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 1 |C|P|  reserved |  prefix-len |   solicit-ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+o

The "C" bit will be gone I believe from consensus (just use release).

The "P" bit says return me a list of prefixes.  

The prefix-len tells the server the relays bits in the prefix.  

The solicit ID permits the client to differentiate between servers using
a different solicit ID we permit per input on previous draft.

The Solicit message is Multicast.

The Solicit does not let a client suggest addresses as in DHCPDISCOVER.

If we look at a solicit vs a DHCPDISCOVER on a datascope or tcpdump they
look completely different and are not identifiable.

The purpose of it is as a DHCPDISCOVER with new features.  Solicit is
the terminology in ND and addrconf and the messages do not have the same
content and therefore I believe they should be different. 

Advertise:

     0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 2 |  reserved   |   solicit-ID    |  preference   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              extensions (variable number and length) ...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Provides solicit-id to the client.
Provides preference value to client.
But note it does permit extensions.
Again Advertise is used in ND and addrconf.

I don't see the added value at all of making them the same as DHCPv4?

>DHCPv4 messages and exchanges.

I don't think so. DHCPv4 works with IPv4 fine and the messages are
appropriate.  DHCPv6 needs to work with IPv6 and the messages are
appropriate, and have continuity with ND and addrconf which is the
engineering  goal, so DHCPv6 interoperates efficiently with addrconf and
I could use Kim's argument for keeping them by saying operators will
become use to solicit and advertise with IPv6 and having them be discover
and offer is not congruent for IPv6 operators.  And at some point IPv4
will go away and in fact some customers will use IPv6 and DHCPv6 on
networks and not use DHCPv4 or other IPv4 thingees that will need DHCPv6
(e.g. 3GPP Mobile IPv6 networks).

Bernie also did not want to change them and may have other input too.

regards,
/jim