Subject: Re: Things I want to see in DHCPv6

From: Tony McAuley <[email-masked]>
Date: Wed, 30 Aug 2000 16:30:34 -0400

We would like to add a few more items for discussion (in addition to
what has already been posted). This is based on our work on using
DHCP in a wireless environment (DRCP).

1. We would like to see a smaller DHCP message header for B/W
efficiency.
   One possibility is to eliminate the client link-local and relay
   addresses, and substitute a MAC address for identification.
   Any IP address information could be added as an option, which would
   also, as Bernie points out, simplify carrying IPv4 addresses too.

2. We would like to reduce the number of messages to configure a node.
   For example, include the address(es) of the DHCP server in the
   (Router) Advertisements, then the client could immediately
   unicast a request to the server. The Advertisement would also a) help

   roaming nodes detect the need to reconfigure and b) eliminates the
   need for clients to broadcast/multicast discoveries/soliciations.

3. To rapidly configure roaming users, we would like to avoid doing
   ND Neighbor Solicitation and Neighbor Advertisement, both for the
   link local addresses and the address given by DHCP.  Maybe this is
   beyond the scope of DHC working group?  We actually prefer DHCPv6
   to IPv6 Stateless autoconfiguration because we believe it can be
   faster. A DHCP server might precheck the addresses it will assign
   to clients.

4. We would like to be able to configure a router's interface if it
   is on the same link as the DHCP server.

5. We would like to define a new interface to DHCP for doing things
   such as adding a new address pool, changing some configuration
   parameters, or being able to request a new address pool.

Thanks
 Tony and Subir

---------------------------------------------------------------------------

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2000 1:18 PM
> To: DHCPv6 discussion list
> Subject: Things I want to see in DHCPv6
>
> 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.

---

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

Tony and Subir,

Responding to your note as IPv6 expert, implementor, and IPv6 Working
Group member not as DHCP WG member.  

>   need for clients to broadcast/multicast discoveries/soliciations.

This request is out of scope for this meeting.  What your asking for
here is a change to Neighbor Discovery protocol.  You need to take that
to the IPng list.  This happens before DHCPv6 will even be started by
IPv6.  But I really like the idea a lot.

But you might want to propose reducing the dhcpv6 message sizes for the
same reason.

>   faster. A DHCP server might precheck the addresses it will assign

Again same comment.
I am not sure not doing ND Solicitatin is a good idea it prevents black
holes as offline comment.

Hmmm.  How do you come up with it can be faster.  Don't get me wrong
every customer I have checked with will use DHCPv6 initially and not
Stateless simply for tight control and system mgmt thats why I am still
working on it.  Also for Mobile nodes. The only way I can see the 
performance win is if the clients are all attached by NBMA and Routing?  
(e.g. Cable, Set-Top Boxes etc...).
I would be very interested as an engineer how you came up with its faster.  
Really!!  I think I can see it for Mobile nodes that are dispersed too
but form their own prefix set across multiple links.  This is future
work on IPng WG list/charter too.  Example would be fleet of battleships
where specific fighter craft in each squadron has its own prefix for
team leader operations and are by definition mobile.  Stateless
autoconfig will not work for performance reasons because the discovery
operations will not be optimal for the routes and better to have dedicated
DHCP server.

thanks
/jim

---

From: Mark Stapp <[email-masked]>
Date: Wed, 30 Aug 2000 17:59:30 -0400

These lists have been pretty interesting, and I like what's been suggested 
by Ralph and Bernie. My list is:

1. We should make every effort to accomodate both ipv4 and ipv6 addresses. 
There would be a great deal of value in a dhcpng that could support both 
address flavors.

2. A single fixed header, rather than different headers for different 
messages. The header should have a version byte (or bitfield), a flags 
field, and a length, possibly in quads. Fields that appear in every message 
might as well be in the header: the message type, for example, should be in 
the header. Some kind of link-local address (a MAC address or v6 link-local 
address) might as well be in the header, because it's going to have to 
appear once in every message anyway. In order to support (1), we should 
either exclude ip addresses from the header, relegating them to extensions, 
or define two initial header formats to carry the two different ip lengths. 
I'd like us to examine the possibility that most information would go into 
extensions.

3. Support a two-message lease binding - something like the "committed 
offer" that some of us were talking about in Pittsburgh. It sounded as if 
this would be a big help to the wireless folks. It also makes removing 
fields from the header and placing their data in extensions more palatable. 
I'd like to see language that allows a client to request a "committed" 
offer by setting a flag in the header. Servers which responded with offers 
that set that flag would have to have committed the binding to stable 
storage, and may have been configured with a different (shorter) 
lease/renew/rebind times to use in these bindings.

4. Simplify client releases: define a single way to "RELEASE" leases, with 
a "RELEASE" message.

5. Use the delayed authentication mechanism that dhcpv4 has been developing.

6. Simplify reconfiguration. I like the notion of 'reconfiguration 
multicast groups', but I'd prefer that clients which see a RECONFIGURE 
simply attempt to renew their leases, rather than enter a new set of 
states. It should be the server's responsibility to manage the number of 
clients which are being reconfigured simultaneously, and to retransmit (at 
appropriate intervals) RECONFIGUREs to those that it doesn't hear back from.

7. Consider ipv6 address compression. Is it likely that much of the data in 
a dhcp message that contains v6 addresses will be v6 addresses, and that 
some of those addresses will share prefixes? It seems as if these are 
natural candidates for in-packet compression (at least in messages from 
servers to clients). Since some other extension data will be fqdns, they 
may be candidates for compression too.

8. Support a client-identifier hierarchy, a la dhcpv4. Clients which wish 
to use a random or persistent id should be able to do so. Those clients 
will still have to supply a MAC (in ipv4) or link-local address (in ipv6) 
in order for replies to be addressed to them. If I understood Charlie's 
message correctly, an application could use this capability to obtain a 
'new' dhcp address. Now, sometime I want someone to tell me more about 
applications that can poke the dhcp client on demand, and then tell the 
dhcp client and the stack to reserve the new address for its exclusive use. 
But _if_ that were possible, the client's use of a new client-id would let 
the _server_ allocate a new address.

-- Mark

---

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

>There would be a great deal of value in a dhcpng that could support both 

Can you provide a scenario in which this would be necessary? I've been
presuming that a dual stack client that wanted an IPv4 address would use
DHCPv4 over IPv4, and for IPv6, would use DHCPv6 over IPv6. Thus, I'm
not clear on the need to include IPv4 options in DHCPv6.