Help with DHCPv6 client-identifiers

Bjørn Mork bjorn at mork.no
Fri Nov 18 18:56:02 UTC 2011


Alex Bligh <alex at alex.org.uk> writes:

>>>> 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.

Yes, but then you do have the ability to identify the clients by VLAN,
don't you?

>> 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.

Yes, you want a (possibly Lightweight) DHCPv6 Relay Agent saving this
information for you before forwarding the packets to the DHCPv6 server.


>> 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. 

The current state of open source DHCPv6 code does not really allow
this.  There are no full featured implementations. 

> As we
> did not want to run a hacked up version of DHCP, we just dropped
> support for DHCPv6, as I said.

Isn't it better to hack up whatever you want, and see if you can get it
upstream? 


Bjørn



More information about the dhcp-users mailing list