DHCPv6 host-identifier, the Never Ending Thread: A Summary

[John Jason Brzozowski]

I would not be surprised to see some re-use of vendor specific options  
for DHCPv6.  While this is seemingly convenient in the near term it is  
clearly not advisable for obvious reasons.  Defining options that meet  
specific needs and requirements seems like the best approach.

John
===============================================
John Jason Brzozowski
jjmb at jjmb.com
(p) 484-994-6787
(f) 610-616-4535
===============================================

On Mar 8, 2009, at 3:20 PM, Marcus Goller wrote:

> John,
>
> I agree in general, from a design point of view. I would not be  
> surprised if some deployments start (ab)using already existing  
> vendor specific options for their purpose, because it might be  
> easier and gets the job done, especially if the server already  
> support it. But as explained in my other email, I might have  
> misunderstood where and when vendor specific options are preferred.
>
> Thanks for clarifying that again.
>
> Marcus
>
> John Jason Brzozowski wrote:
>> Marcus,
>>
>> I think vendor options need to be specified per vendor or  
>> deployment type.  Not sure if you are suggesting if someone in en  
>> enterprise environment should leverage the Cablelabs DOCSIS TFTP  
>> options or not, I would actually recommend otherwise.  If specific  
>> options are required and are not currently defined in the  
>> appropriate space then either a core option or vendor specific  
>> option should be specified.
>>
>> The DOCSIS options are good examples for people to consider and  
>> leverage as examples of how they want to handle DHCPv6 requirements  
>> for their own deployments, whether this means specifying vendor  
>> specific options or core DHCPv6 options with IETF dhc WG.
>>
>> John
>> ===============================================
>> John Jason Brzozowski
>> jjmb at jjmb.com
>> (p) 484-994-6787
>> (f) 610-616-4535
>> ===============================================
>>
>> On Mar 7, 2009, at 6:58 PM, Marcus Goller wrote:
>>
>>> John Jason Brzozowski wrote:
>>>> Frank, et al,
>>>>
>>>> I planned on participating in the 160+ email thread but got tied  
>>>> up.
>>>>
>>>> For what it is worth as someone leading a large IPv6 effort  
>>>> where, as you stated below, MAC addresses are leveraged  
>>>> extensively I can tell you how I handled this issue.
>>>>
>>>> When we specified the use of DHCPv6 in DOCSIS 3.0 we of course  
>>>> leveraged vendor information options.  In these options as you  
>>>> will see if you read the DOCSIS specifications we made provisions  
>>>> to carry the MAC address of the device that adheres to this  
>>>> specification.  This is one part of the equation.  I also had to  
>>>> make sure that the necessary back office systems, DHCP for  
>>>> example, account for the presence of these options to support the  
>>>> deployment.
>>>>
>>>> If you wish I would be willing to discuss further offline.
>>>>
>>>> Regards,
>>>>
>>>> John
>>> John,
>>>
>>> Interesting point actually, now that you bring it up. When I first  
>>> looked at the DHCPv6 RFC, I thought "Hey! Where did all my options  
>>> go?". If I understand it right, DHCPv6 tries to cover to core  
>>> functionalities only, the rest is left to the vendor information  
>>> options. The CableLabs specifications are a good example, because  
>>> they might also be interesting for people who use a TFTP server as  
>>> part of the boot process.
>>> Getting client vendors to support an arbitrary vendor information  
>>> option, might be as hard or easy as getting them to support an  
>>> optional extension to the protocol. On the server side it is  
>>> probably easier to agree on a few standard vendor options which  
>>> get implemented.
>>> The only hard part is to know which vendor information options are  
>>> already out there and are useful, and which need to be created.  
>>> But it is probably the cleanest and intended way of extending the  
>>> protocol.
>>>
>>> Regards,
>>> Marcus
>>> _______________________________________________
>>> dhcp-users mailing list
>>> dhcp-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>