Malisa Vucinic <[email protected]> wrote: >>> Option 2 leverages the DTLS implementation that is in any case >>> mandated by CoAP so it does not necessitate much additional >>> implementation effort, other than the JA relay application. Another >>> advantage here is >> >> So there are several options here, one of which has the JN as a >> client, a different one would have the JN as a responder. There is >> additionally a question of whether the DTLS Client/Server direction >> needs to match the the CoAP direction. I think there is a significant >> need to permit the JCE to manage the order and bandwidth from the join >> process.
> So, the idea in case JN is a DTLS client was that JCE can simply wait
> with the response to ClientHello, according to its policy and different
The JN would have to get some kind of ACK so that it can stop retransmitting.
Just waiting on the reponse to ClientHello won't work.
In draft-richardson-6tisch--security-6top-04, I suggested that the JN would
join a special DODAG just for joining nodes, and the presents of the JN's
serialNumber in the (E)ARO ND DAD that needs to be sent would signal to the
JCE that it exists. This piggybacks upon a transaction which already
happens (no new code, no new state, no additional transactions), is
acknowledged on a hop-by-hop basis, but is not end-to-end.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
