Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

From: [email-masked]
Date: Thu, 19 May 2005 14:09:56 -0400

[ sorry, resend to add a subject for tracking...  please ignore previous ]

Hello DHC WG and IANA, 

Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP 
options 128-135 in the current vendor-specific range, and to request these 
be placed on the "Tentatively Assigned"  list.

Our usage is as follows.  All are related to configuration of IP Phones 
(and similar devices) in a VoIP network. 

Option    Usage
======    =====
128       TFPT Server IP address (for IP Phone - specific sw load)
129       Call Server IP address
130       Discrimination string (to identify vendor)
131       Remote statistics server IP address
132       802.1P VLAN ID
133       802.1Q L2 Priority
134       Diffserv Code Point
135       HTTP Proxy for phone-specific applications

Please confirm that these will go on the Tentatively Assigned list (or 
perhaps some already are). 

Also, it is not completely clear whether an I-D documenting this same 
information is or is not required.  We are currently looking at getting 
away from this scheme, in favor of better defined / standardized 
vendor-specific methods.  Given this, and the high likelihood of clashes 
over the same options wanted for use by others, we do not currently intend 
to pursue standardization of these options.  Is an I-D required to 
complete the process of putting the options on the Tentatively Assigned 
list? 

While we're on it, is there already, or will there be, a definitive list 
of all the options in Tentatively Assigned state? 

Regards,
Peter Blatherwick
Sr. Solutions Architect,
Mitel Networks
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 19 May 2005 22:59:50 -0400

Thanks Peter.
 
I assume your usage of these option numbers has nothing to do with PXE.
 
Regarding the I-D, yes it would be useful to have that. But as there are
conflicting uses of these option numbers, moving away from their use is
highly recommended. So, it is up to you.
 
The I-D would be to document the existing usage.
 
If you make use of the RFC 3925 vendor options going forward, that would
mean you would not need to standardize the new options via the IETF.
 
Yes, there will be a list. I am waiting until early June to compile that
as I wanted to give people until the end of May to respond. I expect to
send it to IANA and hopefully they'll publish that on the DHCPv4 options
page.
 
This list will primarily indicate the options that are in use, but I
don't expect to give details of the data format, etc. That is what
future I-Ds will hopefully do. 
 
- Bernie

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: Thursday, May 19, 2005 2:10 PM
	To: [email-masked]; [email-masked]
	Subject: [dhcwg] DHCP options 128-135 in use -- please place on
"Tentatively Assigned" list re. RFC 3942

	[ sorry, resend to add a subject for tracking...  please ignore
previous ] 
	
	Hello DHC WG and IANA, 
	
	Regarding RFC 3942, this is to document our (Mitel Networks) use
of DHCP options 128-135 in the current vendor-specific range, and to
request these be placed on the "Tentatively Assigned"  list. 
	
	Our usage is as follows.  All are related to configuration of IP
Phones (and similar devices) in a VoIP network. 
	
	Option    Usage 
	======    ===== 
	128       TFPT Server IP address (for IP Phone - specific sw
load) 

	Please confirm that these will go on the Tentatively Assigned
list (or perhaps some already are). 
	
	Also, it is not completely clear whether an I-D documenting this
same information is or is not required.  We are currently looking at
getting away from this scheme, in favor of better defined / standardized
vendor-specific methods.  Given this, and the high likelihood of clashes
over the same options wanted for use by others, we do not currently
intend to pursue standardization of these options.  Is an I-D required
to complete the process of putting the options on the Tentatively
Assigned list?   
	
	While we're on it, is there already, or will there be, a
definitive list of all the options in Tentatively Assigned state?   
	
	Regards, 
	Peter Blatherwick 
	Sr. Solutions Architect, 
	Mitel Networks

---

From: [email-masked]
Date: Fri, 20 May 2005 10:04:55 -0400

Thanks Bernie, 

Will generate the I-D. 

No, nothing to do with PXE.  We were aware of that one, and believe there 
are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly 
like it -- very clean.  However we do have a strong concern that it may 
take some time before it becomes well deployed, since it is still quite 
new (October 04).   Instead (or possibly supplementally) we are looking at 
using options 60 / 43 to exchange vendor info, or option 60 alone to 
identify the vendor with retuned info in other options in the site range 
(224 and above) scoped based on the vendor in the request. 

Is there a BCP or anything to give good advice on "best" approaches? Since 
there are no doubt about a zillion other vendors in the same position, it 
would be good if we all did at least roughly the same thing ;-)

-- Peter

"Bernie Volz (volz)" <[email-masked]>
19.05.05 22:59

        To:     <[email-masked]>, <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

Thanks Peter.

 

 
This list will primarily indicate the options that are in use, but I don't 
expect to give details of the data format, etc. That is what future I-Ds 
will hopefully do. 
 
- Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 19, 2005 2:10 PM
To: [email-masked]; [email-masked]
Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

Hello DHC WG and IANA, 

Option    Usage 
======    ===== 

Regards, 
Peter Blatherwick 
Sr. Solutions Architect, 
Mitel Networks

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 10:28:36 -0400

Yup, using the site specific option range is really a bad idea (whatever
that range is).
 
You can expect servers to start supporting RFC 3925 ... and the more
people that want to start using this, the more likely the server vendors
will start supporting it. Even if a server doesn't explicitly support
it, most of them allow you to enter an arbitrary option number and data
to return -- while having to construct the option data by hand is very
tricky, at least it provides a means for supporting the option on older
servers. (Perhaps it requires a tool where you configure the vendor
specific data and it spits out some ASCII binary form that is usable to
be cut and pasted into most server's configurations.)
 
One thing that isn't as clear as it could be in RFC 3925 is how a client
communication interested in a certain vendor option set. Part of the
reason for this is that it really is up to each vendor to determine
that. But that does make it more difficult for server vendors to provide
appropriate triggers. Likely most servers will require you to classify
the incoming request in some way and then the options configured for
that class are returned. A common trigger for this might be option 60.
 
- Bernie

	From: Kostur, Andre [mailto:[email-masked]] 
	Sent: Friday, May 20, 2005 10:16 AM
	To: [email-masked]'; Bernie Volz (volz)
	Cc: [email-masked]; [email-masked]
	Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place
on "Tentatively Assigned" list re. RFC 3942

	Re: Options 224+ 

	Hold on... from the RFC: 

	   Some vendors have made use of site-specific option codes that
violate 
	   the intent of the site-specific options, as the options are
used to 
	   configure features of their products and thus are specific to
many 
	   sites.  This usage could potentially cause problems if a site
that 
	   has been using the same site-specific option codes for other
purposes 
	   deploys products from one of the vendors, or if two vendors
pick the 
	   same site-specific options. 

	If you start using options 224+, you're just going to end up in
the same boat that we're in now.  Those options are for site-specific
options.  If your phones are going to be using those options (and, BTW,
we have some of these phones....) then it's no longer a site-specific
option!

	-----Original Message----- 
	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Friday, May 20, 2005 7:05 AM 
	To: Bernie Volz (volz) 

	Thanks Bernie, 

	Will generate the I-D.   

	No, nothing to do with PXE.  We were aware of that one, and
believe there are other conflicting usages as well. 

	We have looked at RFC 3925 (options 124 / 125) of course, and I
certainly like it -- very clean.  However we do have a strong concern
that it may take some time before it becomes well deployed, since it is
still quite new (October 04).   Instead (or possibly supplementally) we
are looking at using options 60 / 43 to exchange vendor info, or option
60 alone to identify the vendor with retuned info in other options in
the site range (224 and above) scoped based on the vendor in the
request.   

	Is there a BCP or anything to give good advice on "best"
approaches?  Since there are no doubt about a zillion other vendors in
the same position, it would be good if we all did at least roughly the
same thing ;-)

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 11:55:56 -0400

Ah, that's sort of what I thought, but it turns out that there isn't
anything in the spec that says that. And, in speaking to Josh, there's
valid reasons not to require this at all! A server might be configured
to send these options always or for a certain "class" of clients
(however that class is determined).
 
- Bernie

	From: Kostur, Andre [mailto:[email-masked]] 
	Sent: Friday, May 20, 2005 11:41 AM
	To: Bernie Volz (volz); Kostur, Andre;
[email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place
on "Tentatively Assigned" list re. RFC 3942

	Isn't that the point of 124/125?  The client sends in 124 with
all of the vendor IDs it's interested in/supports, and a 3925 aware
server would key off of that (instead of 60) to choose what to fill 125
with?

		-----Original Message-----
		From: Bernie Volz (volz) [mailto:[email-masked]]
		Sent: Friday, May 20, 2005 7:29 AM

		One thing that isn't as clear as it could be in RFC 3925
is how a client communication interested in a certain vendor option set.
Part of the reason for this is that it really is up to each vendor to
determine that. But that does make it more difficult for server vendors
to provide appropriate triggers. Likely most servers will require you to
classify the incoming request in some way and then the options
configured for that class are returned. A common trigger for this might
be option 60.

---

From: [email-masked]
Date: Fri, 20 May 2005 12:40:51 -0400

[I assume IANA does not need the noise, so removed from thread.]

Thanks for the feedback. 

Just to be clear, what we had discussed was to only pass back options in 
the site range based on having received option 60 containing the vendor 
info.  Interpretation is, for a given site, here are the options for this 
application.  Agree this is not preferred, just another thing we had 
looked at.  It appear you folks would be stronger than "not preferred". 

Any feedback on using option options 60 / 43?  It is a bit flawed for 
multiple vendors in the same exchange, I know.  But is it well supported 
in the field today is the real question.

Issue with using options 124/125 exchanges remains it is not out there 
very widely now, and deployment always takes time ... so we have a gap. 
Administrative pain to construct the data, likely for several different 
flavors of server, is just that ... a pain.  But a pain we'd rather avoid 
or at least minimize.  Forcing upgrades to the DHCP environment in the 
field is also a pain, and a cost that many will not be happy to suck up if 
there are other means.

   > ... One thing that isn't as clear as it could be in RFC 3925 is how a client 
communication interested in a certain vendor option set.  
Hmmm, perhaps I need to re-read.  My understanding was option 124 is used 
to pass a vendor unique ID (or several), along with any specific data 
(opaque to the DHCP process), and the server returns info in 125 against 
the same vendor ID.  Why would option 60 be used as a trigger at all. 

-- Peter

20.05.05 10:28

        To:     "Kostur, Andre" <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

You can expect servers to start supporting RFC 3925 ... and the more 
people that want to start using this, the more likely the server vendors 
will start supporting it. Even if a server doesn't explicitly support it, 
most of them allow you to enter an arbitrary option number and data to 
return -- while having to construct the option data by hand is very 
tricky, at least it provides a means for supporting the option on older 
servers. (Perhaps it requires a tool where you configure the vendor 
specific data and it spits out some ASCII binary form that is usable to be 
cut and pasted into most server's configurations.)
 
One thing that isn't as clear as it could be in RFC 3925 is how a client 
communication interested in a certain vendor option set. Part of the 
reason for this is that it really is up to each vendor to determine that. 
But that does make it more difficult for server vendors to provide 
appropriate triggers. Likely most servers will require you to classify the 
incoming request in some way and then the options configured for that 
class are returned. A common trigger for this might be option 60.
 
- Bernie

Re: Options 224+ 
Hold on... from the RFC: 
   Some vendors have made use of site-specific option codes that violate 
   the intent of the site-specific options, as the options are used to 
   configure features of their products and thus are specific to many 
   sites.  This usage could potentially cause problems if a site that 
   has been using the same site-specific option codes for other purposes 
   deploys products from one of the vendors, or if two vendors pick the 
   same site-specific options. 

If you start using options 224+, you're just going to end up in the same 
boat that we're in now.  Those options are for site-specific options.  If 
your phones are going to be using those options (and, BTW, we have some of 
these phones....) then it's no longer a site-specific option!
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 20, 2005 7:05 AM 
To: Bernie Volz (volz) 
Thanks Bernie, 
Will generate the I-D.

---

From: [email-masked]
Date: Fri, 20 May 2005 12:43:44 -0400

... but if the returned data is keyed by vendor unique id, no matter how 
triggered, then it is up to the vendor app at the client to sort out how 
to interpret it. No? 
-- Peter

20.05.05 11:55

Ah, that's sort of what I thought, but it turns out that there isn't 
anything in the spec that says that. And, in speaking to Josh, there's 
valid reasons not to require this at all! A server might be configured to 
send these options always or for a certain "class" of clients (however 
that class is determined).
 
- Bernie

To: Bernie Volz (volz); Kostur, Andre; [email-masked]

Isn't that the point of 124/125?  The client sends in 124 with all of the 
vendor IDs it's interested in/supports, and a 3925 aware server would key 
off of that (instead of 60) to choose what to fill 125 with?

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 12:45:25 -0400

Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options.
They are not for vendor use.
 
I'm not saying that option 60 is the trigger for 125, just that it could
be. As could any number of other things - such as the mac address or
client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they aren't general purpose
clients? If that is the case, using Option 60 is certainly possible and
should not cause any issues since you're doing what that option is
intended for - identifying the vendor of the client making the request.
 
- Bernie

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Friday, May 20, 2005 12:41 PM
	To: Bernie Volz (volz)
	Cc: Kostur, Andre; [email-masked]
	Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place
on "Tentatively Assigned" list re. RFC 3942

	Thanks for the feedback.   
	
	Just to be clear, what we had discussed was to only pass back
options in the site range based on having received option 60 containing
the vendor info.  Interpretation is, for a given site, here are the
options for this application.  Agree this is not preferred, just another
thing we had looked at.  It appear you folks would be stronger than "not
preferred".   
	
	Any feedback on using option options 60 / 43?  It is a bit
flawed for multiple vendors in the same exchange, I know.  But is it
well supported in the field today is the real question. 
	
	Issue with using options 124/125 exchanges remains it is not out
there very widely now, and deployment always takes time ... so we have a
gap.  Administrative pain to construct the data, likely for several
different flavors of server, is just that ... a pain.  But a pain we'd
rather avoid or at least minimize.  Forcing upgrades to the DHCP
environment in the field is also a pain, and a cost that many will not
be happy to suck up if there are other means. 
	
	   > ... One thing that isn't as clear as it could be in RFC
3925 is how a client communication interested in a certain vendor option
set.   
	Hmmm, perhaps I need to re-read.  My understanding was option
124 is used to pass a vendor unique ID (or several), along with any
specific data (opaque to the DHCP process), and the server returns info
in 125 against the same vendor ID.  Why would option 60 be used as a
trigger at all.   
	
	-- Peter 

20.05.05 10:28 

        To:        "Kostur, Andre" <[email-masked]>,
<[email-masked]> 
        cc:        <[email-masked]>, <[email-masked]> 
        Subject:        RE: [dhcwg] DHCP options 128-135 in use --
please place on "Tentatively Assigned" list re. RFC 3942

	Yup, using the site specific option range is really a bad idea
(whatever that range is). 
	  
	You can expect servers to start supporting RFC 3925 ... and the
more people that want to start using this, the more likely the server
vendors will start supporting it. Even if a server doesn't explicitly
support it, most of them allow you to enter an arbitrary option number
and data to return -- while having to construct the option data by hand
is very tricky, at least it provides a means for supporting the option
on older servers. (Perhaps it requires a tool where you configure the
vendor specific data and it spits out some ASCII binary form that is
usable to be cut and pasted into most server's configurations.) 
	  
	One thing that isn't as clear as it could be in RFC 3925 is how
a client communication interested in a certain vendor option set. Part
of the reason for this is that it really is up to each vendor to
determine that. But that does make it more difficult for server vendors
to provide appropriate triggers. Likely most servers will require you to
classify the incoming request in some way and then the options
configured for that class are returned. A common trigger for this might
be option 60. 
	  
	- Bernie 

	Re: Options 224+ 

	Hold on... from the RFC: 

	-----Original Message----- 
	From: [email-masked]
[mailto:[email-masked] <mailto:[email-masked]>
] 
	Sent: Friday, May 20, 2005 7:05 AM 
	To: Bernie Volz (volz) 

	Thanks Bernie, 

	Will generate the I-D.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 12:47:55 -0400

Correct.
 
If you're IP phone is doing DHCP, then it would be up to it to
intreprete this data.
 
If you're using Windows or Linux, it isn't necessarily clear how you
would get this data though it is always possible that there is some
place that these clients store "unknown" options and and you could get
access to the data in your application.
 
- Bernie

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Friday, May 20, 2005 12:44 PM
	To: Bernie Volz (volz)
	Cc: Kostur, Andre; [email-masked]; [email-masked]
	Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place
on "Tentatively Assigned" list re. RFC 3942

	... but if the returned data is keyed by vendor unique id, no
matter how triggered, then it is up to the vendor app at the client to
sort out how to interpret it. No?   
	-- Peter 

	

20.05.05 11:55 

	Ah, that's sort of what I thought, but it turns out that there
isn't anything in the spec that says that. And, in speaking to Josh,
there's valid reasons not to require this at all! A server might be
configured to send these options always or for a certain "class" of
clients (however that class is determined). 
	  
	- Bernie

---

From: [email-masked]
Date: Fri, 20 May 2005 13:05:26 -0400

So, if we advertise vendor in option 60, and scope the response based on 
this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT  to return 
vendor-related info in site options range?  We had never proposed to just 
blindly use a different site range without scoping it and being able to 
occupy options as needed by the particular site at hand. 

Sorry to be picky about words, just trying to get it right. 

BTW, From my view at least "IP Phone" is a very slippery term indeed these 
days, and moving slowly in the direction of being general purpose in many 
regards.  And like many VoIP folks, we also configure other applications 
which look very much like IP Phones but are not really. 

-- Peter

20.05.05 12:45

        To:     <[email-masked]>
        cc:     "Kostur, Andre" <[email-masked]>, <[email-masked]>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

Peter:

 
 
- Bernie

Thanks for the feedback.   

-- Peter 

        To:        "Kostur, Andre" <[email-masked]>, 
<[email-masked]> 
        cc:        <[email-masked]>, <[email-masked]> 
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please 
place on "Tentatively Assigned" list re. RFC 3942

  
  
- Bernie 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 20, 2005 7:05 AM 
To: Bernie Volz (volz) 
Thanks Bernie, 
Will generate the I-D.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 13:11:57 -0400

Peter:
 
NEVER USE SITE-SPECIFIC OPTIONS! Period.
 
I'm talking about using option 125.
 
- Bernie

	Sent: Friday, May 20, 2005 1:05 PM

	So, if we advertise vendor in option 60, and scope the response
based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT  to
return vendor-related info in site options range?  We had never proposed
to just blindly use a different site range without scoping it and being
able to occupy options as needed by the particular site at hand.   

	BTW, From my view at least "IP Phone" is a very slippery term
indeed these days, and moving slowly in the direction of being general
purpose in many regards.  And like many VoIP folks, we also configure
other applications which look very much like IP Phones but are not
really. 
	
	-- Peter 

20.05.05 12:45 

        To:        <[email-masked]> 
        cc:        "Kostur, Andre" <[email-masked]>,
<[email-masked]> 
        Subject:        RE: [dhcwg] DHCP options 128-135 in use --
please place on "Tentatively Assigned" list re. RFC 3942

	Peter: 
	  
	Yes, you MUST NOT (per RFC 2119 terminology) use site-specific
options. They are not for vendor use. 
	  
	I'm not saying that option 60 is the trigger for 125, just that
it could be. As could any number of other things - such as the mac
address or client id, option 124 data, ... you name it. 
	  
	I assume your IP phones are just that ... they aren't general
purpose clients? If that is the case, using Option 60 is certainly
possible and should not cause any issues since you're doing what that
option is intended for - identifying the vendor of the client making the
request. 
	  
	- Bernie 

	Thanks for the feedback.   

	
	
	  > ... One thing that isn't as clear as it could be in RFC 3925

	-- Peter 

	

20.05.05 10:28 

	

	 
	 
	- Bernie 

	Re: Options 224+ 

	Hold on... from the RFC: 

	-----Original Message----- 

	Thanks Bernie, 

	Will generate the I-D.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 17:49:16 -0400

Cisco does implement them and has for a long time!

But the other problem with option 60/43 is that there is only ONE
vendor's data that can be exchanged. So, there's no way to communicate
multiple vendor's information if the client is a general purpose system
and not an "appliance" that does only one thing.

That's one reason 124/125 are much more attractive longer term.

Though of course there also need to be APIs to the DHCP Client or other
means to "set" options to be sent and "get" returned options.

- Bernie 

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, May 20, 2005 5:35 PM
> To: [email-masked]
> Cc: Kostur, Andre; [email-masked]; Bernie Volz (volz)
> Subject: Re: [dhcwg] DHCP options 128-135 in use -- please 
> On May 20, 2005, at 1:45 PM, [email-masked] wrote:
> > Any feedback on 60 / 43?  Well deployed?  Well understood in the  
> > real world?
> 
> The biggest tragedy of Option 60/43 is that so few client vendors  
> implement it.   AFAIK all the server vendors implement it - to my  
> knowledge, the Nominum server and the ISC server do, and I would be  
> shocked if any of the other commercial servers don't.
>