Hello Chris: I just published 05 with the diffs here https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt
You'll find 2 things: - the capability to send an asynchronous (multicast to all nodes) NA(EARO, target= self) at reboot with a new status asking for reregistration. - a new Node Uptime Option that allows (the peer 6LN) to discover that the node (e.g. 6LR) rebooted since last seen. That option can be used in NS, NA, RS and RA. Note that any new proposed option has to go through 6MAN and that's sometimes a huge step. So relying on it at this stage is a bet, and pressure to 6MAN if you do will be needed. Please let me know if that flies with you. Keep safe; Pascal From: Hett, Chris <chris.h...@landisgyr.com> Sent: jeudi 12 mai 2022 16:47 To: Klaus Hueske <klaus.hue...@renesas.com>; 6lo@ietf.org Cc: Pascal Thubert (pthubert) <pthub...@cisco.com>; Paul Duffy (paduffy) <padu...@cisco.com> Subject: RE: [6lo] Router reboot - loss of state Hi Klaus, Pascal, Yes, I agree that this is a gap that should be addressed. It is not always practical to expect constrained devices to store - potentially hundreds of - neighbor cache details across a power cycle. There should be a way for a 6LR implementing RFC 6775 to notify its neighbors that it has lost its neighbor cache and signal that its neighbors should reregister their addresses. Since this is a Neighbor Discovery related issue, I think it makes sense to add some kind of sequence number option (similar to a DTSN) for NA messages. If a neighbor detects the sequence number has incremented, they can reregister their addresses. Best Regards, Chris. From: Klaus Hueske <klaus.hue...@renesas.com<mailto:klaus.hue...@renesas.com>> Sent: Thursday, May 12, 2022 4:56 AM To: 6lo@ietf.org<mailto:6lo@ietf.org> Cc: Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>>; Hett, Chris <chris.h...@landisgyr.com<mailto:chris.h...@landisgyr.com>>; Paul Duffy <padu...@cisco.com<mailto:padu...@cisco.com>> Subject: RE: [6lo] Router reboot - loss of state Hi Pascal, Thanks for pointing this out! Indeed, the problem is not limited to sleepy devices, but relevant for all nodes that expect address registration according to RFC6775 Section 3.3. The mechanism assumes that hosts actively register ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Pascal, Thanks for pointing this out! Indeed, the problem is not limited to sleepy devices, but relevant for all nodes that expect address registration according to RFC6775 Section 3.3. The mechanism assumes that hosts actively register their address with the router using NS with ARO and that the hosts are responsible for maintaining the registration depending on the configured lifetime. However, if the router is rebooted unexpectedly (e.g. due to a power outage) it will lose its neighbor cache information. This may not even be noticed by the connected hosts, so they will assume their address registration at the router is still okay, which is not the case. Considering the possible long registration lifetime, this would lead the connected nodes unreachable for a long period of time. The DTSN present in DIO messages can be used to refresh routing information by triggering DAO transmissions, but it will not trigger any address re-registration. What we need then is kind of an advertisement issued by the router after reboot that asks the connected hosts to send another NS with ARO to refresh their neighbor cache registration at the router. Probably this could be done by creating a dedicated option to be used in an unsolicited NA send to link local multicast after reboot. This option could be conceptually similar to the DTSN, just for ARO. The lack of such a feature has clearly been identified as a gap, especially when operating mains powered nodes in unstable grids. Hence, I'd prefer to extend the scope of the existing multicast draft to get this fixed as soon as possible. Happy to contribute to a new version of the draft if desired. Best regards, Klaus From: Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> Sent: Freitag, 6. Mai 2022 11:11 To: 6lo@ietf.org<mailto:6lo@ietf.org> Subject: [6lo] Router reboot - loss of state Dear all : There's one thing that was left unspecified in the RFC chain from RFC 6775, 8505, and 9010. That's the case where the 6LR reboots and the 6LN is not aware of the event, maybe it was sleeping. In that case the 6LR forgets the registration and the 6LN might become unreachable till it reregisters. A router that knows the event will happen goes could send a final RA but the 6LN might not hear it either, so the result is not deterministic. Anyway that does not cover the unintended reboot. Usually the L2 detects a loss of association or something, that triggers the 6LN to reparent. But that is not guaranteed to be available in all networks. RPL has a method, the DTSN in the DIO (https://datatracker.ietf.org/doc/html/rfc6550#section-6.3.1<https://urldefense.com/v3/__https:/jpn01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6550*23section-6.3.1&data=05*7C01*7Cklaus.hueske*40renesas.com*7Cc6095f0e524742e74d5108da2de3ab9f*7C53d82571da1947e49cb4625a166a4a2a*7C0*7C1*7C637872753125005927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=5PLxb2Vqb3sMtbjFx7onAM8eT1CP1Uqhf3Cc*2FmnpAEI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!EEzGOCEfvrF80k8sMoAmtYTD!Ij9D4FHBc4lj2Fedt1ezN7EOYbV-bYHbuEGX_DPRWVtrXiv0euhjwYv2zyTXlAfoCFRKo_V1shse3XKqov49jfVTzA$>). A new sequence indicates that the child that sees it needs to send its state, DAO in this case. The child will eventually see a DIO, and when it sees it, the child will know that the sequence was incremented. Though the text in RFC 6550 does not list all the cases when that is useful, a reboot in storing mode is certainly one. But this only requires resending DAO messages and has no effect on ND. https://datatracker.ietf.org/doc/html/draft-chakrabarti-nordmark-6man-efficient-nd-07#section-6.3<https://urldefense.com/v3/__https:/jpn01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-chakrabarti-nordmark-6man-efficient-nd-07*23section-6.3&data=05*7C01*7Cklaus.hueske*40renesas.com*7Cc6095f0e524742e74d5108da2de3ab9f*7C53d82571da1947e49cb4625a166a4a2a*7C0*7C1*7C637872753125005927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=7L53ZM1wt*2BMbYAZEoMPssWOBXiDpi9XlNjGBCx*2Bu2iY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!EEzGOCEfvrF80k8sMoAmtYTD!Ij9D4FHBc4lj2Fedt1ezN7EOYbV-bYHbuEGX_DPRWVtrXiv0euhjwYv2zyTXlAfoCFRKo_V1shse3XKqov7tUDMiQg$> has the same operation with a new RA option, the RAO, which also has a sequence counter, the router epoch; but the draft was stalled at 6MAN and the function is still missing. My suggestion is to fix that gap sooner than later. The fast path is to integrate the option in the multicast draft. The slow path is to make yet another RFC. What would you guys prefer? Keep safe Pascal Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
