Subject: RE: Discussion Item - Using DHCPv4 options in DHCPv6 (Item 6 on C onfe rence Call Agenda)

From: Bernie Volz <[email-masked]>
Date: Thu, 14 Sep 2000 16:32:18 -0400

The only feedback I got regarding this issue was from Jim Bound who said:

	-----Original Message-----
	From: Jim Bound [mailto:[email-masked]]
	Sent: Thursday, September 07, 2000 12:34 AM
	To: DHCPv6 discussion list
	Subject: Re: Discussion Item - Using DHCPv4 options in DHCPv6 (Item
6 on
	Confe rence Call Agenda)

	Hi Bernie,

	I think this is a good idea.  As a note we did go thru the dhcpv4
	options (not the latest ones) and tried to copy them to dhcpv6 exts
	draft.  I strongly agree that it will be much easier for us in the
	future to look at options this way too.

	regards,
	/jim,

So, I assume everyone else is in agreement?

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Friday, September 01, 2000 9:41 AM
To: DHCPv6 discussion list
Subject: Discussion Item - Using DHCPv4 options in DHCPv6 (Item 6 on
Confe rence Call Agenda)

During the DHCPv6 conference call on Thursday, August 31st, I was assigned
the "responsibility" of coming to a resolution on item 6 on Ralph's compiled
list:

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

As I was one of the people that proposed this, let me give you my reasons.

While there are many options in DHCPv4 that are no appropriate to DHCPv6
(either because the options configure things that aren't appropriate or
don't exist in IPv6 or because they contain internet addresses), there are
many other options that are appropriate to both (such as domain names and
URLs). I'm not proposing that all DHCPv4 options be valid in DHCPv6. I'm
just proposing that we reserve option (or extension) numbers from 0 to 255
in DHCPv6 and adopt any of the DHCPv4 options that make sense in DHCPv6 and
use the same option numbers.

>From some point forward, all new DHCP options RFCs should have a statement
that indicates whether the option is valid in DHCPv4 and/or DHCPv6. And, for
those that are appropriate to DHCPv4, we use whatever limitations exist on
the number space (<256). For DHCPv6 only options, any number is valid.

For existing DHCPv4 options that are also valid for DHCPv6, we now only need
to write a document that indicates what these options are and that the
format of the option data is the same, though the option header now uses
16-bit option number and length. We don't have to re-specify the behavoir of
the client and server with respect to these options. Note also that while we
may feel that having DHCPv6 options for the DHCPv4 NDS ones makes little
sense, perhaps someone will find a need. In that case, they could easily
issue a 1 page draft (excluding the draft boiler-plate requirements) that
says DHCPv4 option x is valid on DHCPv6 with a 16-bit option number and
length. I think we'd all agree that reviewing these drafts is much easier
and faster than having to review the entire text again (since we'd then
likely want to add other rewording, etc.).

I am not proposing that we re-format the data of options (such as those that
carry internet addresses) for those would not work "as is" for DHCPv6. If
DHCPv6 needs that option, a new option should be defined to carry the data
appropriate to DHCPv6. Only those options where the data can be used "as is"
should be adopted in DHCPv6.

IANA must also only assign numbers from ONE space instead of having two
option spaces (DHCPv4 and DHCPv6) to consider. Though, IANA would need to be
instructed that options that apply to DHCPv4 would need to be assigned from
the current DHCPv4 space (0..127) and that DHCPv6 only options must be
assigned numbers >255.

This also allows for simplier configuration of DHCP servers should a server
support both DHCPv4 and DHCPv6. Or in storing options data in a database or
LDAP repository (as an author of the LDAP schema for DHCP, I'd like us not
to have a "dhcpv4option" and "dhcpv6option" attribute - much easier to have
just a "dhcpoption" attribute which can store either).

Doing the work do go through all of the DHCPv4 options to determine
applicability to DHCPv6 is likely not an easy task. So, my suggestion is
that as we develop the options we want for DHCPv6, we look to the DHCPv4
options. If we find an identical option in DHCPv4, we use that option number
and option data format. If someone later wants to add another option, they
write that 1 page draft I mentioned earlier.

What's the impact to DHCPv6 for doing this? I think almost nothing except to
reserve options 0 to 255 and use the DHCPv4 option numbers (and data format)
if and only if appropriate.

So, with that ... let's start the discussion. As we did not set a deadline
at the conference call, other than stating a week, and given the Labor Day
holiday, I'd like to conclude this discussion by end of day Friday,
September 8.

- Bernie Volz
  IPWorks, Inc.