Can Openwrt org apply for a (DUID-EN) org/enterprise number...?

[Paul D]

On 2025-10-09 14:33, David Härdeman wrote:
> 9 October 2025 at 08:20, "Bjørn Mork via openwrt-devel" <openwrt-devel at lists.openwrt.org> 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.