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

[Marcus Goller]

Ralph,

Ok, understood, thanks. Reading through RFC 3315 and then looking at the 
CableLabs DHCP specifications for DHCPv6, I came to the conclusion that 
it apparently is up to the vendor to fill the gaps. But I now see that 
this was a decision made by CableLabs and I could imagine that others 
would go down that route too, before approaching the WG and go through 
the formal processes.

Coming from the cable industry, I am fine with what is available in the 
CableLabs vendor space so far.

Ralph Droms wrote:
> Marcus - the decision is not so much to leave other options to "vendor 
> options" as to define new options "on demand".  The dhc WG made a 
> decision that there are a lot of DHCPv4 options that are essentially 
> unused, so we reviewed the list, came up with a minimal set of 
> required options which were included in RFC 3315.  We've defined a few 
> other options since RFC 3315.
>
> If you have other options that are note yet defiend and would be of 
> global interest, please bring them to the attention of the dhc WG.
>
> - Ralph
>
> On Mar 7, 2009, at 6:58 PM 3/7/09, 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