gnrc_ipv6_nib/SLAAC: rfc7217 stable privacy addresses

[xnumad]

Contribution description

Implementation of RFC7217 ("stable privacy") means that for addresses generated by SLAAC, their IID (interface identifier) is

• semantically opaque, i.e. cannot derive hwaddr from it
• random but with such parameters that it is stable within a subnet (i.e. for the same prefix on the same interface)
• derived from a randomly generated key (secret_key) that shouldn't be shared across devices.
  RIOT-specific: The implementation in this PR compiles the secret_key into the elffile, therefore the same elffile shouldn't be flashed onto multiple devices - in order to fulfill the RFC requirements.

Notes about implementation:

• uses tail recursion (i.e. optimizable by compiler, or manually replacable by a loop) (affects stack size)

RFC compatibility: Requirement levels: (implemented: MUST, SHOULD. not implemented: MAY, OPTIONAL.)

--

Adaptability

Supports any link layer that has a hardware address:
https://github.com/xnumad/RIOT/blob/88363f3cde7175691fe27399d73a54e08934e6c7/sys/net/gnrc/network_layer/ipv6/nib/_nib-slaac.c#L168-L169

The usage of IIDs which do not match the link layer address causes LOWPAN_IPHC to not be able to statelessly compress the IP address anymore. An optimization to enable compression again could be to add compression contexts (feature branch for opportunistic compression contexts: https://github.com/xnumad/RIOT/tree/feature%2Fopportunistic-compression-contexts).

6LoWPAN specifics

They do not affect this PRs current functionality but are worth noting.

For link-local addresses on a 6LN iface, this PR does not use the IDGEN (interface identifier generation) mechanism described by rfc7217.

• This is because of incompatibility with 6LoWPAN-ND (RFC6775) (and RFC8505, which would allow it, is not implemented).
• → Not fulfilling RFC7217 requirement "MUST be employed for [...] link-local"

Testing procedure

Add CFLAGS += -DCONFIG_GNRC_IPV6_STABLE_PRIVACY=1 at the appropriate position in the Makefile of examples/gnrc_networking. Tested on BOARD=nrf52840dk

Output of ifconfig command shows that SLAAC addresses have random differing IIDs (except for link-local address on a 6LoWPAN iface, see above). The IID is stable within a subnet, i.e. it also persists across reboots.

Issues/PRs references

Commits marked with 🍒 (cherry-picked) are largely derived from the RFC8981 implementation at #20369

[chrysn]

I don't have the time to do a full review at the moment, but from a quick high-level reading this looks like it's well done, and checks a lot of boxes (including careful treatment of Kconfig handling).

A few notes around here and there are really just "things that struck me" with no particular severity. Given there are a lot of fixup commits from the onset, please consider squashing (possibly after handling any of my comments), as that'll make the sequence of commits easier to understand.

[chrysn]

We'll have to think a bit about device individualization in RIOT as a whole (esp. for questions like "is this maybe better created in a HWRNG assisted way at first start?"), but until then, passing it into the build seems fine.

As someone who repeatedly flashes devices and then starts network interactions, it may be convenient to store this in the build directory and recreate only if absent, as that will make addresses stable across rebuilds.

[xnumad]

Definitely agree, letting the board generate the secret_key by itself (and permanently store it - as per the RFC) would be more convenient, as a future improvement!

[xnumad]

Squashed

[xnumad]

Squashed a typo

[xnumad]

Rebased.