On Thu, Apr 24, 2025 at 2:00 PM <[email protected]> wrote:
> Send 6lo mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 6lo digest..."Today's Topics: > > 1. Conclusion (Re: Call for adoption of > draft-ietf-6lo-updating-rfc-8928) > (Carles Gomez Montenegro) > 2. The 6LO WG has placed draft-ietf-6lo-updating-rfc-8928 in state "WG > Document" > (IETF Secretariat) > 3. RFC 9685 Registration Refresh Request and the ROVR field in the > NA(EARO) > (Mathis Marion) > > > > ---------- Forwarded message ---------- > From: Carles Gomez Montenegro <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Wed, 23 Apr 2025 16:24:55 +0200 > Subject: [6lo] Conclusion (Re: Call for adoption of > draft-ietf-6lo-updating-rfc-8928) > Dear 6lo WG, > > The call for adoption of draft-ietf-6lo-updating-rfc-8928-00 is now > closed. > > There have been 5 messages in favor of adoption, and no messages against > it. > > We declare that the document is now adopted by the WG. > > Thanks to everyone who has participated. > > Cheers, > > Shwetha and Carles > > > On Tue, 15 Apr 2025 at 09:46, Carles Gomez Montenegro < > [email protected]> wrote: > >> Dear 6lo WG, >> >> This message starts a call for WG adoption of >> draft-ietf-6lo-updating-rfc-8928-00. >> (Link: https://datatracker.ietf.org/doc/draft-ietf-6lo-updating-rfc-8928) >> This document aims to fix a mistake with the C flag in EARO in RFC 8928. >> As this is a short document, the call will end on the 22nd of May, EOB. >> >> Please state whether you are in favor of adopting this document. >> >> Also, comments and reviews of the document will be very much appreciated. >> >> Thanks, >> >> Shwetha and Carles >> >> >> > > > ---------- Forwarded message ---------- > From: IETF Secretariat <[email protected]> > To: <[email protected]>, <[email protected]>, < > [email protected]> > Cc: > Bcc: > Date: Wed, 23 Apr 2025 08:46:19 -0700 > Subject: [6lo] The 6LO WG has placed draft-ietf-6lo-updating-rfc-8928 in > state "WG Document" > > The 6LO WG has placed draft-ietf-6lo-updating-rfc-8928 in state > WG Document (entered by Carles Gomez) > > The document was previously in state Call For Adoption By WG Issued > > The document is available at > https://datatracker.ietf.org/doc/draft-ietf-6lo-updating-rfc-8928/ > > > > > > ---------- Forwarded message ---------- > From: Mathis Marion <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Thu, 24 Apr 2025 14:34:24 +0200 > Subject: [6lo] RFC 9685 Registration Refresh Request and the ROVR field in > the NA(EARO) > 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] >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
