Hello,
This is my first time writing on a IETF mailing list, so I hope that it
is the right place to ask such questions. If not, feel free to redirect
me to the right place.
First, a bit of context: I am working on the Wi-SUN protocol stack
which uses the 6LoWPAN adaptations mechanisms for IPv6 Neighbor
Discovery. In this context, the "Registration Ownership Verifier"
(ROVR) field of the "Extended Address Registration Option" (EARO) is
always an EUI-64.
RFC 9685 defines a new mechanism "Registration Refresh Request" to
force transmission of NS(ARO) packets from neighboring hosts: a router
sends a NA(EARO) packet in multicast with a dedicated EARO status code.
My question is: in this special NA(EARO) multicast packet, what value
should be put in the ROVR field of the EARO? This packet is clearly not
destined to any specific neighbor so it does not make sense to fill it
with a neighbor EUI-64. Putting the router EUI-64 is also unexpected
since the router is not registering its own address. My last guess
would be to use a broadcast EUI-64 as the ROVR to indicate that the ARO
is not destined to any particular node.
Note that on reception of a NA(ARO), hosts must check the EUI-64 field,
and drop the packet if the value is not the host EUI-64:
RFC 6775 5.5.2. Processing a Neighbor Advertisement
In addition to the normal validation of an NA and its options, the
ARO (if present) is verified as follows. [...] If the EUI-64 field
does not match the EUI-64 of the interface, the option is silently
ignored.
I did not find any exception to this rule in RFC 8505 nor RFC 9685. Do
we need to consider the "Solicited" (S) bit of the NA to act
differently?
Thank you for your time and consideration.
Mathis Marion
Silicon Laboratories
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
