Subject: [dhcwg] Clarification regarding Dhcpv6 Vendor-specific option (option 17)

From: ravi kumar <[email-masked]>
Date: Mon, 9 Mar 2009 11:12:39 +0530

RFC 3315 specifies that Vendor-specific option (option 17) is used by *clients
and servers* to exchange vendor-specific information.
Dhcp Server includes this option in Reply message, when client request for
options configured for vendor class. But when do Client include this option
?

In contrast to RFC 3315, RFC 3736 specifies that option-17 is used to pass
information to clients in options defined by vendors.
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?
Please clarify me in this regard.

regards
Ravi

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 9 Mar 2009 10:44:23 -0700

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

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

> information to clients in options defined by vendors.

This is a summarization, "the common use," as RFC 3736 is citing RFC
3315.

> messages sent to Server and in which scenarios do Client include this

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Mar 2009 14:01:42 -0400

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: [email-masked] [mailto:[email-masked]] 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)

---

From: ravi kumar <[email-masked]>
Date: Wed, 11 Mar 2009 17:17:13 +0530

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) <[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Mar 2009 11:01:48 -0400

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

________________________________

From: ravi kumar [mailto:[email-masked]] 
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)

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) <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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.
	
	> messages sent to Server and in which scenarios do Client
include this
	
	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

---

From: Bud Millwood <[email-masked]>
Date: Wed, 11 Mar 2009 16:58:39 +0100

> 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

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

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Mar 2009 09:31:50 -0700

> group considered a VSO ORO a "last resort".

I wouldn't say so.  Servers that do not implement sub-option-request-
options will simply supply all configured options all the time.  This
is a superset of what clients will expect.

It's a safe optimization.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Mar 2009 09:52:14 -0700

> Vendor-specific option  be used for this purpose?

I may not understand the question.

The only thing that causes a VSIO to be included in reply is if the
VSIO option code is on the ORO.

However, a server might select which /specific/ VSIO options (which
enterprise-ID or specific sub-option contents) to send based upon
contents of any VCIO options, or as Bernie stated, a VSIO sub-ORO,
depending upon the vendor's specification.

So for example if a client sends VCIO enterprise ID's A and B, and
the server is configured with values for enterprise ID's B, and C,
then in this case if the client placed VSIO on its ORO, the server
may only reply with VSIO for enterprise ID B only (having no config
for C).  A different (simpler) server may instead reply with
enterprise ID's B and C, if the server has no mechanism to distinguish
specific ID's, even though the client can make no use of VSIO for ID
C.

Note that in some cases (in DHCPv4), vendor-class would be specified
to be in the reply made by the server, so that the server's reply can
be versioned (and the client can behave differently for newer or older
servers).  This should probably be deprecated, and a better technique
if required would be to put a version option in the VSIO contents.

> Client just request option X, by including only option x in VSIO option?

No.  As Bernie says, some VSIO options do provide a sub-ORO, but the
presence of VSIO options will not guarantee a similarly-identified
VSIO is included in the reply.

> What would typical Server implementations be, in this case.

ISC's implementation is very simple right now - we reply with all VSIO
that are configured within the client's scope, IFF the client placed
VSIO on the ORO.

> fashion of how ORO is used for requesting specific standard options

Only the ORO determines what options the client may reasonably expect
in reply (with some "core DHCPv6 protocol layer" exceptions).

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Mar 2009 13:52:46 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Bud Millwood
Sent: Wednesday, March 11, 2009 11:59 AM
To: [email-masked]
Subject: Re: [dhcwg] Clarification regarding Dhcpv6
Vendor-specificoption(option 17)

> 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

---

From: ravi kumar <[email-masked]>
Date: Thu, 12 Mar 2009 10:04:19 +0530

Thanks a lot for your valuable information.

Ravi