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