Help with DHCPv6 client-identifiers

[Alex Bligh]

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

There is more than one client VM on the same VLAN. As they both belong to
the same customer, if they want to spoof eachother's MACs and transpose
their IPs, that's fine by me.

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

Sure, but as my virtual switch doesn't have "ports" as such, and as
my virtual NICs are identified by MAC address, then the easy identifier
to use is ... the MAC address. Yes, I could use a circuit ID equal
to the MAC address I suppose. But it "just worked" with DHCP on IPv4.

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

This may be true, but I suspect this is because the demand for DHCPv6
is less than DHCPv4, partly because of auto configure, partly because
of DHCPv6 design decisions that make it unattractive to use.

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

We are not averse to hacking things up, and indeed did hack up our own very
lightweight DHCPv4 server because in a customer-facing environment there
are some disadvantages to ISC dhcpd, which are OT for this thread (we still
use ISC dhcpd for other stuff).

However, what we can't hack up is client operating systems, as we have no
control over them. So we are stuck with whatever clients present in the
packets. Using layer 2 MAC is a horrible solution and would not have had
applicability to many people, and has little chance of getting upstream.
So, as I said, we use auto configure, which works just fine and has 100%
support in IPv6 compliant client OSes (unlike at the time dhcpv6). If
dhcpdv6 had been less of a use-case-hostile design, I think it would have
far wider deployment.

As a general point, I think it's better to have a working standard and code
to that, than hack stuff up outside the standard.

-- 
Alex Bligh