Dear Adnan, Thank you for providing more information. My question is about the STATUS=11 (Registration Refresh Request), not STATUS=3 (Moved). The corresponding procedure is described in section 7.3 of RFC 9685. I understand that the NA(EARO) status=3 is associated with a single address registration, so the content ROVR field is quite intuitive. However this is not the case of the NA(EARO) status=11.
Regards, Mathis Marion Silicon Laboratories On 29/04/2025 01:28, Adnan Rashid wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear Mathis, Thanks for adding and correcting me. Let me answer again to your two questions in first email 1-Solicited NA (EARO): In direct reply to an NS (source ≠ ::), sent unicast with S = 1. 2-Unsolicited (“STATUS=Moved”) NA (EARO): Sent multicast BY 6LR to its vicinity for stale-state cleanup with S = 0. Every NA (EARO), whether solicited or not, carries the original 6LN’s ROVR to identify which binding is being confirmed or purged. Standards Respected: - S-bit per RFC 4861/6775/8505/9685 - EARO format and semantics per RFC 8505 Regards, AR On Fri, Apr 25, 2025, 14:25 Mathis Marion <[email protected]> wrote: On 24/04/2025 18:48, Adnan Rashid wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hi Mathis, > Hello Adnan, > 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). In a multicast NA(EARO) packet for registration refresh, if we put the source EUI-64 of a NS(EARO) in the ROVR, then the NA(EARO) will be processed by a single neighbor: the one who owns the EUI-64 and initially sent a NS(EARO). However the purpose of sending the "Registration Refresh Request" in multicast seems to be to query all of the neighbors at the same time. > 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. From my understanding: - In classic NDP (RFC 4861), the S bit is set in all unicast NA. These unicast NA can be responses to NUD probes (unicast NS), but also responses to multicast NS for address resolution. - In 6LoWPAN NDP (RFC 6775), the goal is to remove multicast NS for address resolution, so hosts are expected to register their address to their router. In this case the role of the NS and NA is quite different: NS(ARO) is used to advertise an address and NA(ARO) serves as an acknowledgement. I believe it makes sense to set the S bit in these NA(ARO) since they are still "solicited" (ie. a response to a NS). This is not stated explicitly but I would assume this from classic NDP. - In RFC 9685, the NA(EARO) gains a new purpose with the registration refresh procedure. In this instance the multicast NA(EARO) is spontaneously sent by a router, so it makes sense to clear the S bit (ie. the packet is unsolicited). > > I hope my answers correctly address your questions. > Thank you for sharing your knowledge. > > Regards, > > > AR > > On Thu, Apr 24, 2025, 14:34 Mathis Marion <[email protected] <mailto:[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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
