Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> a écrit :


Thomas Watteyne <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
-= IPv6 IoT consulting =-