RE: [dhcwg] Assigning DHCPv6 option codes
Richard Barr Hibbs <rbhibbs@pacbell.net> Thu, 24 January 2002 05:33 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 AAA06993 for <dhcwg-archive@odin.ietf.org>; Thu, 24 Jan 2002 00:33:39 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA03197 for dhcwg-archive@odin.ietf.org; Thu, 24 Jan 2002 00:33:40 -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 AAA02669; Thu, 24 Jan 2002 00:24:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02638 for <dhcwg@optimus.ietf.org>; Thu, 24 Jan 2002 00:24:16 -0500 (EST)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06753 for <dhcwg@ietf.org>; Thu, 24 Jan 2002 00:24:14 -0500 (EST)
Received: from BarrH63p601 ([64.170.119.193]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQF00IM6GCFUL@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Wed, 23 Jan 2002 21:24:15 -0800 (PST)
Date: Wed, 23 Jan 2002 21:23:18 -0800
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
Subject: RE: [dhcwg] Assigning DHCPv6 option codes
In-reply-to: <200201232355.g0NNtWFh026414@calcite.rhyolite.com>
To: dhcwg@ietf.org
Reply-to: rbhibbs@pacbell.net
Message-id: <JCELKJCFMDGAKJCIGGPNMEJKDJAA.rbhibbs@pacbell.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
> -----Original Message----- > From: Vernon Schryver > Sent: Wednesday, January 23, 2002 15:56 > > 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? 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Assigning DHCPv6 option codes Ralph Droms
- RE: [dhcwg] Assigning DHCPv6 option codes Bernie Volz (EUD)
- RE: [dhcwg] Assigning DHCPv6 option codes Bernie Volz (EUD)
- Re: [dhcwg] Assigning DHCPv6 option codes Ted Lemon
- RE: [dhcwg] Assigning DHCPv6 option codes Ralph Droms
- Re: [dhcwg] Assigning DHCPv6 option codes Ted Lemon
- Re: [dhcwg] Assigning DHCPv6 option codes Vernon Schryver
- RE: [dhcwg] Assigning DHCPv6 option codes Bernie Volz (EUD)
- Re: [dhcwg] Assigning DHCPv6 option codes Ted Lemon
- Re: [dhcwg] Assigning DHCPv6 option codes Ted Lemon
- RE: [dhcwg] Assigning DHCPv6 option codes Richard Barr Hibbs
- RE: [dhcwg] Assigning DHCPv6 option codes Richard Barr Hibbs
- RE: [dhcwg] Assigning DHCPv6 option codes Vernon Schryver
- RE: [dhcwg] Assigning DHCPv6 option codes Richard Barr Hibbs
- RE: [dhcwg] Assigning DHCPv6 option codes Vernon Schryver
- RE: [dhcwg] Assigning DHCPv6 option codes Ralph Droms