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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 29 Mar 2001 14:22:13 -0600

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: Dale Worley <[email-masked]>
Date: Thu, 29 Mar 2001 18:35:22 -0500

From: "Bernie Volz (EUD)" <[email-masked]>

   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.

I may be mistaken as to its significance, but there is a relevent item
in:

ftp://ftp.iana.org/in-notes/iana/assignments/bootp-dhcp-extensions/bootp-dhcp-option-126-127

The file itself is a copy of an e-mail request by Ralph E. Droms (who
is one of the authors of RFC 2131 "DHCP Options and BOOTP Vendor
Extensions") to allocate option codes 126 and 127 for extension
purposes.  (Much like proposal 3 in Volz' e-mail.)  Given its
placement in an IANA directory, I presumed that the assignment has
been made, rather than merely proposed.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <[email-masked]>
Virata Corp.	  Applications Infrastructure   http://emweb.com