Hello Pascal, Good to see this confirmed, then I suppose an exception needs to be added to the EARO verification rules, similar to how RFC 9685 section 4 allows multicast IPv6 addresses in the Target field of NS packets. Wi-SUN does not use any multicast addresses at the MAC layer, only broadcast, so in this case it probably makes most sense to use ff:ff:ff:ff:ff:ff:ff:ff. However, I am not familiar enough with MAC layer multicast addresses to conclude anything. I will try to discuss this in the Wi-SUN working group.
Regards, Mathis Marion Silicon Laboratories On 29/04/2025 11:01, Pascal Thubert 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. Hello Mathis Yes, this is a gap in the spec. I agree that using a broadcast value is a good idea. I'd suggest 33:33:00:ff:fe:00:00:01 to match the way we build the MAC address for SNMA. Can you specify that in the Wi-Sun spec and come back to us with your wording? We could write an erratum based on your working proposal. all the best Pascal Le jeu. 24 avr. 2025 à 14:35, Mathis Marion <[email protected]> a écrit : 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] -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
