NDP: implement missing functionality

[miri64]

This is an overview issue to organize ongoing development of IPv6 neighbor discovery:

• Main ND, RFC 4861
  • Router Discovery and Prefix Discovery; section 6 [gnrc_ndp_router: Initial import of router behavior of router discovery #3049 -> merged]
  • Address Resolution and Neighbor Unreachability Detection; section 7 [ng_ndp: initial import of address resolution #2910 -> merged]
  • Redirect Function; section 8
• IPv6 Stateless Address Autoconfiguration, RFC 4862
  • Assign Link-local address to interface [as part of ipv6_netif: initialize device dependent values #2944]
  • Duplicate Address Detection
  • Creating Global Addresses
• Neighbor Discovery Optimization for 6LoWPANs, RFC 6775 [gnrc_sixlowpan_nd_border_router: initial import of border router behavior of 6LoWPAN-ND #3134 -> merged]
  • "sensible" context configuration for border routers (see RFC 6775, section 7.2)
  • sleeping/wakeup behavior RFC 6775, section 5.8
  • Multihop DAD

Unsure, because important for understanding of RFC 6775, but unknown if implementation effort is needed:

• DHCPv6 clients, RFC 3315
• IP Addressing Model in Ad Hoc Networks, RFC 5889

Optional:

• Unhastify NUD, RFC 7048 (as part of gnrc_netif2: gnrc_ipv6_nib: full integration into GNRC #7925)
• Router prioritization, RFC 4191

[miri64]

Should look into this when working on #5293.

[PeterKietzmann]

@miri65 now that the new NDP is nearly there, could you update the "missing functionalities" list please

[miri64]

@miri65

I'm getting older 😭

This is still up-to-date. The NIB did not add any significant new functionality. It's in the project as a reminder to the testers, that some functionality isn't implemented yet (and won't be in #7925).

(side-note: even if there would be new functionalities, I only would update them after #7925 got merged ;-))

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

[tinstructor]

@miri64 @benpicco I was wondering what happens when the ABRO valid lifetime expires since RFC 6775 is rather ambiguous (at least to me it is) on this subject. For example, it states on page 29:

When the ABRO Valid Lifetime associated with a 6LBR times out, all information related to that 6LBR MUST be removed.

But then on page 36 it says:

The router keeps state for each 6LBR that it sees with an ABRO. This includes the version number, the Valid Lifetime, and the complete set of PIOs and 6COs. The prefixes are timed out based on the Valid Lifetime in the PIO. The Context Prefix is timed out based on the Valid Lifetime in the 6CO.

I've tried digging through the code and I think I understood that RIOT just times out all information stored for a given 6LBR (i.e., including contexts and prefixes) when the ABRO valid lifetime expires, regardless of the fact that prefix and context lifetimes may not have expired yet. Conversely I understood from the code that when prefixes and / or contexts expire before the ABRO does, they are timed-out independently. Is my assumption correct?