Subject: RE: Things I want to see in DHCPv6

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 10:11:40 -0400

I essentially agree with Ralph on his list. Here are some
additions/comments.

- Use of multicast instead of broadcast (I'm not sure what our "base" for
the list of things is so this may already be assumed).

- Use of "client identifier". As I understand it, the current DHCPv6
specification uses the client's link local address as the identifier for the
client. However, with all of the generation techniques I recall for IPv6
link local addresses, this usually means it is based on the interface's
hardware address or randomly generated (for privacy). Therefore, while
perhaps a unique identifier, it certainly isn't a "permanent" identifier for
the client and hence not that useful from an administrative point of view.
That's what the idea behind the IPv4 client identifier was. Perhaps there
was a reason this concept was dropped (if so, why is not documented in
Appendix A of the DHCPv6 draft)?

- Cleaner and simpler message formats. In the new DHCPv6 draft, too many
bits being used as flags - should be using more extensions/options. Too
tight packing is being used (while saving bits is good, I think it went too
far). One case of a simpler messages ... in the current DHCPv6, on a solicit
message a client can set a bit to get the prefix list back (as an
extension). Why have this bit? Why not simply have the client include the
ERE extension in the solicit to request the prefix list extension. Consider
if we have 50 allocatable resources that require similar semantics - do we
have 50 bits available? Seems to me that using the ERE in this case is much
more consistent with the way DHCP should work.

A few other examples:
	- 9-bit solicit id. Why not just use 16-bits?
	- Why move solicit-id location between a Solicit and Advertise
message (better to leave in same bits)?
	- Solicit/Advertise/Request/Reply/Release all have a very similar
header but they are all different. Can't we have one header for these?
	  For example:
		1-byte msg-type, 1-byte flags/reserved, 2-byte transaction
id
		16-byte client's link local
		16-byte relay-addrses
		16-byte server-address
		<encode everything else into extensions>
I do want to see smaller packet formats - the BOOTP legacy should be
discarded (as it was in the current DHCPv6 design).

- Avoid stateful server (in terms of the protocol interaction). I believe
there are some holes in the DHCPv6 design in terms of the "releasing of
resources". If a duplicated Request is received by a server immediately
after sending a Reply with allocations, the server has to know this was
duplicated otherwise it might release the assigned addresses (since the
Reply contained an address assignment, but the duplicated Request tells the
server to release this (and any other) resources).

- There are also to many was to release resources. While I think it is a
nice design to allow "all" resources to be released, I don't see a need to
have a "release all but". If the client knows the resources it has, it can
simply release those that it not longer needs instead of doing an "all but".
If the client doesn't know what resources it has, the solicit with "release
all" is great to get rid of any old resources.

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

- Consider the DRCP requirements. The current DHCPv6 spec does address
several of these, such as more compact messages.

- Finally, if I had my choice, I'd like to see a DHCPng were ONE new
protocol can accommodate IPv4 and IPv6 address assignments. The protocol
would allow operation over either IPv4 or IPv6 and address assignments can
be done at the same time (regardless of which transport is being used). In
the short term, I think this would speed the deployment (one code base and
with benefits to the IPv4 community). One could argue that the v4 capability
eventually will not be required. I buy that, but how long do you believe
that will take? Now, I don't see that as a major change to the current
DHCPv6 design. We just need to have extensions that request IPv4 vs IPv6
addresses and either move all addresses (such as relay-agent, etc) into
extensions instead of in the fixed header or have a means to identify the
addresses (perhaps simply using the IPv6-mapped-IPv4 (or whatever they are
called) addresses). Perhaps even that isn't required because the server
would know if the packet was received over a v4 transport, they must be v4
addresses and if on a v6 transport, they must be v6 addresses.

I also have one item that I feel needs clarification on Ralph's list:
>   * One interface, with a single unique identifier, can be assigned
>     multiple addresses

In IPv6, does this mean one address per prefix on the "interface" (with
multiple prefixes being supported) or does it mean that the client can also
obtain MULTIPLE addresses for the same prefix. I would hope both. It is not
clear exactly how this would easily be achieved - how to tell the difference
between a duplicate request (without caching transaction ids) and a request
for a second (or third...) address. If done in a single request, having
multiple IP Address Extensions could be used. But if done in multiple
requests, it is not as easy. I guess it might first be worthwhile to
consider why we need this - sounds like a useful feature, but would it be
used and for what reasons?

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
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.  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 15:44:36 -0400

Hi Bernie,

Response to Clarification question ONLY:

Clarification
>I essentially agree with Ralph on his list. Here are some
Ralph stated he wanted the 2131 message types but later you say you
don't want the boot OP param and multicast is a good thing?  Can you
clarify more as I know Ralph better and I think I know what he is saying
but not clear which way your going here and if you completely agree with
Ralph or want to amend that agreement?  Just for message "syntax" not
semantics as I realize that stuff will have to be at the meeting. thanks

>used and for what reasons?

In IPv6 stateless the node first configures its EUID and for now
implementations are doing the Aggregatable format for IPv6 which implies
a 64bit EUID.  This 64bit EUID is also used to create the nodes 
link-local address by adding an architectural defined constant FE80 to
that and bingo one has a link-local address.  If you watch many of the IPv6
nodes boot up at bake-offs when the OS is being loaded on the screen in the
case of UNIX you see "configuring link-loal address" so by the time the
login prompt appears the node has a link-local address and it is unique
on the link via duplicate address detection and the node can converse on the
link with any other node using its link local address.

So lets assume for clarity that the EUID for mynode interface #1 
is "34" when I attached the link-local prefix to it the link-local 
128bit address is FE80::34 this would be the present client link-local 
address in the existing dhcpv6 messages.

Then a router appears on the link and starts sending out Router
Advertisements as ICMPv6 messages (no more ARP stuff) with a list of
prefixes and sets the bit telling the nodes you can use these prefixes
to configure your addresses.  Lets say the router sent out the following
prefixes:

  3ffe::/64
  2ffe::/64

So at mynode for interface #1 with EUID of 34 I can now configure
addresses as follows:

  3ffe::34
  2ffe::34

And I don't have to run duplicate address detection again as I did for
the link-local and as the EUID did not change.

If I had interface #2 with EUID 53 on the SAME LINK I could configure
two addresses for that interface as:

  3ffe::53
  2ffe::53

What IPv6 gurantees is that link-local addresses will not be duplicated
on a link (IPv4 subnet).

DHCPv6 has used the client link-local address as the dhcpv4 client
identifier and we actually did a have a lot discussion on this years ago
but that was before the Ipv6 Privacy paranoids got involved and
anonymous address have been added to the mix.  This presents a new issue
as you succinctly pointed out and it did for all of our IPv6
implementations too.  I will stop there per Ralphs suggestion to not
discuss input yet.  But at the meeting I can expound on how we have
dealt with that for neighbor discovery and IP over foo issues.

One of the unstated goals of dhcpv6 was to be able to emulate the same
capabilities from a dhcpv6 server to a dhcpv6 client as the router did
with prefixes.  In addition to also using the existing dhcpv4 model
where you give the client a complete 128bit address.  The idea was to
let the user to pick their pain.  But the client in either model can
communicate on the link always with multicast or unicast using its
link-local address as its source address in the IPv6 header.  Hence, it
can get to onlink servers or to onlink relays or generically to agents
on the link.

Hope this was helpful,
/jim