Hello,
To keep you up to date, the subject has been discussed with the Wi-SUN alliance.
The agreement ended up to ignore the ROVR field on reception of the multicast
NA(EARO).
I am waiting for an updated Wi-SUN specification version to share the exact
text, but here is my current proposal on the Wi-SUN side:
The EUI-64 field of the multicast NA(EARO) MUST be ignored since
the option is not destined to any specific child node. This rule
overrides section 5.5.2 from RFC 6775 and addresses potential
interoperability issues induced by a lack of details in RFC 9685.
Regarding what the IETF wants to recommend, I would still argue in favor of
using a broadcast/multicast address when relevant.
I do not know much about other usages for the 6LoWPAN stack where the ROVR is
not a MAC address so I do not know how realistic this proposal really is.
Regards,
Mathis Marion
Silicon Laboratories
On 29/04/2025 12:29, Mathis Marion wrote:
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]
