Subject: Discussion: Names and semantics of messages

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Oct 2000 15:33:19 -0400

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: Bernie Volz <[email-masked]>
Date: Thu, 19 Oct 2000 15:48:33 -0400

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. 

- Use options. We know and "love" these (don't we?). I agree this is perhaps
on the surface contrary to what I said above regading the messages names,
but we've been talking about 16-bit options for DHCPv4 already and really
all we're changing is to use the 16-bit format. Also, per previous
discussions about carving out the DHCPv4 option space from the DHCPv6 option
space and 'reusing' the options that are the same, it is cleaner to talk
about options only - not options and extensions.

- 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

- Ralph

---

From: Bernie Volz <[email-masked]>
Date: Tue, 24 Oct 2000 16:03:34 -0400

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

Oh, when don't I have input???

If we wanted to switch the DHCPv6 messages to be more like DHCPv4 messages,
we'd have to have the DHCPSOLICT (or DHCPDISCOVER) include more details,
such as the address binding information (since a DHCPOFFER includes
addresses). Also, this means that the DHCPv6 model would have to reserve
addresses for clients that might not even use that server - I think that was
one of the benefits of the DHCPv6 model. Perhaps this is not a significant
issue as the IPv6 address space is so vast that wasting some addresses isn't
a big deal.

Also, if you keep DHCPOFFER functionality, the "C" bit WILL BE REQUIRED in
the DHCPSOLICIT (DHCPDISCOVER) because if the server's going to allocate
addresses, it needs to know to discard any old ones before it does that.
And, there's also the question of whether "C" means discard all addresses
for this client or only for this address binding (for the client).

You can easily see that adopting the DHCPv4 semantics will cause many other
changes and impacts. Do we have time to review all of these and make sure
we're clean?

I personally would like to keep the DHCPSOLICIT and DHCPADVERTISE. Jim also
gives some good arguments for keeping the names IPv6ish (to match ND and
addrconf). But my personal view is if it doesn't quack like a duck, smell
like a duck, walk like a duck, it ain't a duck.

If you want to change the DHCPREPLY to a DHCPACK (and DHCPNACK), I have less
of an issue with that name change as the functionality is very similar
there.

I think we're already keeping DHCPRELEASE?

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Tuesday, October 24, 2000 12:21 AM
To: DHCPv6 discussion list
Cc: [email-masked]; [email-masked]
Subject: Re: Discussion: Names and semantics of messages

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

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.

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

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?

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

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