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

[Bjørn Mork]

"David Härdeman" <david at hardeman.nu> writes:

> 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 

Quoting from the link I gave:

 Hm, come to think of it....we might want to consider generating a
 DUID-EN on first boot and stashing that in permanent storage via
 UCI...then the DUID would remain stable even if interfaces change

That's definitely misunderstanding how DUID-LLTs work. They are as
stable as DUID-EN regardless of interfaces changes.

> 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].

DUID-EN is not simpler.  You need entropy.  You need more storage.  You
create larger network packets.  You create a non-standard OpenWrt
specific DUID allocation scheme.

Provided we accept that unlikely is good enough to satisfy this MUST:

   The source of the identifier is left up to the vendor defining it,
   but each identifier part of each DUID-EN MUST be unique to the device
   that is using it, and MUST be assigned to the device no later than at
   the first usage and stored in some form of non-volatile storage.

> 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".

You can be tracked equally well with any DUID type.  They are all
supposed to be stable identifiers.  That's the whole point.

> I can see that that could be confusing to users.

I can see random DUID-ENs being confusing to users.

But if we use DUID-LLT then we can at least point the confused users to
an RFC explaining it.

> That's why I think DUID-LLTs are better suited for e.g.
> a printer with a single ethernet port.

Another misunderstanding which could have been avoided by reading
RFC8415 (or RFC3315). It explicitly says this about DUID-LLT:

   This method of DUID generation is recommended for all general-purpose
   computing devices such as desktop computers and laptop computers, and
   also for devices such as printers, routers, and so on, that contain
   some form of writable non-volatile storage.

There has never been any requirement that the address donating
hardware should be related to the network interfaces running DHCPv6.  It
could be, but that's the exception.  Not the other way around.

   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; 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.

> 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).

   Clients and servers MUST treat DUIDs as opaque values and MUST only
   compare DUIDs for equality.  Clients and servers SHOULD NOT in any
   other way interpret DUIDs.

If odhcpd violates the RFC then the bug should be fixed.

> 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.

That's an opionion. I disagree.  DUID-ENs are completely unsuitable for
any uncoordinated use.

> 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]).

They don't care about standards and they don't have the luxury of
globally unique mac addresses (being focused on containers and VMs with
virtual network interfaces).

I like to think that OpenWrt is different in both aspects.

>> 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...?

Sure, we can make it unlikely.

But there is an alternative which guarantees uniqueess without the
entropy cost.


Bjørn