[riot-notifications] [RIOT-OS/RIOT] Address registration handling inappropriate (#15867)
notifications at github.com
Wed Jan 27 13:48:11 CET 2021
@miri64 I initially wrote this bug report for the first case (which I looked into more extensively) and just assumed this was also a problem for the second case (which it seems is not true). My apologies for jumping to conclusions. Concerning the proposal for a fix, I think the way forward is up for interpretation, as RFC 6775 does not explicitly mention this case (i.e., no pre-existing NCE and an incoming ARO with Registration Lifetime of 0) and / or is vague at best.
For example, [RFC 6775 Section 6.5.3.](https://tools.ietf.org/html/rfc6775#section-6.5.3) says:
> If the ARO contains a zero Registration Lifetime, then any existing NCE for the IPv6 source address of the NS MUST be deleted and an NA sent
However, this has an ambiguous implicit meaning at best for the case wherein there is no pre-existing NCE. Do we ignore the NS altogether? Or do we simply return a NA with Status code = 0? And what would happen then in case of multi-hop DAD?
For example, [RFC 6775 Section 8.2.3.](https://tools.ietf.org/html/rfc6775#section-8.2.3) says:
> When a 6LR receives an NS from a host with a zero Registration Lifetime, then, in addition to removing the NCE for the host as specified in Section 6, a DAR is sent to the 6LBRs as above.
If you opt to return a NA, it does not make sense to also send a DAR to the 6LBR, which would conceivably ignore this DAR anyway since there is either nor pre-existing entry in the 6LBR DAD-table or the supplied EUI-64 wouldn't match the one stored in any pre-existing entry anyway. In other words, this would be redundant.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications