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

On Wed, Mar 11, 2009 at 11:22 PM, Bernie Volz (volz) <volz at cisco.com> wrote:

I think David explained this well in his follow on messages.

In general, most servers will probably be "dumb" and respond with all of
the Vendor options configured (if the ORO includes option 17).

Specialized servers may do more complex processing, such as dissecting a
received Vendor Option when it contains a vendor ORO to supply only the
specific items requested.

Our server, by default is dumb (it returns all configured vendor
options). But it can be extended for specific applications to do more
complex processing (but this requires extra 'code').

- Bernie

-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf

Of Bud Millwood
Sent: Wednesday, March 11, 2009 11:59 AM
To: dhcwg at ietf.org
Subject: 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
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg