DHCPv6, DUID+IAID, Client Identifier Revisited

mdpugh

It's been a while since I investigated whether any headway had been made regarding using DUID+IAID for soliciting an IPv6 address from ISC's DHCPv6 server. As far as I can tell, they still have the phrase The "host-identifier" option is limited to a simple token in the latest version, so I am assuming the answer is "no", at least as far as fixed addresses are concerned. I'd still like to know what is taking so long to address this limitation, but I'll take that up in the ISC forum.

From a pfSense point of view, I just tried enabling one of the interfaces as a DHCPv6 client and captured the traffic on the DHCPv6 server. It's still showing a 0000000 IAID, so I assume the ISC client (you did switch to that, right?) isn't passing this information even to obtain a non-fixed address. I don't know if the IAID is even being generated by the client. Has anything moved at all on this front since I last asked?

I also came across the following at http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/:

Surprise #2: You can no longer simply use the MAC address of an interface to assign a fixed IP address via DHCP. Unlike DHCPv4, in which the MAC address of the client interface is included in a DHCP request, DHCPv6 uses a DHCP Unique Identifier, or DUID, to uniquely identify the client. By default, the DUID is synthesized from the MAC address of an arbitrary interface on the host plus the system time at the moment the DUID is generated. The same DUID is then used regardless of which interface a DHCPv6 message originates from.

The DUID normally persists across reboots, but if it’s deleted on the client, e.g., when a new operating system is installed, the DUID is automatically regenerated with a new time, and the server will no longer recognize it. RFC 3315 prohibits using a portion of the DUID as an identifier (it must be treated as opaque), so DHCPv6 servers can’t be told to “just look at the MAC address part” of the DUID.

Fortunately for those wishing to use old-style MAC addresses, there’s an alternative DUID type that let you do this. The DUID described above is a “Type 1” DUID, and is referred to as a “Link-Layer plus Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type 1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs (DUID-LLs), which is simply the MAC address prepended with two identifiers (the sequence “00:03:00:01”). Moreover, these can be configured on a per-interface basis in the ISC DHCP client.3 Problem solved.

3. The configuration for doing this is:
interface "eth0" {
  send dhcp6.client-id = concat(00:03:00, hardware);
}

interface "eth1" {
  send dhcp6.client-id = concat(00:03:00, hardware);
}

Is this legit? Has anybody tested this? It's certainly not the solution I'm waiting for, but it would solve a lot of problems in the short run if "hardware" in the above configuration generates a different string in each interface definition.

Actually, it doesn't matter that much whether "hardware" does in fact generate a different string in each case. What does matter is how much freedom in creating the dhcp6.client-id is available. From looking at the packet capture, a dhcp6.client-id that is DUID+"0003000c"+IAID (generate IAID as desired–last 32 bits of the MAC for example) should create a well-formed Client Identifier concatenated with Identity Association for Non-temporary Address. Does ISC or the RFCs place a limitation on the length or format of the dhcp6.client-id (it's been a while since I last familiarized myself)?

mdpugh

On closer inspection, it looks as if etc/inc/interfaces.inc is still constructing the WIDE client instead of ISC's version. Is this right?

databeestje

Client has not been replaced yet. I have not managed to put in the time yet.