Static IPv6 assignment to clients, is a DUID always static?

Can I get some help clarifying my understanding of IPv6, is a DUID unique to the client (similar to a mac address) or is this UID generated by openwrt for the first time it sees a request from the device?

Asking in another way, will the IPv6 DUID for a client ever change under any of these:
a) I re-install the client OS (windows reinstall)
b) I flash openwrt and start from anew version or build from scratch?

Trying to understand how to retrieve the following two pieces of information assuming

uci set dhcp.@host[-1].duid="000100004fd454041c6f65d26f43"
uci set dhcp.@host[-1].hostid="23"

is "hostid" (IPv6 interface identifier (address suffix)) unique to per host or is it for the entire vlan? can I retrieve a DUID from the client without connecting to openwrt or can this number be randomly generated?

I think DUID is generated by the client.

1 Like

Yes. The DUID is designed to be a unique and stable identifier for DHCPv6 clients and servers. Quoting from https://datatracker.ietf.org/doc/html/rfc8415#section-11

The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server. That is, the DUID used by a
client or server SHOULD NOT change over time if at all possible;

It's true that the most common DUID format (mac address + time) is generated by the client. But that's a one time operation. The generated DUID is supposed stored and reused forever. Note that this means the generated DUID is stable even when the mac address it s based on is changed/replaced/removed.

That's why there are different possible formats. Some clients have no persistent storage where they could keep a generated DUID. They can then use another format, possible based on other persistent unique identifiers they already have (e.g. serial number or macaddress without time).

2 Likes

However, the DUID is generated and stored by the client OS. Parallel installations of multiple operating systems on the same physical client usually mean different DUIDs for each installation (particularly 'funny' when booting non-persistent (e.g. linux-) live systems).

1 Like

So true. When I first made the log server (RaspPi with USB flash drive) i mounted the flash drive to a fixed position with DUID. That worked until I reformatted the flash drive in a Windows computer after a while. Then the DUID changed and Rasp OS failed to recognize it.

But if I use UUID instead Rasp OS always recognize the flash drive as the same hardware.

1 Like

Sure. But this is not something you can or should try to work around on the server. The server will simply consider each of the installations as separate clients. It can't possibly know anything about the shared hardware. This will work just fine from the server point of view.

And it the client has a problem with that, then it needs to take the necessary steps to ensure it is using the same DUID regardless of OS or DHCPv6 application (you don't need to switch distro to get into this problem - switching applications is enough since there is no standard for DUID storage).

I am a bit unsure where you all want to go with this. I get the feeling that you believe you can work around client misconfigurations on the server side somehow. My advice is DON'T. It will just lead to much bigger problems, like sysadmin insanity. The DHCPv6 DUID is unique and persistent by definition. If some client breaks that, then fix the client. Don't try to make up some other client identification scheme.

1 Like

This sounds all nice on paper, unless you're in a situation where you (well, me) work with (basically) stateless systems on a daily basis, both in VMs and on the bare iron. While this works all fine with IPv4 (statically reserved DHCP leases and local DNS backed hostnames), IPv6 is a problem as the DUIDs will change often, in unpredictable ways, making external access to the test systems much more cumbersome than it needs to be.

While one could fix the DUIDs for permanently co-installed systems (depending on the OS this can be a fun trip), but that's not really an option if a larger number of freshly installed (and soon nuked again) operating systems (w2k-win11, any linux distribution imaginable, Solaris, FreeBSD, etc. pp.) alternate regularly.

  • yes, they're test systems, changing in higher frequencies
  • yes, I do need to access them from my LAN (using their DNS backed hostname)
  • yes, IPv6 connectivity is important.
  • no, only providing IPv4 DNS resolution for these systems doesn't feel like a solution (although it kind of works)

At least for my personal uses, the DUID concept of DHCPv6 is pretty much flawed (also with multiple physical interfaces on the same host, which is the case for basically all of my systems - with at least 3 interfaces each) - I'd strongly prefer MAC based DHCPv6 leases.

Quintessence for the OP: no, DUIDs won't survive a re-installation of the host OS, nor do they remain the same for co-installed systems (be it a backup installation of the same OS, a linux/ windows partition or a USB-booted linux live system); they just (should) remain the same for the life cycle of this particular OS installation on this system.

1 Like

I would prefer this as well, is this possible today on OWRT dhcpv6 server? the instructions seem to point out duid is required but makes no mention of using a mac for static v4 + v6 (dual stack) example.