On 2025-10-09 14:33, David Härdeman wrote: > 9 October 2025 at 08:20, "Bjørn Mork via openwrt-devel" > <[email protected]> wrote: >> Looks like a misunderstanding of how DUID-LLT is supposed to work: >> https://github.com/openwrt/odhcp6c/pull/73#issuecomment-3382270139 > > I wouldn't characterise it as a misunderstanding. Yes, DUID-LLT's exist, but > I think a DUID-EN has some advantages. > > The first one is simplicity. With a OpenWrt-specific enterprise number, the > definition/generation of the DUID is up to the "vendor". And we could define > the DUID-EN as being simply <enterprise-number> + a random identifier of > suitable length/complexity (say, 128 bits), created on first boot, similar to > how ULAs are handled today by OpenWrt [1].
If/when openwrt gets an EN, then this is entirely viable. > The DUID-LLT has the disadvantage that it is linked to a hardware address. > That means that an interface has to be picked on first boot, and the > MAC/hwaddr of the chosen interface will then be part of the DUID which will > be used/visible on all interfaces "forever". I can see that that could be > confusing to users. That's why I think DUID-LLTs are better suited for e.g. > a printer with a single ethernet port. Heck, even OpenWrt's own odhcpd digs > through DUID-LL/DUID-LLT identifiers and tries to convey meaning from them > (i.e. try to derive a MAC address from the DUID). > The original RFC[1] discusses this case, which is why LLT is applicable today: The choice of network interface can be completely arbitrary, as long as that interface provides a globally unique link-layer address for the link type, and the same DUID-LLT SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID-LLT. [1] https://datatracker.ietf.org/doc/html/rfc3315#section-9.2 So we can use the device MAC. Once generated, a user can migrate their device config to a newer device, and retain the DUID. EN is just as flexible but requires an EN, not yet available today. Maintaining a stable DUID isn't critical - it helps maintain a more stable network environment. Home consumer networks are more dynamic. New devices, new internet providers, new routers every so often. > The DUID-EN is better suited to convey the purpose of the identifier, that > it is a permanent per-host identifier with no real linkage to any particular > interface and no particular meaning beyond that. Randomness further derived when an EN is available, vs randomness derived from hardware and time. > > In that sense, the scheme that I'm thinking of is kind of similar to > DUID-UUIDs. This is also the approach used by e.g. systemd (they have > an enterprise number and generate a DUID-EN using the "machine-id", which > is generated on first boot [2]). > >> But I guess the real cost is that OpenWrt would have to create a policy >> and internal registry of it's usage. Otherwise it would pretty soon be >> unusable because of collisions. > > I don't see why a registry would be necessary? Just create a random DUID > with enough bits that the odds of a collision are astronomical...? Agreed. ULA is sufficiently random. ULA were originally thought/designed to be globally unique. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
