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> Sent: Freitag, 6. Mai 2022 11:11 To: 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://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>). 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://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> 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
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
