Help with DHCPv6 client-identifiers

[Bjørn Mork]

Rudy Zijlstra <rudy at grumpydevil.homelinux.org> writes:
> On 11/18/2011 02:43 PM, Alex Bligh wrote:
>>
>>
>> --On 18 November 2011 13:48:33 +0100 Bjørn Mork <bjorn at mork.no> wrote:
>>
>>> head-in-sand... You may want to consider:
>>
>> 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.

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

>> In my view, it was an error not to put the hardware address in the DHCPv6
>> packet as an option. The server after all does not have to use it. It use
>> any of the multiplicity of other ways of allocating addresses.

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.   Unless you actually
verified that the option matched the source.  But if you did that, then
what extra value did the option provide?

> Which is why cablelabs added IPv6 vendor options to include the MAC
> address... It is pretty much the only way to identify a CM.

I don't have the faintest idea what the cable modem people are doing, so
I'll just have to trust you.  It sounds extremely stupid, though.  If
they can make the CM DHCPv6 client add another vendor option, then they
could have implemented real authentication instead, preventing simple
spoofing and replay attacks.  Embedding the client MAC address in the
DHCPv6 request is just pointless.


Bjørn