EUI-64 calculation

[OlegHahm]

I just discovered that RFC4193 describes an algorithm to generate a Pseudo-Random Global ID from either a MAC address or "a suitably unique identifier, local to the node, should be used (e.g., system serial number)". Maybe we can use this algorithm for creating an EUI-64 from the CPUID?

[miri64]

Looks alright on first side 👍

[OlegHahm]

SHA1 is on its way: #4701.

[miri64]

Just to be clear, the algorithm described on the RFC still requires the time of date and also describes the creation of a (somewhat) globally unique IPv6 address, right?

[OlegHahm]

Yes, it requires time and date (most of the devices have an RTC and even if not gettimeofday() can also be called with xtimer and it doesn't matter if the timestamp is "real"). And it describes how an EUI-64 and an IPv5 address can be obtained.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

@benpicco @maribu this could be interesting for your rework of luid.

[maribu]

@benpicco @maribu this could be interesting for your rework of luid.

I'd say the current luid implementation is superior in terms of usability, as

• No NTP timestamp is needed for generation in luid
• The same board with the same transceiver setup will always end up with the same local EUI in luid

[miri64]

It is however still problematic when the CPU ID is very similar (see e.g. last week's discussion to the users list)

[benpicco]

Is there a small hash algorithm that produces 64 bit output? Hashing the CPU ID would provide better results than just xor in a loop.

[maribu]

IMO this can be closed.

@benpicco: ping :)

[benpicco]

The algorithm described in RFC 4193 won't work for us as it depends on the time - and we want stable L2 addresses.

But our current algorithm appears to be working quite well, so let's close this. (also, see #15239)