[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] Clarification regarding Dhcpv6 Vendor-specificoption (option 17)



On Wednesday 11 March 2009, Bernie Volz (volz) wrote:
> >For instance: options x and y are vendor options defined on Server. Can
>
> Client just request option X, by including only option x in VSIO option?
>
>
> This is only possible if the vendor option defines an ORO like scheme
> and the server understands it. Note that CableLabs does this, see
> http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I02-080306.p
> df, Table 5, CL_OPTION_ORO.
>
> A client can (should) include option 17 in its ORO if it wants vendor
> options. But, which vendor options can not be controlled by the ORO
> mechanism because that option only allows a list of option number (like
> option 17), not enterprise-ids nor vendor specific suboptions.

Is the Cablelabs ORO considered a special case? Is the consensus that most 
servers won't recognize new vendor-specific OROs without a patch?

Our VSO ORO processing is generic, but it would be nice to know if we as a 
group considered a VSO ORO a "last resort".

- Bud

> - Bernie
>
> ________________________________
>
> From: ravi kumar [mailto:ravikumar.lrk at gmail.com]
> Sent: Wednesday, March 11, 2009 7:47 AM
> To: Bernie Volz (volz)
> Cc: David W. Hankins; DHC WG
> Subject: Re: [dhcwg] Clarification regarding Dhcpv6
> Vendor-specificoption (option 17)
>
>
>
> Thanks a lot for your replies.  I have one more question!
>
> Incase if client requires only specific Vendor Option from Server, Can
> Vendor-specific option  be used for this purpose?
>
> For instance: options x and y are vendor options defined on Server. Can
> Client just request option X, by including only option x in VSIO option?
>
> What would typical Server implementations be, in this case.
> I just want to confirm, if  VSIO can be used for Vendor options, in
> similar fashion of how ORO is used for requesting specific standard
> options configured on Server.
> regards
> Ravi
>
> On Mon, Mar 9, 2009 at 11:31 PM, Bernie Volz (volz) <volz at cisco.com>
> wrote:
>
>
> 	See the DOCSIS 3.0 documents (www.cablelabs.com
> <http://www.cablelabs.com/> ). Cable modems (clients)
> 	include vendor information options. As does the relay agent. As
> do the
> 	servers in response.
>
> 	- Bernie
>
>
> 	-----Original Message-----
> 	From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On
> Behalf
> 	Of David W. Hankins
> 	Sent: Monday, March 09, 2009 1:44 PM
> 	To: DHC WG
> 	Subject: Re: [dhcwg] Clarification regarding Dhcpv6
> 	Vendor-specificoption (option 17)
>
> 	On Mon, Mar 09, 2009 at 11:12:39AM +0530, ravi kumar wrote:
> 	> RFC 3315 specifies that Vendor-specific option (option 17) is
>
> used by
> 	*clients
>
> 	> and servers* to exchange vendor-specific information.
>
> 	This is correct, and RFC 3315 should be considered the only
> reference
> 	on the subject.  Note the statement is not normative, and the
> table in
> 	Appendix A (also not normative?) clearly indicates Relay-Forw
> and
> 	Relay-Reply permit the VCIO and VSIO options.
>
> 	> Dhcp Server includes this option in Reply message, when client
>
> request
> 	for
>
> 	> options configured for vendor class. But when do Client
>
> include this
> 	option
>
> 	> ?
>
> 	Whenever they want to.  Some vendor options may require
> negotiation,
> 	in which case the client needs to advertise its desired value
> (or
> 	range).
>
> 	Generally clients don't need to do this, as vendor options are
> usually
> 	specific assignments and the "default values" are known in
> advance (if
> 	this option isn't present, the client defaults to X) because it
> is the
> 	vendor's client, after all.
>
> 	So usually the client just sends VCIO options, and the server
> replies
> 	with relevant VSIO options, containing only those parameters
> that need
> 	defaults over-ridden.
>
> 	> In contrast to RFC 3315, RFC 3736 specifies that option-17 is
>
> used to
> 	pass
>
> 	> information to clients in options defined by vendors.
>
> 	This is a summarization, "the common use," as RFC 3736 is citing
> RFC
> 	3315.
>
> 	> I would like to know, if Client can include Vendor-specific
>
> option in
>
> 	> messages sent to Server and in which scenarios do Client
>
> include this
>
> 	> option?
>
> 	If a client needs to deliver any information the server can not
> assume
> 	in advance, then probably the client would also send VSIO
> options.
>
> 	--
> 	David W. Hankins        "If you don't do it right the first
> time,
> 	Software Engineer                    you'll just have to do it
> again."
> 	Internet Systems Consortium, Inc.               -- Jack T.
> Hankins
>
> 	_______________________________________________
> 	dhcwg mailing list
> 	dhcwg at ietf.org
> 	https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687