Looks like a great idea Michael. In an ideal world the Root would become a filtering Join Relay (think DHCP relay here).
This way we save complexity (no need for the JR to know who the JRV is), state in the network(no compression context needed), and bytes in the packet if IP in IP is used (with 6LoRH IP in IP the root is implicit, and we may define an implicit context for it in IPHC). Like in RFC 3048, this also means extra information for the relayed packets, so the JR can point on its local state of the pledge on the way back (if the root is JR it needs the addresses of the JP or a locally significant pointer to it). Are there security implications that do not foresee, like which of the JP and JR has an SA with the JRC vs end to end protection of the join response? Pascal Le 17 nov. 2017 à 02:10, Michael Richardson <[email protected]<mailto:[email protected]>> a écrit : Thomas Watteyne <[email protected]<mailto:[email protected]>> wrote: If there is no IPIP, then everything is easy. But, AFAICT, we want the JRC to be able to live on the Internet, i.e. not per se co-located with the DAGroot. In that case, the Join Request looks like any data packet sent by the JP to an IPv6 address outside the mesh, which triggers IPIP because the outer IP header contains the RPI. So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are collocated. BTW: another alternative is that the DAGroot can actually run a second Join Proxy pointing at the JRC, or being much more resourceful node, even a stateful proxy. -- Michael Richardson <[email protected]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
