RE: [dhcwg] Re: Extending the DHCPv4 option codes

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: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of
Michael Johnston
Sent: Monday, October 06, 2003 6:42 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: [dhcwg] Re: Extending the DHCPv4 option codes

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 

Ralph Droms writes: 

> 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
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg