[6tisch-security] 6lo-ra-in-ie becoming

[Michael Richardson <[e-mail]>]

{6lo is CC'ed to close this question up, but Reply-To: set to 6tisch, as
there isn't anything that is not 6tisch specific left at this point}

I have just posted: draft-richardson-6tisch-join-enhanced-beacon
  https://datatracker.ietf.org/doc/draft-richardson-6tisch-join-enhanced-beacon/

The diff isn't very interesting, as it's mostly a forklift upgrade.
This is the result of ongoing discussion to make the zero-touch and one-touch
join processes work together, and to achieve a level of interoperation such
that a zero-touch capable device, which has received a one-touch, could
actually recognize that it needs to do zero-touch.

Further, we are trying to accomodate both one-touch and zero-touch bootstrap
using both pledge initiated communications (the one-touch preference), and
Join Registrar/Coordinator initiated communications.  The network shall know
which way it will operate, and the network will announce this in the proposed
enhanced beacon. (ENHANCED. I hope I stamped out all the occurances of that
other E-word, which I will not write here)

This text could go into 6tisch-minimal-security, or it could be a seperate
document.   It would have been nice to put it into 6tisch-minimal; but I
sure hope that ship has sailed.  Maybe it should Update that?

The R flag is for host-operation of nodes which would otherwise want to
listen for a multicast Router-Advertisement, or initiate one with a multicast
RS.  It is hard for me to construct a scenario where the R bit would be zero,
and yet the device is alive enough that it thinks it ought to send beacons.
It could be that some networks do not wish to support attachment of leaf
nodes to all routers though.  {previous paragraph probably belongs in document?}


The core is:

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   TBD-XXX     |J|I|R| R E S V |         network ID            |
    +-+-+-+-+-+-+-+-+-+-+-+---------+                               |
    |                           network ID                          |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      network ID               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

J
: the Join Proxy flag is set if the sending node will operate as a Join Proxy
according to {{I-D.ietf-6tisch-minimal-security}}.

I
: the Initiate Join flag is set if this network supports pledges initiating the
join process themselves according to {{I-D.ietf-6tisch-minimal-security}}. If not set, then the pledge
should do an NS DAD operation ({{RFC6775}} section 4.3, explained in {{I-D.ietf-6tisch-dtsecurity-secure-join}}) and then remain silent, to wait to be contacted.

R
: the Router Advertisement flag is set if the sending node will act as a Router for host-only nodes that need addressing via unicast Router Solicitation messages.

network ID
: this is an opaque 16-byte identifier that uniquely identifies this network,
potentially among many networks that are operating in the same frequencies
in overlapping physical space.

In a 6tisch network, where RPL is used as the mesh routing protocol, the
network ID SHOULD be constructed from a SHA256 hash of the DODAGID of the
network.  The result will be a 32-byte hash, and the lower 16-bytes should be
used.


{oh. I show only 8 bytes of network-ID in the picture. Oops. I will grow the
diagram}




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