Re: [Roll] UNaware leaves (3)

Michael Richardson <> Thu, 29 August 2019 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A827A1200D6 for <>; Thu, 29 Aug 2019 16:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zh2iVBBXDuve for <>; Thu, 29 Aug 2019 16:57:13 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F34D120059 for <>; Thu, 29 Aug 2019 16:57:13 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 3EBE33808A for <>; Thu, 29 Aug 2019 19:56:00 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 707EDD8C for <>; Thu, 29 Aug 2019 19:57:11 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 29 Aug 2019 19:57:11 -0400
Message-ID: <23546.1567123031@localhost>
Archived-At: <>
Subject: Re: [Roll] UNaware leaves (3)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Aug 2019 23:57:16 -0000

Pascal Thubert (pthubert) <> wrote:
    >> Should this specification extend 6tisch-minimal (CoJP) to include a way to set
    >> the InstanceID?

    > Possible, you're welcome to propose text and chat with Minimal co
    > authors on the 6TiSCH ML : ).

Actually, we created a "Constrained Join Protocol Parameters Registry"
parameters.  This document can allocate a value from it :-)

    > Pls keep in mind that over a same L2 network a node may participate to
    > more than one instance, so a list would be needed. Also that minimal
    > provisions L2 and now it would be provisioning L3.

    > There's a limit to what we want to provision with AAA
    > vs. management. The cool thing with management is that it is common to
    > several security mechanisms.

I don't think we need a list on CoJP.
A RAL that participated in multiple L2 networks would probably need to do
multiple joins to get the network keys for each, and it would have to have
enough RAM/Flash/etc. to keep track of the different keys, and also instanceID.

    >> o  A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a
    >> 6LN acting as a RAN SHOULD NOT set the 'R' flag.
    >> wouldn't a 6LN acting as a RAN be a 6LR Leaf, and therefore not a 6LN?
    >> Maybe we need another term here.

    > Anything connected to a 6LoWPAN network is a 6LN. A 6LN is a Node, that
    > is a host or a router.  A 6LR is a 6LN with additional capabilities. We
    > do not have a term for a 6LoWPAN plain host (like a 6LH) but as far as
    > RPL is concerned a RUL is good enough.

I think that a 6LoWPAN plain host (I like 6LH), is a RPL-unware-leaf (RUL)
We have just created the RPL-Aware-Leaf (RAL), and we'd like it to become the
status quo, right?

Oh, I think I'm confused on terms.  I'll have to come back and read it again.

    >> Not putting it in means the adjacent 6LR has to IPIP it, address it to the RPL
    >> Root.
    >> If we put it in, then in the storing case, no further IPIP is needed!!

    > Agreed. But that means a change in the RUL s. RFC 8505. That's a MAY at best.

I think that it's the killer-app part of this work.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-