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