On Tue, Jul 17, 2018 at 10:25 PM Tero Kivinen <[email protected]> wrote:
> If JRC restarts and looses track who is in the network, then it cannot > send updaes, as it does not know who is in the network. I.e., in that > case all nodes need to rejoin. > How do we detect that JRC restarted at 6LBR if JRC is in the Cloud? I guess we need to assume that the JRC knows the address of 6LBR upon restart and can contact it, but this is then related to the issue Jim Schaad raised on reuse of Partial IVs on the application layer. If JRC rekeys *only* the 6LBR who starts using the new key for all outgoing traffic, all the nodes in the network will fall out of sync which will force them to rejoin, obtain new key and new short addresses. Seems to be sufficient? > > On the other hand if JRC wants to clean up some address space, for > example if it has given out lots of short address without expirity > time, and then it cannot take those address back to use ever even if > the node has already been silent for few weeks. In that case if it > does the rekey of the network then after the old keys are no longer in > use anywhere it can start reusing the short addresses for those nodes, > it did not send key update for. > So I guess this would be equivalent to the case of expelling a node from the network, i.e. rekeying everyone but that node. > It cannot use the fact that node did not ack the key update sent to it > to indicate that node has gone from the network, as it is possible > that the ack got lost, even when the key update actually reached the > node. So it needs to have list of nodes it will send key updates, and > those it does not send it, are something it can remove from the > address pool after the key update. > Agreed.
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
