Some months ago, my co-worker and I ran into an interesting issue: a notebook with a newly installed Ubuntu 20.04 does only work with IPv4, but this office network is dual-stacked (IPv4 and IPv6). Other Linux clients as well as Windows and Mac systems still work fine. They all get an IPv4 configuration by DHCPv4 and an IPv6 configuration by stateful DHCPv6 from the same DHCP server, relayed by a Cisco ASA 5500-X. What’s wrong with Ubuntu 20.04?

Our first idea was, that we forgot to activate global IPv6 during installation. But it was enabled. Our next idea was an active local firewall that blocks DHCPv6 packets or IPv6 in general. This is a frequent problem because DHCPv6 is using UDP ports 546 and 547. But the same notebook at a home network works fine with IPv6 and IPv4. We had to look at our network…

In this network, a Cisco ASA is acting as the default router to the internet. It’s also acting as a DHCP relay system for IPv4 and IPv6 to forward DHCP packets of the clients to the central DHCP server and back. But the DHCPv6 server didn’t get a SOLICIT message from the client; DHCPv4 works.

Some log lines from the ASA got our attention:

At this time we didn’t understand the log lines. Because we had no better idea, we decided to activate some debug commands at our ASA:

Maybe that’s a few commands too much, but we wanted to get a hint of what we are doing wrong. Less than 100 seconds later we got the following lines:

This tells us: there is a client that wants to get an IPv6 configuration (solicit) but the ASA decides the DHCPv6 client ID with a length of 18 octets is wrong. Because of this, the ASA throws away the solicit message.

OK. Now we know the device which causes the problem. But what’s wrong?

We searched around and found, Cisco knows this issue: ASA dropping DHCPv6 SOLICIT from Unix-based systems (unfortunately only accessible with a Cisco Account). They recommend a workaround: “Modify the client UUID to use UUID of 1”. We had no idea why changing the system UUID should be a way to get DHCPv6 working…

Now we had a more detailed look at the messages we got in the ASA console. There we saw from Windows system lines like this:

The Ubuntu system causes these lines:

Some more hours later we understood the issue like this: Cisco implemented the relaying of DUID types 1-3, [not UUID!] defined in RFC3315 (July 2003), but not the additional DUID type 4, defined in RFC6355 (August 2011). And we get the hidden hint from Cisco for their workaround: change the DUID (DHCP unique identifier) to a type 1 DUID.

For Ubuntu Linux we didn’t find a (for us working) way the change DUID type to 1; but in a new Debian 10 installation of another co-worker, we run in a similar issue. After installation the system used a DUID type 4, too:

For the Debian Linux system, we found the workaround: we delete the lease file and create a new one with a DUID type 1 (DUID-LLT = link-layer address plus time ).

Of course, you can use a DUID type 2 (vendor-assigned unique ID based on Enterprise Number) or DUID type 3 (link-layer address), too.

This is just a workaround for a network with less affected clients. If you have to publish this solution for a large bring-your-own-device (BYOD) network with many affected clients: Have fun!

At the time of writing these lines, there is an update at the Cisco case which indicates that there should be a new version of the ASA operating system which should fix the DUID type 4 issue of the DHCPv6 relay agent. We are looking forward to get the new version, maybe in a few years. :-)

Reference: DHCPv6 Relay configuration example for Cisco ASA

Photo by NeONBRAND on Unsplash.