RE: [dhcwg] Assigning DHCPv6 option codes

[Vernon Schryver <[e-mail]>]

> From: Richard Barr Hibbs <[e-mail]>

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

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.


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

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? 


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

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.


Vernon Schryver    [e-mail]

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