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

[[e-mail]]

Hi Andre, 

Point taken, and also as per Bernie's STRONG WORDS ;-)

I'm trying not to focus on a particular vendor here (though obviously I do 
have interests in a particular one).   As with many others, we do not want 
to be dependent even on our own DHCP server implementation.   We are 
looking for a general-purpose solution ... because our customers are. 

Any feedback on 60 / 43?  Well deployed?  Well understood in the real 
world? 

-- Peter






"Kostur, Andre" <[e-mail]>
20.05.05 13:13

 
        To:     "'[e-mail]'" <[e-mail]>, "Bernie 
Volz (volz)" <[e-mail]>
        cc:     "Kostur, Andre" <[e-mail]>, [e-mail]
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tenta tively 
Assigned" list re. RFC 3942


IMHO:
 
As a _vendor_, you MUST NOT mandate that any site-specific options be sent 
back to your device.  Theoretically speaking, as a site administrator I 
may wish to send option 230 back to every device that requests, because I 
may have some custom DHCP tracking monitoring software that's looking for 
someting in 230.  Since this is a site-specific thing (it's completely 
localized to my site, and makes no sense in anybody else's site), I can 
use 230 without worrying about it conflicting with anything else.  Now if 
I deploy a Mtel IP phone into this site (assuming Mitel has moved say the 
VLAN ID option to 130), I can no longer do that since a vendor has 
mandated a site-specific option to be sent back to a general-use device.
 
Besides... in most of your deployments, aren't the phones doing DHCP 
against an ICP200 or MAS6000 box anyway (_both_ of which are until Mitel's 
control), so upgrading whatever DHCP service on those to be 3925 compliant 
shouldn't be too hard for Mitel... it's only sites like ours which are 
using a different DHCP service (ours) where 3925 compliance would be 
dependant on that DHCP service being compliant...
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, May 20, 2005 10:05 AM
To: Bernie Volz (volz)
Cc: Kostur, Andre; [e-mail]
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942


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 





"Bernie Volz (volz)" <[e-mail]> 
20.05.05 12:45 
        
        To:        <[e-mail]> 
        cc:        "Kostur, Andre" <[e-mail]>, 
<[e-mail]> 
        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 

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


[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 




"Bernie Volz (volz)" <[e-mail]> 
20.05.05 10:28 
        
       To:        "Kostur, Andre" <[e-mail]>, 
<[e-mail]> 
       cc:        <[e-mail]>, <[e-mail]> 
       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 

From: Kostur, Andre [mailto:[e-mail]] 
Sent: Friday, May 20, 2005 10:16 AM
To: '[e-mail]'; Bernie Volz (volz)
Cc: [e-mail]; [e-mail]
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: [e-mail] [mailto:[e-mail]] 
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 ;-) 

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