A note on DHCPv6 DUID and Prefix Delegation

This is a short post about an issue I had regarding prefix delegation and the use of DUID in DHCPv6.

Story

I have a static/fixed IPv6 prefix (/48). My ISP init7 offers this for free. I had it setup a while ago when I had 1Gbps connection (Fiber/FTTH). I did not ask, but I thought it was working based on OTO ID. If you do not know, OTO ID is the number on the fiber optic socket (at my apartment). So it actually uniquely and physically identifies my connection at the ISP, this is how the connection is initially purchased and setup. So I thought it is reasonable to use this for the prefix delegation.

Some months ago, I have upgraded my connection to 10Gbps. This means I have changed my network adapter (hence its MAC address has changed). I was not using the prefix particularly for something until recently, then I setup something that requires this particular prefix, and I realized the prefix I was using was different than the one fixed for me before. So I reported it to init7, and they fixed it. I did not pay too much attention, because I thought there was maybe a mistake on their side or because the connection is upgraded to 10Gbps etc. so they had to change infrastructure, the port I am connected on their side etc. I was not using the prefix for something important yet so it caused no issue.

Then, this week, I changed my network adapter again (hence MAC address changed again), still 10Gbps connection but just different adapter. The problem happened again, so I again have contacted init7 support. This time I wanted to know more about the issue (because I may change the network adapter again sometime in future) to prevent it from happening. It was pretty obvious this was not due to an error on their side so prefix delegation was not based on OTO ID for sure. So I thought it is based DUID, and DUID changes with MAC, hence the prefix delegation not working. Initially init7 engineer told me it is based on MAC. I first thought maybe he meant DUID but MAC is much more known by users, so maybe he wanted to use the more common terminology, assuming I was right this was due to DUID change due to MAC change, but this was not the whole story.

I asked the engineer again if he really meant it is based on MAC or maybe he meant DUID, and if he meant DUID, I thought I can start using DUID-UUID to eliminate this issue in the future. (more about DUID types below)

Before I got an answer, I realized I actually thought about this before, and I actually fixed my DUID. It was a DUID-LLT so it was generated based on MAC, but I then specified it explicitly on the firewall (pfSense), so even if I changed my network adapter, it was still sending the previous DUID, generated based on the MAC of the previous network adapter. It sounds strange (but actually not), but because the DHCPv6 server should interpret UUID as an opaque byte array, it should have worked, but it did not.

Then I got the answer from the engineer. He told me some ports are using OTO ID and other ports are using MAC for prefix delegation. So it was quite unexpected for me, I thought DHCPv6-PD (Prefix Delegation) is working 100% with DUID. I also confirmed it by changing my DUID from previous DUID-LLT type, to a freshly generated DUID-UUID and I was still receiving the same static prefix assigned to me. So the prefix delegation was not using the DUID.

The take home message is, prefix delegation does not need to be based on DUID.

DUID Types

DHCPv6 uses DHCP Unique Identifier (DUID) to identify clients (and also clients identify the DHCPv6 server by its DUID). DUID concept is not new, but DHCPv6 made it popular. DUID as the name indicates, should be unique, somehow related to client and be generated once and re-used (as long as the client is the same). DUID is made very flexible and future proof. The server is not supposed to understand what it contains, it only interprets it as a sequence of bytes (maximum 128, but it is variable, so it can be shorter). The format of DUID (RFC 8415) depends on the DUID type, and the DUID type is stored always in the first 2-bytes (16-bits).

There are at the moment four DUID types:

• DUID-LLT (Type 1): using Link-Layer address plus Time (32-bits, seconds since 01.01.2000 00:00 UTC modulo 2^32)
• DUID-EN (Type 2): using vendor assigned Enterprise Number
• DUID-LL (Type 3): using Link-Layer address
• DUID-UUID (Type 4): using a Universally Unique Identifier (UUID)

The relation to client in Type 1 and Type 3 is based on MAC address, whereas in Type 4 it can be randomly generated. For Type 2, you should have a Private Enterprise Number (PEN) registered at IANA, and then use your identifiers.

When I say it like this it sounds like DUID-LLT changes when MAC changes, but actually the point is not this. It is only about the generation of DUID. RFC says if a device has multiple network interfaces, so multiple link-layer addresses, one of them should be selected for DUID generation and this DUID should be used for all network interfaces, so it is a representation of this client (computer, server, router etc. whatever the device is) and not only a representation of a network interface. Moreover, the generated DUID-LLT should be used even if the network interface having the link-address that used for generation of DUID is removed (because it is still the same client/device, you might have just replaced the network adapter like me). If the device does not have a non-volatile storage, then it is recommended to use DUID-LL.

Even if DUID-LLT in the above described usage solves issues regarding to network interface changes and it seems DUID-UUID type is proposed for some other issues, I think using DUID-UUID makes sense if DUID is supposed to represent the client not the actual interface.

As an example, if the time can be encoded in hex as tt:tt:tt:tt, and if the MAC address is aa:bb:cc:dd:ee:ff, DUID-LLT is:

00:01:00:01:tt:tt:tt:tt:aa:bb:cc:dd:ee:ff

The first 00:01 encodes DUID Type 1, the second 00:01 encodes hardware type which is Ethernet and has value 1.