Subject: [dhcwg] Vendor-specific options

From: Bud Millwood <[email-masked]>
Date: Thu, 23 Aug 2007 23:59:32 +0200

In DHCPv4, the vendor options contained in option 43 were interpreted 
according to the free-form text of option 60. Vendors were free to put 
anything in option 60, and many of them chose different data for different 
models of their equipment.

In DHCPv6 the vendor options are interpreted according to the vendor_id field, 
but vendors are *not* free to put anything in there that they want - just 
their assigned id.

How are vendors expected to define different sets of options for different 
equipment? It seems to me that the possibilities are:

1. Vendors don't have different options, they use the 16-bit tag space to 
define all options for all devices. Seems like a bad idea for a couple of 
reasons, one being you can't easily narrow down and present to the user a set 
of options for a particular piece of equipment.

2. Vendors start defining their own free-form text fields inside the VSO, and 
we end up looking awfully similar to DHCPv4.

3. Vendors use 'vendor-sub-identifiers', hopefully modelled after the VSO.

It seems the VSO in DHCPv6 tried to solve the problem of allowing free-form 
vendor class, but just deferred the problem to parsing within the VSO - at 
least in the case where a vendor had multiple option 60 values for different 
sets of vendor-specific options (in DHCPv4).

Are we going to see all sorts of crazy schemes in the DHCPv6 VSO to denote 
different option spaces?

Are any vendors currently partitioning their VSO suboptions?

Could/should we recommend that vendors use the VSO format inside the VSO if 
they want partitioned option spaces?

- Bud

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

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 23 Aug 2007 19:06:38 -0400

Hello Bud,

I am not sure if I am following all of the points below.  I will try to offer some comments, however.

Vendor class in particular in DHCPv6 includes an enterprise-id that is used to differentiate the values within.  Other options can be defined  in the vendor option space (17) which also includes an enterprise-id.  An example of where this has been used is in DOCSIS 3.0.

Is this what you were inquiring about?

HTH,

John
========================================= 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=========================================

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]]
Sent: Thu 8/23/2007 5:59 PM
To: [email-masked]
Subject: [dhcwg] Vendor-specific options

- Bud

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Aug 2007 16:18:01 -0700

> of options for a particular piece of equipment.

This is my understanding.

I think that DOCSIS, concerned I think about having a large number of
options in one 16-bit space, has elected to use a sub-parameter-
request-list option.  I might be thinking of something else, but I
think DOCSIS 3 specified one.

Where software supports it - the operator configures all the values
for all the different options, and they get delivered automatically
to the clients that want them.

	option vendor.foo ...;
	option vendor.bar ...;
	option vendor.baz ...;

Where software doesn't support it - the operator configures "classes"
that match individual vendor class options, and configure values
relevant to those classes of clients in one place.  The output packet
contains only that which is relevant to the class of client in
question.

	class "thingits" {
		match if vivco.example = "thingit";
		option vendor.foo ...;
	}
	class "whatsis" {
		match if vivco.example = "whatsis";
		option vendor.bar ...;
	}
	class "dongles" {
		match if vivco.example = "dongles";
		option vendor.baz ...;
	}

(where vivco is 'vendor identified vendor class option'...I can't
remember which is which anymore...is it "vcio" for DHCPv6?)

The worst case is that the clients get big packets.

I don't think there's a danger that vendors are going to have multiple
option spaces with one enterprise-ID...but if someone says they might,
we should listen.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 23 Aug 2007 19:33:57 -0400

Hello David,

You are correct we specified an ORO as part of DOCSIS 3.0.

It would be interesting to hear more about multi-enterprise-id scenarios.  While it seems valid (I think) I imagine it could tricky to organize.

John

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]]
Sent: Thu 8/23/2007 7:18 PM
To: [email-masked]
Subject: Re: [dhcwg] Vendor-specific options

 option vendor.foo ...;
 option vendor.bar ...;
 option vendor.baz ...;

 class "thingits" {

---

From: Bud Millwood <[email-masked]>
Date: Fri, 24 Aug 2007 01:44:52 +0200

On Friday 24 August 2007 01:18, David W. Hankins wrote:
> > reasons, one being you can't easily narrow down and present to the user a
> > set of options for a particular piece of equipment.
>

Nope, you're right, I just checked it. There's an ORO in the VSO options for 
DOCSIS 3.0.

> to the clients that want them.

OK, I guess it's not so bad to define all options in the one 16-bit tagspace. 
From the standpoint of being able to parse inbound VSO options, it's a 
no-brainer. (Easier than vendor sub-identifiers)

I think maybe what I expect is just to be able to group sets of vendor 
suboptions by some class name so the operator can easily locate suboptions 
specific to the device he wants to consider. Should be easy enough to just 
allow a class name in my option definitions.

BTW, if the vendor hasn't defined a vendor-specific ORO, I guess you'd have to 
support the method described below.

> remember which is which anymore...is it "vcio" for DHCPv6?)

IOW in this scenario you would check option 16/vendor class data and match the 
classes against the pre-defined classes of options.

> option spaces with one enterprise-ID...but if someone says they might,

Well then until I see one I'll leave it where it is. I'd be happy to never see 
vendor sub-identifiers.

- Bud