Hi Malisa and Tero, Thanks for answering my question! It is clear to me!
I don't fully understand. Do you mean in which case would a node send > another Join Request, if it has already completed the join process sometime > before and obtained the L2 encryption keys? > My question is exactly what you rephrased :-) Tengfei On Tue, Jul 17, 2018 at 1:24 PM, Tero Kivinen <kivi...@iki.fi> wrote: > Mališa Vučinić writes: > > Hence I have two questions: > > 1. in what case JRC or some entity will send such packet? > > > > For example if a JRC detects that some node in the network > > misbehaves, generates large amount of traffic, is misconfigured or > > similar. The JRC would then simply need to rekey the network, > > providing the new key to every node except the one that it wants to > > see expelled. > > > > Then, Tero on another thread also mentioned a couple of cases where > > this is necessary, e.g. if JRC restarts. > > 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. > > 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. > > 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. > -- > kivi...@iki.fi > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
