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