Hi Mathis, You are in a right place to ask this question. I will try to answer your questions as per my best knowledge.
1-RFC 9685 did not update RFC6775. 2- ROVR always in NA(EARO), whether it's unicast or multicast. So, all one hop nodes know who was the actual source of NS(EARO). 3- S-bit will not set in NA(EARO) whether it's unicast or multicast. If I am not wrong, I think it is for NUD, but please check RFC 4861. I hope my answers correctly address your questions. Regards, AR On Thu, Apr 24, 2025, 14:34 Mathis Marion <mathis.marion= [email protected]> wrote: > 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] >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
