Subject: RE: DHCP Option Tag Exhaustion (1..127)

From: Ralph Droms <[email-masked]>
Date: Fri, 30 Mar 2001 13:04:52 -0500

Option 3 has already been considered and rejected by the WG.  I wrote the 
draft using tags 126 and 127 to expand the existing address space through 
encapsulation.  The WG consensus was that option 2 is the right way to go 
and we have a draft describing a new option code space.

It's not clear we are in an emergency yet.  There are 10-15 option codes 
that were reserved before the current option assignment rules (BCP 43, RFC 
2939) were put in place but were never formally assigned to an option 
(usually because the option was never accepted as a Proposed Standard).  I 
started to go through the list of assigned option codes once upon a time 
but never followed through to submit a list to IANA of codes that could be 
reassigned.

- Ralph

At 08:39 AM 3/30/2001 -0800, Joe Aiello wrote:

>Option 3 seems a good choice.  There is already a draft that is a good 
>model (Ted's) and would provide a large number of new option codes.  I 
>assume IANA will still assign the options and may have a slight 
>modification to their process.
>
>
>
>Folks like me who have requested a new option be  assigned for their draft 
>(draft-aiello-dhc-appliance-class-01.txt, and if you are interested in 
>being a co-author or would like to provide some industry support, contact 
>me), may have some relief   I know, that was a shameless act of self interest&
>
>
>
>Thanks Bernie for bringing this up.
>
>
>
>
>
>-----Original Message-----
>From: Bernie Volz (EUD) [mailto:[email-masked]]
>Sent: Thursday, March 29, 2001 12:22 PM
>To: DHCPv4 discussion list
>Subject: DHCP Option Tag Exhaustion (1..127)
>
>
>
>Folks:
>
>This message is to start (or restart) the discussion (on the WG mailing 
>list) around addressing the likely upcoming exhaustion of the DHCPv4 
>option space. As specified in RFC 2132:
>
>         Option codes 128 to 254 (decimal) are reserved for site-specific 
> options.
>
>Thus, we only have option codes 1 to 127 available for IETF specified 
>options. Values 0 (pad) and 255 (end) are otherwise used [RFC 2132].
>
>The most obvious solutions I believe are:
>1. Expand the range of IETF specified options by reclaiming some range in 
>the 128 to 254 range.
>2. Use a new magic cookie value to specify a 16-bit option space.
>3. Use one of the remaining unassigned option tags (<128) to encapsulate 
>new 16-bit options (or perhaps simply to extend the option space by 
>another 256 values).
>
>If there are other solutions, it would be useful for these to be discussed 
>as well.
>
>Here's some initial comments on the solutions listed above proposed:
>
>1. Expand the range of the IETF specified options by reclaiming some space 
>in the 128 to 254 range.
>
>This would require collecting information on which values are currently in 
>use (unless that usage is very self contained and easily redeployable to a 
>different value). For example, Microsoft uses several values in their 
>products which would be difficult to change because of the large number of 
>hosts in the market.
>
>Perhaps the range from 160 to 223 may be available (that is based on my 
>probably incorrect belief that people would start at one end of the range 
>or the other).
>
>The pro for this approach is that it really requires no code changes in 
>clients or servers (other than to implement the new options when they are 
>defined).
>
>The con for this approach is we might not learn of all of the options in 
>use and therefore cause a collision with an existing option.
>
>2. Use a new magic cookie to specify a 16-bit option space.
>
>This seems fairly straight forward in theory. If the new magic cookie 
>appears in a DHCP (BOOTP) packet, the new client and server simply use the 
>16-bit option format proposed for DHCPv6 (16-bit tag followed by 16-bit 
>data length following by the data). Options 0 to 255 would retain their 
>same meaning whether in the 8-bit or 16-bit format.
>
>One issue is how do the client / relay / server negotiate the use of the 
>new format? Does the client send a Discover with the new magic cookie and 
>if it receives no replies after some number of attempts, fall back to the 
>old magic cookie? Does it send two Discovers (one with new and one with 
>old)? If a relay receives a packet with the new cookie, it won't forward 
>it(?). Thus, this requires that both relays and servers be upgraded in 
>order for the new format to be available to servers behind relays?
>
>And, of course this requires fairly substantial code changes in clients, 
>relays, and servers.
>
>So, the pro for this approach is rather limited - we achieve our goal.
>
>The cons for this approach are rather large:
>- Major code changes
>- Relays and servers need to be changed at same time (otherwise changing 
>servers does no good for clients behind a relay)
>
>- DHCP traffic is increased with the client sending multiple Discovers 
>(and servers perhaps sending multiple offers) to find out whether a server 
>can support the new format.
>
>3. Encapsulation.
>
>We define a new encapsulation option. In its simplest form, this option 
>would encapsulate 16-bit formatted options (formatted like DHCPv6 
>options). Using Ted Lemon's new concatenation draft 
>(draft-ietf-dhc-concat-*.txt), this encapsulation option could easily be 
>more than 255 bytes in length. In other forms, perhaps we use a 16-bit 
>option code by 8-bit length. Or we us an ASN.1 like number encoding - each 
>byte of the option tag and option length encodes 7-bits of data and one 
>bit specifies whether another byte of tag (or length) follows.
>
>The format for the basic option is:
>
>     Code   Len      Extended option 1       Extended option 2
>    +-----+-----+-----+-----+-----+-----+--- ... 
> ---+-----+-----+-----+-----+...
>    | TBD | Len |   ETAG1   |   ELEN1   | EDATA1... 
> |   ETAG2   |   ELEN2   |...
>    +-----+-----+-----+-----+-----+-----+--- ... 
> ---+-----+-----+-----+-----+...
>
>While any option COULD be encapsulated, existing options (tag < 256) 
>SHOULD NOT be encapsulated (since they do not need to be).
>
>A client that supports this technique would advertise that fact to a 
>server by including the tag assigned to the encapsulation option in a 
>Parameter Request List option (55). A client would also include any 16-bit 
>options it wanted by encapsulating an "Extended Parameter Request List" 
>option in an encapsulation option (the client could of course include any 
>additional options as well). This "Extended Parameter Request List" option 
>would be a new option, assigned from the >255 tag list, which is 
>essentially identical to the existing Parameter Request List option except 
>that 16-bit option values are used.
>
>Note: The "Extended Parameter Request List" option could be a 8-bit option 
>(which would eliminate the need to encapsulate it).
>
>The pros of this approach are that no changes to existing clients and 
>servers are needed (unless they want to support new options >255). We can 
>start assigning new options and clients or servers that want to implement 
>them can. No impact to relays as they pass the options on as before (just 
>data to them). If new relay agent type options are needed, they too could 
>be assigned in the >255 range.
>
>The cons of this approach are minimal, when implementing the FIRST >255 
>option, additional client, server, or relay work is needed. And, I guess 
>to be fair, some bytes are "wasted" in the encapsulation option overhead. 
>But, that's fairly minimal.
>
>
>
>Of course, my preference is for the Encapsulation technique (3).
>
>If there are additional techniques that might have been discussed in the 
>past or that you think of, or you feel that I've misrepresented the 
>techniques, pros, or cons, please comment.
>
>- Bernie Volz
>   Ericsson

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Fri, 30 Mar 2001 11:59:05 -0800

> From: Ralph Droms
> Sent: Friday, March 30, 2001 10:05 AM

> that were reserved before the current option assignment rules
> (BCP 43, RFC 2939) were put in place but were never formally assigned to
> an option (usually because the option was never accepted as a Proposed
> Standard).  I started to go through the list of assigned option codes once
> upon a time but never followed through to submit a list to IANA of codes
> that could be reassigned.
>

I've forgotten now how long ago I proposed two possible ways of obtaining
relief that were rejected by voice vote at a Working Group meeting, but I'm
going to throw them out again to the mailing list.

1.  Establish "Sunset" rules for DHCPv4 Options

Certain options are absolutely required by the base protocol, but many are
simply convenience items.  Examples include things like "Default IRC
Server."  For non-mandatory options, IANA could establish a sunset date, say
5 years after adoption of the option code.  At the sunset date, any option
which could not muster support (based on actual usage) would be retired, and
its code available for reuse.

This approach has a number of problems, as pointed out by Thomas Narten, not
the least of which is burdening IANA with yet another task, and the
necessity of making each non-mandatory option a separate RFC to have
individual control over the assigned option codes.

It has the distinct advantage of preventing the v4 option space from
becoming bloated over time with unused and forgotten options.

2.  Establish a "Demonstrated Use" Rule for New Options

When a new option is proposed in an Internet-Draft, it's status would be
"Experimental" rather than "Standards Track" until a minimum number of
interoperable implementations (for example, three) could be demonstrated.
Only then would the option be promoted to "Standards Track" status, thus
permitting easy reclamation and reuse of options that seemed like a good
idea, but which don't make it into actual usage.

This has the disadvantage of lengthening the document cycle, but it does
have a built-in regulatory mechanism in the form of demonstrable,
interoperable implementations.

-----

Neither of these proposals diminishes the value of considering how we could
significantly enlarge the v4 option space, but there is also the ugly
question of should be trying to extend the useful life of DHCPv4 at all?
Doesn't that reduce the likelihood of DHCPv6 being adopted widely?  That is
also something we should perhaps debate here.

--Barr Hibbs
  UltraDNS Corporation