Re: [6tisch-security] Short address assignment

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    >> Do you think we should slip the PANID in with the short-address
    >> assignment?

    > What do you mean by that?

I mean, should the JRC set the PANID at the same time as it sets the
short-address.  This provides the option for the join network to be in a
different PANID than the production network, (yes, requires two sets of
beacons, etc.), but also perhaps provides for changing the PANID at the
next rekey.

    >> We have not explained how the pledge knows about PANIDs: clearly it
    >> could just use whatever PANID the beacons it hears contain. Do you
    >> think we need to be more explicit?

    > When device searches for network it will listen beacons, and when it
    > hears beacons it will pick one and set its macPanId to match for that
    > and join that network. Device can only be part of one PAN at the same
    > time, i.e. it can only receive frames which are directed to its
    > macPanId value (or broadcast PAN ID). It can send frames to other PANs
    > by providing both source and destination PAN.

Right: this is the implicit PANID set.  The new device assumes it should use
the PANID that it hears.

    > Each short address is associated with exactly one PAN, i.e., the PAN of
    > the coordinator who gave it out.

    >> Perhaps we should at least put it in the yang model such that it read
    >> back?

    > Could be useful if we at one point want to have networks crossing
    > multiple PANs.

    >> I have included an inception date for the short-address for this
    >> reason as well. I called it "effectiveat", but maybe there is a better
    >> name.

    > Looks ok to me.

Thanks.

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