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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 1 Apr 2001 20:47:59 -0500

Barr:

While I like these in theory, I'm not sure how practical they will be. Recalling existing options, no matter how little implemented, won't be easy because older implementations will always exist. And, if a client used the old form of the option but the server gave out the new one (or vice versa), you could easily have problems.

- Bernie

-----Original Message-----
From: Richard Barr Hibbs [mailto:[email-masked]]
Sent: Friday, March 30, 2001 2:59 PM
To: DHCPv4 discussion list
Subject: RE: DHCP Option Tag Exhaustion (1..127)

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

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

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