Subject: RE: [dhcwg] Assigning DHCPv6 option codes

From: Vernon Schryver <[email-masked]>
Date: Wed, 23 Jan 2002 16:55:32 -0700 (MST)

> From: Richard Barr Hibbs <[email-masked]>

> > I am unaware of a single example where site-specific options have
> > ever been used.
> >
> ... many "thin clients" such as Wyse used those option numbers for their
> configuration.  Of course, that is really "vendor-specific" and not
> "site-specific" but it still is the same number range (128-254).
> ...

I thought RFC 2132 clearly separated the site-specific range
[128,254] from the vendor-specific range defined in section 8.4.
Where is the overlap?

Vernon Schryver    [email-masked]

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

---

From: Richard Barr Hibbs <[email-masked]>
Date: Wed, 23 Jan 2002 21:23:18 -0800

> -----Original Message-----
> From: Vernon Schryver
> Sent: Wednesday, January 23, 2002 15:56
>
...hmmmm...  the imprecision of words.....

yes, vendor-specific <<information>> is encoded as specified in section 8.4
into the value field of a single DHCP <<option>> (number 43), but that's not
quite the same thing as I was pointing out in my reply:  Wyse, Citrix, and
other vendors of "thin" clients, several vendors of VoIP telephones, and a
few other vendors such as cisco and Intel use <<option>> numbers 128-254 to
request and/or supply data for their products.

While option 43 is defined for passing data whose code point values are not
required to be specified by an RFC, it does permit the use of
"vendor-specific" code points 1-254, which are permitted to redefine or
duplicate any "standard" DHCP option, or to define completely new ones.
Options 128-254 of the site-specific option set may also do this, so what is
the difference?

The total length of the encapsulated data in option 43 is limited to 255
octets:  the total length of data in the site-specific options is 127 * 255
= 32,385 octets.  On the other hand, option 43 allows 254 different,
presumably unique, code points while the site-specific options permit only
127.  The downside to using the site-specific options for conveying data is
that server support is far from uniform because of the lack of specification
for dealing with overlapping or conflicting vendor implementations.  Of
course, a similar problem exists with option 43:  it is not possible to
examine an arbitrary set of vendor-encapsulated options and know the
identity of the vendor, since there is no standard way to specify this.
That's why in several server implementations the vendor class identifier
(option 60) is presumed (though not required by RFC 2132) to be used in
conjunction with option 43.

To stave off an argument, RFC 2132 does not require (by using MUST phrases)
that option 43 only be used with option 60 -- the RFC uses weaker SHOULD
phrases -- and does not specify server behavior if either option appears
alone.

--Barr

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 23 Jan 2002 23:01:53 -0700 (MST)

> Options 128-254 of the site-specific option set may also do this, so what is

What's the difference?!?
The site-specific options 128-254 are in a different space than the
vendor-specific options 1-254.  When a vendor abuses the site specific
option 251, it is inviting catastrophy when either some other vendor
equally provincial and incompetent vendor abuses the same site specific
option 251, or the poor sucker running a site uses option 251.

> conjunction with option 43.

I understand no good sense in that.

Anyone with a legitimate need to decode vendor-specific option need
only ask the vendor, and be told or not depending on whether the vendor
decides the need is legitimate.  To determine the identity of the
vendor, what's wrong with consulting the usual sources?  If those
give no joy, then you have no legitimate need to do any decoding,
even if that means that the product must be shipped back to the vendor.

Second, the downside to using site-specific options is more than mere
lack of uniformity of specification.  You may as well toss out the
whole standardization process send any random bits you want.  Why not
use option 53 for something different and interesting? 

> phrases -- and does not specify server behavior if either option appears

Programmers provincial enough to not conceive of the possibility that
there might be equally provincial programmers elsewhere and so not
use option 60 to prevent collisions deserve all of the grief they'll
get and more.  I'm not sure whether their customers deserve the grief
they'll get, but perhaps they're guilty for buying junk.

SHEESH!
I really hope someone will tell me I've completely misunderstood
and that I'm not really being told that the DHCP-WG consensus is
that you just pick random option numbers to use howerver you want
and just hope no one elsewhere picks the same numbers.