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

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Oct 2016 12:13:06 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Oct 2016 09:49:27 -0400

to reply to myself

Michael Richardson <[email-masked]> wrote:
    > 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.

I realized today that the RA probably also needs to carry the ABRO to be
useful to secured hosts.  Such hosts will still have to unicast as RS to get
the PIO from a router.  I'm sure that we don't want to put the PIO into an
unencrypted EB/RA.

The ARBO has the 6LBR address which is often, but not always the same as the
DODAGID.   It can equally well be used to identify the network.

    > probably on the order of ten bytes of zeroes.

So far, the savings I got with GHC was 4 bytes.  I posted an update to the
git repo.  (     https://github.com/ietf-roll/6lo-ra-in-ie )

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 25 Oct 2016 00:44:16 +0200

Michael,

Cool! Some editorial remarks:

OLD
extended beacon
NEW
enhanced beacon

Could the draft be generic enough to allow for RPL DIOs to be carried in an
EB?

On Wed, Oct 19, 2016 at 3:49 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________