A counter-proposal for option 127

Shawn Mamros <mamros@ftp.com> Thu, 15 February 1996 18:59 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26356; 15 Feb 96 13:59 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26352; 15 Feb 96 13:59 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa21450; 15 Feb 96 13:59 EST
Received: from localhost by reef.bucknell.edu with SMTP (5.65/IDA-1.2.8) id AA08014; Thu, 15 Feb 1996 13:52:10 -0500
Date: Thu, 15 Feb 1996 13:52:10 -0500
Message-Id: <9602151618.AA06447@mailserv-C.ftp.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Shawn Mamros <mamros@ftp.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: A counter-proposal for option 127
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

I've just downloaded the latest batch of Internet drafts.  I may have
comments on some of the others, but thought I'd address the one which
immediately jumped out at me first... namely, the definition for the
new option 127 to extend the option code space.

I have a problem with the way it's defined, because it violates the
single-byte option code followed by single-byte length field that
we've been following to date, when I can think of at least one way
(more on this way in a second) to extend the option code length *and*
maintain at least some backwards compatibility for existing clients and
servers so they can at least skip over newer options that they don't
understand.  Moreover, unless I'm interpreting it wrong, the proposed
format only provides for a maximum of 256 additional options, in spite
of being worded as a "two-byte option code", because the first byte always
has to be 127 (am I right?).

If our esteemed WG chair is willing to entertain a counter-proposal,
here it is...

    Code   Len     Option      Data...
   +-----+-----+-----+-----+-----+-----+----
   | 127 |  n  |  oh |  ol |  d1 |  d2 | ...
   +-----+-----+-----+-----+-----+-----+----

where "oh" is the high-order byte of the two-byte extended option code,
and "ol" is the low-order byte.  The length "n" must include the two bytes
of the extended option code itself.

One nice feature of this scheme is that it provides 65,536 potential options,
which (hopefully!) ought to be enough for any forseeable future.  If the
general consensus is that we'll only need another 256 options, though,
making it a single byte instead is fine by me.

The only drawback I can see is that you lose two bytes of potential option
data within the max. 255 bytes length.  (Though if everyone were to follow
the "letter of the law" in allowing for concatenation of multiple instances
of a single option (see section 4.1 of draft-ietf-dhc-dhcp-06.txt), this
won't be a problem, assuming we actually do see options that wind up
being greater than 253 bytes long...)

Just a thought...

-Shawn Mamros
E-mail to: mamros@ftp.com