Re: [dhcwg] Assigning DHCPv6 option codes

[Thomas Narten <[e-mail]>]

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg