Re: [dhcwg] DHCPv6 message type

On Mon, Apr 28, 2008 at 07:28:11PM -0400, Bernie Volz (volz) wrote:
> If we were really concerned about option numbers being hijacked, we
> should request that IANA randomly pick option numbers from the full
> range - as then you'd never know what the next value from IANA would be.
> (The issue exists for the messages - someone could use message 255 as it
> is unlikely IANA would assign that message number for a long time.)

Well, I'm concerned about people hijacking options, but I still don't
think I'd direct IANA to allocate options randomly.  First, more work
for them, second, I can see an implementation case where DHCP software
allocates a fixed array (compiled in probably) for option code
definitions.  Allocating options randomly deselects the ability to
index this array directly by option code (as was done in e.g. ISC DHCP
3.0.x).

We used to do something like this, we might have done something much
more like this (but I decided to go a different route), but we don't
do either method anymore, largely in order to support the Vendor-
Identified spaces as 32-bit option code spaces (where the enterprise-
id is just an option code).

I don't know if such deselection is universal, but I think at least
minimalistic software is likely to benefit from having the "used"
option codes in as compact a binary space as possible, if for no
other reason than to make it possible to index an array of 'dhcp
options' directly by option code.

> I asked at the DHC WG meeting when I presented the draft if it would
> help if I removed the reserved options section, but people still didn't
> like the draft even if it had just the vendor-specific message. I don't
> think we *need* the reserved options, it just made life a bit easier.

We could check the minutes, but my memory of the WG meeting is that,
after some discussion of many of these talking points, we left the
discussion after an objection was raised that if one were to put this
mechanism in an RFC, then hypothetical people might believe it to be a
good idea, implying this to be an undesirable end result.

I thought this was rather remarkable at the time as, although I am not
terribly experienced in IETF matters, I can think of several RFCs that
were not, are not, and probably never will be good ideas, and many
drafts (such as draft-ietf-wrec-wpad) that would have served the
network much better as an RFC standard despite its marked lack of
visitation by the good idea fairy.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins