[6tisch-security] transporting Router Advertisements in Extended Beacons: draft-richardson-6lo-ra-in-ie

[Michael Richardson <[e-mail]>]

Hi, as detailed in the design team minutes at:
   https://mailarchive.ietf.org/arch/msg/6tisch-security/QI671AgUjY2t4nMKSWc7SPn5PjA

The design team has come to realize that there would be significant time and
energy savings if we could embed an IPv6 Router Advertisement into the
802.15.4 TSCH Enhanced Beacon used by 6tisch to synchronize timing, and
announce the schedule.

I did an initial draft at:
  https://datatracker.ietf.org/doc/draft-richardson-6lo-ra-in-ie/

at the cost of 1-2 bytes, it just uses 6282/6loRH compression to store any
IPv6 packet, but we may want to lock this down more.  The total content is
56 bytes, which just barely fits into a Beacon. (uncompressed it is 80 bytes,
which will not fit)

This is very very much -00!!!  Comments and co-authors welcome, github at:
     https://github.com/ietf-roll/6lo-ra-in-ie

Much more "why" text is needed, and how to use the components is needed.
I don't know if this should be a 6lo or 6tisch work effort; I leave it to the
chairs to think about this.

Unless I mis-read 6282, it provides no compression of ICMPv6 headers,
nor does 6loRH do so at present.  I know that Pascal had talked about coming
back in 6loRH v2, using the new code page space, to compressing RPL (which is
ICMPv6).

I went slightly further afield in this document, and defined a new Router
Advertisement option that I called:
              "Constrained Network Identification"

This will contain a copy of the 16-byte DODAGID so that a very sleepy node
returning to operation would be able to identify which beacon belongs to
which network.  A joining node will have no idea which DODAGID it
wants, and a maliciously sent beacon could have any manner is superfuge here.
Nodes which have already joined the network SHOULD be able to authenticate
the beacons.  However, this is one of the larger objects in the 56 bytes that
I describe, and maybe it is excessive to store so many bytes here.

It could be that the SLLA option (and EUI-64 contained within) is also
unnecessary.

I want to attempt to apply RFC7400 (GHC) to this, the savings will be
probably on the order of ten bytes of zeroes.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-