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

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



>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.pdf, 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.
 
- 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). 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