host-identifier with IPv6

[Marcus Goller]

> You can always come up with a scenario where you can show that DHCP doesn't
> do what you want in that scenario.   But each specific behavior of DHCP is
> there for a reason.   Rather than attempting to engineer a different
> protocol that does precisely what you want, and in the process opening
> yourself up to all the interoperability problems we were trying to avoid
> when we wrote the spec, why not simply figure out how to get what you need
> in the context of the spec as written?

That would probably require some sort of pattern matching capability
on the server side, allowing to skip or ignore the first 64 or 32 bit,
depending on the DUID type (and also taking the hardware type into
consideration). If the DHCP clients allow to print the DUID value,
this might be a possible way to identify the client, depending on the
actual process of when and how IP addresses are configured on the DHCP
server. This still leaves some uncertainties of which link-layer
address is going to be chosen by the client, if multiple network cards
are present. Pre-configuring the DHCP server with the MAC address from
a sticker on the outside might not work then. Allowing the DHCP client
to make it configurable which interface to use might not be in line
with the RFC, as it would not keep the DUID consistent over time
(after it was first generated), if I understand that correctly.

Marcus