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 <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]
