Subject: RE: [dhcwg] Assigning DHCPv6 option codes

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 23 Jan 2002 01:34:39 -0600

One other issue related to the DHCPv6 option space ...

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.

Should we say that options numbers 32768 to 65535 are reserved for "private" (site-specific?) options. This is a fairly large space, but then again if we have 32767 defined options we'd likely need very large packets to communicate them all. 

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 9:50 PM
To: [email-masked]
Subject: [dhcwg] Assigning DHCPv6 option codes

There is a potential collision problem between DHCPv4 and DHCPv6 option 
codes.  The DHCID RR uses the option code to identify the source of the 
information stored in the RR.  If DHCPv4 and DHCPv6 use overlapping option 
codes that identify different options, the source of the information in the 
RR will be ambiguous.  One proposed solution is to start numbering DHCPv6 
options at 256, to avoid collisions with DHCPv4 option codes.  Another 
solution is to assign new codes for the identification field in the DHCID 
RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other 
sources of information not encoded in a DHCP option.  For example, DHCID RR 
code 1 might identify the contents of the RR as a DHCPv4 client identifier, 
while DHCID RR code 2 might indicate a DHCPv6 DUID.  Comments on the two 
solutions?

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Sat, 26 Jan 2002 08:04:11 -0500

> 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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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