Subject: [dhcwg] Extending the DHCPv4 option codes

From: Ralph Droms <[email-masked]>
Date: Mon, 06 Oct 2003 16:04:42 -0400

By my rough count, once the option codes list in
draft-ietf-dhc-unused-optioncodes-07 are returned to the list of available
DHCP option codes, there will be about 20 option codes available for
assignment to new options.  We currently have fewer than five documents
specifying new options in the dhc WG document queue, leaving us about 15
option codes for future assignment.

draft-ietf-dhc-extended-optioncodes-00 proposes a couple of ways to extend
the list of available option codes.  At least one of the proposed mechanisms
would take some time to implement, so we should start a decision process now
to give us enough time to implement whatever mechanism we eventually settle on.

Please review draft-ietf-dhc-extended-optioncodes-00 and comment on the
proposed mechanisms.  Feel free to suggest an atlernative if you have a
better idea...

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Michael Johnston <[email-masked]>
Date: Mon, 06 Oct 2003 22:42:10 GMT

A few comments on three of the proposals outlined in the introduction.  From 
a DHCP client boot ROM point of view, this list is in my order of 
preference.

1.1:  Extending DHCP option codes using options 126 and 127.
Easy to implement and parse additional options with very little code 
overhead. 

1.2:  Using site-specific options.
Most of the additional options from 136 through 223 can be used without too 
many issues with large installations.  Options 128 through 135 are requested 
by all PXE (and many non-PXE) boot ROMs (including boot ROMs built into 
BIOSes) and are expected to be used by site specific pre-boot applications.  
If this route is taken, my suggestion would be to leave 128 through 135 and 
224 through 254 as site specific options. 

1.4:  New magik cookie with 16-bit options.
My biggest concern would be with operation with existing relay agents.  Has 
there been any testing in this area?
My next concern is with small boot ROM limitations.  It is tough enough to 
implement an IP stack + DHCP client + site features into 8kB through 32kB 
boot ROMs.  (Yes, I know that NICs with larger FLASH chips are available, 
but using the larger chips on a NIC or motherboard is usually not 
acceptable.)  Adding another layer of packet building and parsing code in 
some of the cases I have come across would not be possible. 

%%michael

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 6 Oct 2003 19:56:20 -0400

Michael:

Thanks much for the comments. I'll let a few days go by and then work on
updating the I-D with your comments.

Personally, I like using the site-specific options range because it puts all
options on an equal footing (using the extended options requires a more
significant implementation effort for the first option that makes use of
this extended space; though once done, additional options aren't significant
work).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Johnston
Sent: Monday, October 06, 2003 6:42 PM
To: Ralph Droms
Cc: [email-masked]
Subject: [dhcwg] Re: Extending the DHCPv4 option codes

%%michael

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Oct 2003 20:04:06 -0500

> My biggest concern would be with operation with existing relay agents. 
>  Has there been any testing in this area?

If we extend option codes by using options 126 and 127, it's no 
problem, because we just put the option extension code *after* the 
length, and then anything that doesn't know about these options skips 
them.   A simple relay agent would do fine with a different magic 
cookie too.   It would not do well with relay agents that implement 
option 82.   However, I think the simplest choice is to steal some of 
the site-specific options, which at this point are never used.

> My next concern is with small boot ROM limitations.  It is tough 
> enough to implement an IP stack + DHCP client + site features into 8kB 
> through 32kB boot ROMs.  (Yes, I know that NICs with larger FLASH 
> chips are available, but using the larger chips on a NIC or 
> motherboard is usually not acceptable.)  Adding another layer of 
> packet building and parsing code in some of the cases I have come 
> across would not be possible.
> %%michael

This also argues for just stealing some of the site-specific options.

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Oct 2003 12:40:38 +0700

Date:        Tue, 7 Oct 2003 20:04:06 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | However, I think the simplest choice is to steal some of 
  | the site-specific options, which at this point are never used.

I'd agree with that, but I'd expect the right answer, rather than
necessarily the simplest, will depend upon how long people expect
there to remain serious interest in extending DHCP (for v4).

That is, if you believe that people will still be inventing new options
for DHCP 10 years from now, the site specific option space will probably
run out as well, and there'd need to be yet another method invented to
add new options.   In that case, it would be better to simply add lots
more options now (using the 126/127 technique - and make the new option
numbers allocated out there 16 bits).

On the other hand, if the general belief is that while DHCP for IPv4 might
still be in use 10 years from now, no-one will care enough about it to
still be inventing new options, then all that's needed is enough option
codes to last that long - and in that case, the site specific option space
is quite likely the right way to go (there are only a few new options
defined a year it seems).

kre

---

From: Ralph Droms <[email-masked]>
Date: Wed, 08 Oct 2003 12:53:12 -0400

Since the publication of RFC 2132, there have been 17 new options added to 
DHCP (not counting the PXE options and the options in use by Apple; for 
details, see draft-ietf-dhc-unused-optioncodes-07).  Here's the breakdown 
of number of new options defined per year:

     1996 0
     1997 5 (RFC 2241, RFC 2242)
     1998 0
     1999 4 (RFC 2485, RFC 2563, RFC 2610)
     2000 3 (RFC 2937, RFC 3004, RFC 3011)
     2001 1 (RFC 3118)
     2002 3 (RFC 3361, RFC 3397, RFC 3442)
     2003 1 (RFC 3495)

(note that some RFCs define more than one option)

Seems to me the current option space might be good for five years and using 
even as few as options 128-159 might be enough to last us "forever"....

- Ralph