Help with DHCPv6 client-identifiers

[scott_stone at trendmicro.com]

Thanks everyone for all the input on this, I think I have a much better handle on what's going on here now.  In our case, we only use DHCP on server networks where all of the hosts are known, inventoried, and have static reservations - ie, operations installs a host, enters its info into a database, from which the DHCP configuration is derived - we do not allow unknown clients to talk on the network and do not use dynamic pools, so MAC address identification is a pretty good/safe choice for us, since every client is known and we have eyes and security cameras on every rack and switch port :) .... so it looks like we need to come up with something in our deployment methodology to pre-assign a DUID at install time.. which will work for new Linux boxes only, since scripting anything in Windows is... fun... and all those legacy systems will need someone to go in there and make changes.  Fun!  Perhaps puppet will come to the rescue yet again.

====================
Scott Stone <scott_stone at trendmicro.com>

-----Original Message-----
From: dhcp-users-bounces+scott_stone=trendmicro.com at lists.isc.org [mailto:dhcp-users-bounces+scott_stone=trendmicro.com at lists.isc.org] On Behalf Of Alex Bligh
Sent: Friday, November 18, 2011 11:33 AM
To: Bjørn Mork
Cc: Users of ISC DHCP
Subject: Re: Help with DHCPv6 client-identifiers



>> 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
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.