Help with DHCPv6 client-identifiers

[Alex Bligh]

>>> In some deployments yes. In others, nearly everything you have written
>>> is irrelevant. For instance, We use DHCP to give IP addresses to virtual
>>> machines. We know the MAC address we give them, as we build the NIC (and
>>> indeed sometimes filter other MAC addresses out).
>
> The need to filter is absolute.  There is nothing preventing the client
> from spoofing a mac address.

It must be nice to think you know more about my deployment than I do. The
need to filter is actually not absolute. In one mode of operation, we offer
private virtual VLANs unique to the customer, and MAC collision with
devices on other virtual VLANs does not matter. Allowing MAC spoofing in
such an environment is useful, as some horrible customer software requires
it.

> I would have identified these by the (virtual) switch port they were
> connected to, both for DHCP and DHCPv6.

Which is not in the DHCP packet unless your virtual switch intercepts
and rewrites the DHCP.

> Right.  And it it were, then it wouldn't even have helped if you did
> filter.  The client could use its allocated mac address as source, but
> just put some other address in the DHCPv6 option.

Sure, and the client would then get the wrong IP address, which (in
the environment we're talking about) would not matter, as it would
only break that client.

> Unless you actually
> verified that the option matched the source.  But if you did that, then
> what extra value did the option provide?

The ability to use unmodified standards-compliant DHCP code. As we
did not want to run a hacked up version of DHCP, we just dropped
support for DHCPv6, as I said.

-- 
Alex Bligh