Subject: Design team teleconference, 8/31

From: Ralph Droms <[email-masked]>
Date: Fri, 01 Sep 2000 16:27:19 -0400

We held a DHCPv6 spec design team teleconference on 8/31.  The purpose of 
the teleconference was to develop a plan for getting the spec ready for 
final WG review in San Diego, followed by a WG last call in early 
January.  To meet that goal, we put together a calendar of milestones to be 
accomplished over the next four months and a list of issues that need to be 
resolved in the current spec.

This message will summarize the outcomes of the meeting.  I will follow up 
with a list of discussion items and dispositions later today and a full set 
of minutes early next week.

Participants:

Mark Stapp          [email-masked]
Rich Woundy         [email-masked]
Michael Carney      [email-masked]
Jim Bound           [email-masked]
Bernie Volz         [email-masked]
Richard Jones       [email-masked]
Thomas Narten       [email-masked]
Ted Lemon           [email-masked]
Barr Hibbs          [email-masked]
Bernard Aboba       [email-masked]
Francis Dupont      [email-masked]
Josh Littlefield    [email-masked]
Subir Das           [email-masked]
Tony McAuley        [email-masked]
Ralph Droms         [email-masked]

Outcomes:

Milestones and calendar
-----------------------
  9/30/2000 Publish revised spec, with changes
            based on design team teleconference
10/10/2000 Interim WG meeting to review revised
            spec
11/15/2000 Publish final spec for WG review in
            San Diego, based on input from WG
            review on 10/10
12/1x/2000 Final WG review in San Diego
  1/ 5/2001 WG last call

Discussion Issues
-----------------
We discussed the following issues, which were generated from design team 
input prior to the teleconference.  The issue numbers are from the original 
list of issues; the design team edited the list during the teleconference 
to generate this final list.

The design team performed a triage on the list of issues, dividing the list 
into

YES         - do it now
FUTURE WORK - consider in future
<name>      - responsible person
TRANS. DOC  - include in a (yet-to-be-written)
               transition doc
DEFER       - reconsider later for current doc

YES     1. Use of multicast instead of broadcast

TED     2. Use of globally-unique "client identifier": link-local
            address may not be sufficiently "permanent" for client lease
            identification
         20. Support a client-identifier hierarchy, a la DHCPv4.

DEFER   3. Cleaner and simpler message formats.
         10. Smaller DHCP message header for B/W efficiency.
         16. A single fixed header for (at least) Solicit, Advertise,
             Request, Reply, and Release messages, rather than
             different headers for different messages, with most
             information in extensions; get rid of mode bits wherever
             possible; multi-bit numbers should be 8, 16, 32, 64 or 128
             bits; there should be no reserved fields in extensions.
         27. Any bits in extensions that change the meaning of the
             extension type for the whole extension should be
             represented as new extensions.
         28. The client, when it is referring to an address it wants to
             renew, should be able to reflect back at the server the
             exact IP Address extension that it got from the server,
             rather than having to tweak it.

YES     4. Avoid stateful server (in terms of the protocol
            interaction).  Clarifications:
            - Correct server operation will not depend on XID
            - Clients will use XID consistently to allow for server
              optimizations

YES     5. Reduce number of ways to release resources

BERNIE  6. Where appropriate, keep v4 and v6 options/extensions "the
            same". Use the same option numbers. Use the same format
            (except for 16-bit type/length).

FUTURE  7. Define DHCPng as ONE new protocol can that can accommodate
WORK       IPv4 and IPv6 address assignments.

YES     18. Simplify reconfiguration; Use DHCPv4-style reconfiguration
         8. 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.
         9. 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?
BERNIE  -  Implement multicast reconfigure?

MARK    11. Reduce the number of messages to configure a node; e.g.
             - a two-message lease binding
             - permitting a client to obtain 1-n addresses as needed
               rather than all at "boot" time

FUTURE  12. To rapidly configure roaming users, avoid ND Neighbor
WORK        Solicitation and Neighbor Advertisement, both for the link
             local addresses and the address given by DHCP.

FUTURE  13. Configure a router's interface if it is on the same link
WORK        as the DHCP server.

FUTURE  14. Define a new interface to DHCP for doing things such as
WORK        adding a new address pool, changing some configuration
             parameters, or being able to request a new address pool.

DEFER   15. No state transition diagram in spec

YES     17. Use the delayed authentication mechanism that dhcpv4 has
             been developing.

FUTURE  19. Consider IPv6 address compression.
WORK

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

TED     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'?

BARR    23. Relay agents - adopt DHCPv4 function: relay agents insert
             interface address in 'giaddr' and forward to DHCP servers
         26. Relay agents should simply encapsulate the client message
             in a DHCPv6 extension; the relay message should have its
             own type.

YES     24. Discard references to "releasable resources"

FUTURE  29. Releasable resources should be documented in a separate
WORK        draft.

TRANS.  25. What happens when the network type is ambiguous - could be
DOC         IPv6, could be IPv4.

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 23:39:28 -0400

Was not clear what thread to post this too.  But one of the discussions
was the name of the messages.  The current DHCPv6 message names
correspond directly to Neighbor Discovery rfc 2462 thats where they came
from.  I think it more important to stay in synch with that part of IPv6
than DHCPv4.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 23:50:47 -0400

dhcpv6 message names correct:
whoops specifically solicit and advertisement.  request, reply, and
release were from dhcpv4.  reconfigure was new concept.

regards,
/jim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 15:32:35 -0400

At 11:39 PM 9/7/00 -0400, you wrote:
>was the name of the messages.

Right - I'm not sure we actually got that thread kicked off.  It was my 
question - do we need different semantics and message names for DHCPv6 or 
can we reuse the technology from DHCPv4?

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?

>   The current DHCPv6 message names

If the messages are really different messages - with different semantics - 
then sure, we should go with RFC 2462.  If the DHCPv6 messages walk and 
quack like DISCOVER/OFFER/REQUEST/ACK then that's what we oughta call 'em...

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 00:27:36 -0400

>quack like DISCOVER/OFFER/REQUEST/ACK then that's what we oughta call 'em...

But they don't look like them at all or even remotely resemble them at
all.  Or the behavior affect of the server from the messages.

One example is that in DHCPv4 the server awaits after the OFFER to hear
back.  In DHCPv6 now the server has to keep no state after the
advertize.  I think thats a better model than DHCPv4 and servers don't
have to keep state the advertize in DHCPv6 is stateless.

Also the DHCPv6 client code will live in very close proximity to the
stateless client if you will for IPv6 addrconf.  The message names in
DHCPv6 correspond to the syntax of ND.  So one can have:

nd_solicit
dhc_solicit
nd_advertise
dhc_advertise

so one could actually write one client to do both and thread/fork/spawn
the necessary processes to handle stateless or multiple client IAs.

I can go on but I think we need more WG discussion.

regards,
/jim

- Ralph