Re: [dhcwg] Pre-determining DUID

[Bud Millwood <budm at weird-solutions.com>]

On Sunday 18 October 2009, Ted Lemon wrote:
> > So these are the motivations behind our desire at least to provide the
> > chaddr in the DHCP packet as a way to identify and classify clients.
> > As I said in my other email, we have a working prototype that does
> > exactly this for ISC dhcrelay.
>
> My only objection to you proposing this is that it's clear to me from
> some of your early statements in this message that you actually intend
> to use the MAC address from the relay agent option as an identifier in
> place of DUID, and not as a hint for your back office system to use in
> connecting DUID-based identifiers to MAC-based identifiers.   This is
> unnecessary--what you're proposing completely solves your problems
> without requiring any change to RFC3315 or RFC4361.
>
> So if you were to propose a protocol extension that included the MAC
> address in the relay agent options, and you were to describe how it
> could be used as a hint to relate DUID-based identifiers to MAC-based
> identifiers, I would be in favor of that.   But to the extent that
> your proposal essentially substitutes this relay-provided identifier
> for DUID-LLT, this would eliminate an identifier that is the same
> across all interfaces for the same device, and I would not support that.
>
> One bellwether of this would be whether or not you expected a PXE boot
> loader that sends a different identifier than the OS client to get the
> same IP address that the OS client gets, because the relay-supplied
> MAC address is the same.   If you expect this, your spec breaks
> interoperability.

We've done quite a bit of research on this topic, and I think Ted hit the nail 
on the head with his last comment.

In DHCPv4 a client id served two purposes: it identified the originator of the 
DHCP request, and it identified the owner of a lease.

Identifying the originator is absolutely not the same thing as identifying the 
owner of a lease, and there is *no* requirement whatsoever that these 
identities be related.

In our DHCP server design we have separated out the process of identifying an 
originator so much that we will accept almost any form of identification you 
care to configure, while still enforcing the DHCPv6 requirement that we 
assign leases to a DUID/IAID/IATYPE. (This makes for some interesting 
possibilities)

Since you expect to have some reasonable form of unique identification, I 
suggest that you seriously consider adding the hardware type to this option 
you are proposing. Without the hardware type you run a higher risk of 
identity clashes.

So the proposal should state that the htype+MAC address you are providing MUST 
NOT be used for the assignment of leases. This is no different than if you 
were to configure the server to identify the originator using the relay agent 
interface-id option.

MAC addresses are ubiquitous and a reasonable form of originator 
identification (when taken with htype), so I think this proposal is perfectly 
acceptable... even downright useful for many workflows that require 
pre-provisioning of devices.

- Bud