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

[David Härdeman]

9 October 2025 at 16:11, "Paul D" <newtwen at gmail.com> wrote:
> On 2025-10-09 14:33, David Härdeman wrote:
>>  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. 

Yes, which is why I hope that OpenWrt will get one :)

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

Another advantage of not relying on MAC addresses is that the DUID can
be trivially generated. I've created a draft PR to demonstrate how simple:

https://github.com/openwrt/openwrt/pull/20359

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

Well...it's also a question of RFC-compliance to maintain a stable DUID
across interfaces, hardware changes, etc (and yes, I realise that storing
any of the DUID-* ids in uci would achieve that).