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