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

From: "Joe Aiello" <[email-masked]>
Date: Fri, 30 Mar 2001 08:39:31 -0800

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  in the having a new option assigned.  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: [email-masked]
Date: Fri, 30 Mar 2001 09:53:20 -0800

Using option 3 still leaves the problem of proprietary options, such as that
described with Microsoft.

A while ago, I proposed an OUI or enterprise-id based extension, kind of
like SNAP.  This format solves both problems: new address space for option
tags, and guaranteed unique tags for proprietary stuff.

It could work like this:

   +-----+-----+-----+-----+-----+-----+-----+
   | tag | len | enterp-id | data...         |
   +-----+-----+-----+-----+-----+-----+-----+

IANA could use an enterprise-id of zero.  IANA assigned "data" fields would
be coded as are the existing options: tag,len,value.  Smart enterprises
would do the same.
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks

 

-----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: