[riot-notifications] [RIOT-OS/RIOT] Address registration handling inappropriate (#15867)
notifications at github.com
Wed Jan 27 14:05:50 CET 2021
> […] 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.
Yeah RFC 6775 is that often (it says e.g. also to send DARs directly to the 6LBR, but does not tell how to know the 6LBRs address; one could suspect to take the address from the ABRO, but as the ABRO is part of the optional multihop prefix dissemination we can not rely on always having that for the equally optional multihop address registration).
> > 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? […]
I'd say sending status code 0 is the right way to go. The implicit meaning of registration lifetime 0 is the sender of the NS saying "please delete my entry", so there should be a reply to that that the deletion was successful. If there is no pre-existing NCE, this would also mean to signal success, as a deletion of a non-existing item is still a successful deletion ;-).
> 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 or return a duplicate address code 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.
If the node asks for the deletion of the entry it should also be deleted at the border router. So a DAR should be send to the 6LBR and a DAD signaling success returned, whether the DAD-table entry existed or not.
> Actually, sending a DAR in this case could make sense in case a node wants to know for some reason if an address is already in use but doesn't wish to register it. Then the 6LBR would return a duplicate address status code to the 6LR. However, this would only work if this case was handled synchronously (which does not really make sense if you look at RFC 6775) and the 6LR creates a Tentative NCE, even when the Registration Lifetime is zero. However, [RFC 6775 Section 8.2.](https://tools.ietf.org/html/rfc6775#section-8.2) explicitly says:
> > When a 6LR receives an NS containing an ARO with a non-zero Registration Lifetime and it has no existing Registered NCE, then with this mechanism the 6LR will invoke synchronous multihop DAD.
> From which I'd conclude that our case would be handled asynchronously anyway
This is indeed confusing :-/
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