Subject: Things I want to see in DHCPv6

From: Ralph Droms <[email-masked]>
Date: Tue, 29 Aug 2000 13:18:00 -0400 (EDT)

Part of the deal in prepping for Thursday's DHCPv6 design team phone call
is to develop a list of "things we want to see" in DHCPv6.  So, here's my
list:

1. Address model:
   * One interface, with a single unique identifier, can be assigned
     multiple addresses
   * Server knows exactly what addresses to assign to client
   * Client asks for "configuration", which includes assigned
     addresses
   * Client may extend leases on addresses individually

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

3. Relay agents - adopt DHCPv4 function: relay agents insert itnerface
   address in 'giaddr' and forward to DHCP servers

4. Authentication - adopt DHCPv4 delayed authentication from latest
   I-D

5. Discard references to "releasable resources"

6. Use same options/extension in DHCPv4 and DHCPv6

7. Use DHCPv4-style reconfiguration

Reading the drafts is a prerequisite to participating in Thursday's phone
call.  Posting your own "things I want to see" list would be a good way to
demonstrate you've read the drafts and you're truly interested in
participating.

I'll collate any submissions into a list that I will publish prior to
Thursday's meeting.  We'll use that list as part of our formal agenda for
the phone call.

To avoid rat-holes, mailing list discussion of the *merits* of list items
will be disallowed.  Requests for clarification are OK and will help us
get consensus on the list of features to talk about on Thursday.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 00:28:55 -0400

Hi Ralph,

I would like to submit my state diagrams for people to use for
clarification of the existing message types as needed at the meeting so
I would ask that attendees have them at hand.

Can you give us an example of the format for discussion during the
meeting.  I would assume for anyone who wants to remove/change things 
in DHCPv6 they would need to state why and why whats there is not going
to work.  Likewise those who wnat to keep things in DHCPv6 would also
have to do the same.  They key is to have fair and equal exchange of views.

thanks
/jim

---

From: Ralph Droms <[email-masked]>
Date: Wed, 30 Aug 2000 14:22:41 -0400

>I would ask that attendees have them at hand.

Sure - just to make sure everyone has seen the URLs, the docs are at:

ftp://sipper.zk3-x.dec.com/pub/dhcpv6_state.ppt

and

ftp://sipper.zk3-x.dec.com/pub/dhcpv6_state.PDF

>meeting.

Following Ted's proposal, I expect to have a list of features to be 
includes or excluded.  I'll put that list together and e-mail it to list 
participants Thursday AM.  During the phone call, we'll discuss the 
features in the list one-by-one to determine consensus on the disposition 
of each feature.  I imagine the author of each list item will take the lead 
in explaining his position first, with followup by others on the phone call.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 15:10:14 -0400

Hi Ralph,

>in explaining his position first, with followup by others on the phone call.

OK.  How do those of us who "may" not support inclusion or removal or a
change to an item respond technically why its a good or not-so-good
idea.

For example: I will argue one of the advantages as a programmer I like
about the DHCPv6 message types is that I know the msg type immediately
as a client or server implementation right after the UDP header. In
DHCPv4 (ignoring the state machine issues) I have to look past the
DHCPv4 header and see the option if I don't want to build a state
machine.  

I know here at compaq in the technical community when engineers don't
agree on a design issue we hear boths sides of a change thats what I am
getting at.

thanks
/jim

---

From: "Ralph E. Droms" <[email-masked]>
Date: Wed, 30 Aug 2000 15:21:10 -0400 (EDT)

On Wed, 30 Aug 2000, Jim Bound wrote:
> >During the phone call, we'll discuss the 

Ah - perhaps the word "followup" isn't clear.  What I meant was
"presentation of opposing and supporting opinions"; i.e., everybody gets a
chance to talk about facts and opinions in opposition to or in support of
the list item in question.

- Ralph

---

From: Richard Johnson <[email-masked]>
Date: Wed, 30 Aug 2000 12:23:48 -0700 (PDT)

I have a few general comments on the draft(s).  I also have some more
specific comments on the text but will send them directly to the
authors instead.

DHCPv6:

*  I would like to suggest that if the DHCPv6 protocol can be made to
   work for DHCPv4 as well (which I think it can with a small amount
   of effort), we could then use this as a sort of "DHCPng" and only
   allow new options in DHCPng unless there's a really good reason for
   including it in DHCPv4.  This would strongly push everyone involved
   to implement DHCPng as fast as possible in order to gain support
   for new options.  This is very similar to what the DNSEXT group is
   doing with eDNS.

*  Might it be useful to allow Reconfigure and Reconfigure-reply
   messages to be sent via a relay to client's which do not have such
   reachable IP addresses, in order to inform them of changes in
   non-releasable resources?  The same thing could also go for
   Reconfigure-init to some extent.

*  Might a client send a Solicit in response to a Reconfigure-init?
   What if the topology changes such that this is necessary in
   order find a DHCP server with can allocate addresses on the new
   subnet?

DHCPv6 Extensions:

* In section 3 (DHCP Relay Considerations) the text reads:

   The DHCP Relay MUST NOT change any information in any DHCP Extension
   fields.  All Extension information flows between DHCP Server and DHCP
   Client without modification by any Relay.

I could easily envision some types of extensions which may REQUIRE a 
relay to change them.  At lease we need to allow for a relay to ADD
additional extensions, such as in the case of the "DHCP Relay Agent
Information Option" of DHCPv4.

* In section 4 (Releasable Resource Extensions) the text reads:

   A client MUST remember in non-volatile storage which server allocated
   which releasable resource, in order to appropriately manage the lease
   associated with that resource.

What if the client doesn't have non-volatile storage?

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 15:50:39 -0400

Hi Ralph,

>the list item in question.

Great... yes that was what I was not sure of.  3 hours seems long but I
bet we will use every minute of it.

thanks
/jim

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 30 Aug 2000 15:57:21 -0700

1.  Same header format for Solicit, Advertise, Request, Reply, and Release
messages.

2.  Keep fields in same location for all message types.

3.  Use of a unique identifier, one that is extremely unlikely to change, to
identify a client.  The DHCPv4 client identifier isn't globally unique, so
we need a better definition of how to generate an identifier.

4.  Where a DHCPv6 Extension is essentially identical to a DHCPv4 Option,
use the same name for both.  Otherwise, the DHCPv6 Extension names can be
completely independent.

5.  The message exchanges should be as brief as possible to support mobile
users by:  (1) reducing the number of messages if possible, (2) reducing the
size of messages by careful construction of headers and incremental
configuration, and (3) permitting a client to obtain 1-n addresses as needed
rather than all at "boot" time.

--Barr

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 31 Aug 2000 09:02:46 -0700

>   for new options.  This is very similar to what the DNSEXT group is

This sounds like a really bad idea to me. Protocols need to stand on
their own without having to hold hostages. If we're not confident that
DHCPng will be deployed without this then its a sign that we've designed 
the wrong thing. I would note that DNSEXT is not a very good model 
since most of their work has not been widely deployed.

>Information Option" of DHCPv4.

You'd need to be careful not to invalidate DHCP authentication in the
process, or end up requiring multiple authentication options, one
for the ones the server sends, and another for the relay agent inserted
ones. One of the things I like most about DHCPv4 is that these issues
seem to have been thought through (and excess complexity avoided).