Re: [dhcwg] Assigning DHCPv6 option codes

Thomas Narten <narten@us.ibm.com> Sat, 26 January 2002 13:18 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06401 for <dhcwg-archive@odin.ietf.org>; Sat, 26 Jan 2002 08:18:06 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20723 for dhcwg-archive@odin.ietf.org; Sat, 26 Jan 2002 08:18:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20563; Sat, 26 Jan 2002 08:05:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20540 for <dhcwg@optimus.ietf.org>; Sat, 26 Jan 2002 08:05:51 -0500 (EST)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06252 for <dhcwg@ietf.org>; Sat, 26 Jan 2002 08:05:47 -0500 (EST)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g0QD4Bt07404; Sat, 26 Jan 2002 08:04:11 -0500
Message-Id: <200201261304.g0QD4Bt07404@cichlid.adsl.duke.edu>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
cc: "'Ralph Droms'" <rdroms@cisco.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] Assigning DHCPv6 option codes
In-Reply-To: Message from "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> of "Wed, 23 Jan 2002 01:34:39 CST." <66F66129A77AD411B76200508B65AC69B4CDEF@EAMBUNT705>
Date: Sat, 26 Jan 2002 08:04:11 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> To my recollection and quick browsing of the -22 draft, I do not
> recall us ever carving out a portion of the option space for
> "private" (site-specific?) options.

According to RFC 2434 terminology, I think what you are asking about
is Private Use options:

      Private Use - For private or local use only, with the type and
           purpose defined by the local site. No attempt is made to
           prevent multiple sites from using the same value in different
           (and incompatible) ways. There is no need for IANA to review
           such assignments and assignments are not generally useful for
           interoperability.

           Examples: Site-specific options in DHCP [DHCP] have
           significance only within a single site.  "X-foo:" header
           lines in email messages.

Ted Lemon <mellon@nominum.com> writes:

> I am unaware of a single example where site-specific options have ever been 
> used.

I assume you mean as defined above. If this is the case, DHCPv6
would't seem to need them!

Vernon Schryver <vjs@calcite.rhyolite.com> writes:

> Microsoft is using more than one "site-specific" IPv4 DHCP options.
> Their web pages talk about 252 and you can see 251 if you snoop
> on Window ME packets.

This is not what I would call "Private Use". If a vendor ships a
product with values hard-wired in, there is the risk  of name-space
collisions. In such cases, it would seem better to assign option
values from the global pool.

Ted Lemon <mellon@nominum.com> writes:

> We shouldn't allow people to request option codes from the IANA if they 
> haven't published a draft, but I think it's safe to relax the restrictions 
> to the extent that if a draft exists, an option code can be assigned 
> without the draft going to last call.   This utterly draconian 
> requirementis only justified by the extremely small number of option codes 
> available in DHCPv4.

There are a number of reasons why you might not want to assign an
option code until the spec is done, but they may not apply in all
cases.

Giving out numbers to anyone almost guarantees that some will be
assigned and never used. In some cases (i.e., DHCv4) this is a
problem. In others (DHCPv6?) probably not.

Giving out numbers too early runs the risk of having vendors
implement/ship from an early draft, and then the WG may have to deal
with the problem of not being able to redefine the option the way it
wants because of deployed systems. That has happened in this WG. 

Giving out numbers without any review runs the risk that someone will
reinvent an existing option, possibly badly. Hasn't that happened with
DHCPv4 before?

One might argue that withholding the assignment of a code point would
be incentive for a WG to finish the critical IDs and turn them into
RFCs, so that getting the option code assigned would still happen
relatively quickly. But, I no longer argue that, based on what I've
seen in some WGs. :-(

How serious the above problems are depends on the protocol, the
scarcity of option codes, the history of the community :-), etc.

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg