Help with DHCPv6 client-identifiers

[Chris Buxton]

As an alternative, why not use SLAAC-derived IP addresses, with the M flag left off? You can still use DHCPv6 for options (turn on the O flag). Just make sure all servers are using EUI-64 addresses -- this may require some minor tweaking on Windows systems, to ensure they use EUI-64 instead of random addresses.

This way, the IPv6 address used by each host is:

a) effectively static
b) based on the MAC address

Now if you do see duplicate MAC addresses in your server subnets, you can go into one or the other and change the MAC address to something unique. A reboot might be required, but the problem should thereby be solved.

Once each host picks its address, you can simply enter it into DNS -- possibly the host can do so itself, using DDNS.

In my admittedly-limited testing, a Windows 7 client in a DHCPv6-enabled network will by default end up with one of each of the following:

- normal SLAAC address
- temporary SLAAC address (limited lifetime)
- DHCPv6-derived address

For outgoing connections, the temporary SLAAC address is used. Disable that temp address and it will start using the DHCP-derived address.

For non-Windows hosts, I have yet to see much in the way of DHCPv6 support at all. So again, you're left with SLAAC, always using EUI-64 addresses (in my experience). That is, assuming the host even supports SLAAC at all.

Regards,
Chris Buxton
BlueCat Networks

On Nov 18, 2011, at 12:21 PM, <scott_stone at trendmicro.com> <scott_stone at trendmicro.com> wrote:

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