Re: [Roll] Following up on seq Counter to protect the config option and others

Abdussalam Baryun <> Tue, 15 October 2019 07:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AE65120088 for <>; Tue, 15 Oct 2019 00:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zGdCHq-QfMwA for <>; Tue, 15 Oct 2019 00:29:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B11CF120013 for <>; Tue, 15 Oct 2019 00:29:29 -0700 (PDT)
Received: by with SMTP id k20so15945190oih.3 for <>; Tue, 15 Oct 2019 00:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=d1771cz1sVo3QEd7y/ifIeLIYddjOy9JQTJTHsOMPik=; b=qv004Lw0TdplOMKr5rSvFb5CkLrobo+4oBjzTDHwkLlT85t28UWejRkbvYezA8i7xS jb/M9L8NoTxqanmMY3YLW87rLuF6Xk5Kzuq1B+zHb/nskjxMAyG6ZidD0bUo4pDIpVtG jWp26wWX+EbdFtH0eBrhMhxEHoPnEDEqe+uoAZiNj4S4IwxjPDupP0yw156VoqMtPqZo oFhjDyf7TYN666YIsqPsHZC7khGvROk2Gg2u1Nj8CexSe1arFq4JhOsHbojM+rHCV3Gf WYwunVU5fdsnJhHsU4Ja/EQie7+Nh8x+KmnF5WRkHbQBKPTNFDwtlKMnvjwrP1Tjiucf zAmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=d1771cz1sVo3QEd7y/ifIeLIYddjOy9JQTJTHsOMPik=; b=qCkXiY2aIh2n9IdUjniPmbZcNdYxBPIIoVgpP67e0HsYWvUlAa4Oh00C+TLRgEwmsm MPoyifgZkoAHYqk3xdQUxkfSCwdviKWh25JshkWDArz1LjXecXjpi4q3LtAasHkxXhX3 lWA1OHVf/fo2Jur9+ZAYcZJygSWDIT2oq1xyW2/VSZgZSLjYLYf/w7C4SBm4llUcKgCf 0vli5cjJBIZjB+sS9cZRm/Ng/tTxw5XJU3x+R/unqL/oiNLmROt94oKoaY2FSh3k8g1W 9tnF5qSL7S94teeud5s9mIt2ZcFaA4TRIpFOH5k3ffn1BExB3r6ngvnzc0Qnv14uQVcO YmEA==
X-Gm-Message-State: APjAAAUEwe1Vy1e9qYFkHswzy5SPap6BXeVUPasMn3rQe/EkoxhV1pxs IgcHqxPWP6pm3zwU8p3ZUyRtL1o+dP+VcU89dS1QGA==
X-Google-Smtp-Source: APXvYqyigy2gaBl5YVtEk57ON3FtFyjc/d1/A1IaDhfPFwLAHhIx8y6Ap8axFrXpOrt9hVex1Dd9IB4ZAY6EtJ1KOZ4=
X-Received: by 2002:a05:6808:b31:: with SMTP id t17mr124659oij.52.1571124568832; Tue, 15 Oct 2019 00:29:28 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Abdussalam Baryun <>
Date: Tue, 15 Oct 2019 09:28:58 +0200
Message-ID: <>
To: Routing Over Low power and Lossy networks <>
Content-Type: multipart/alternative; boundary="000000000000d2c0540594edf17b"
Archived-At: <>
Subject: Re: [Roll] Following up on seq Counter to protect the config option and others
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: Tue, 15 Oct 2019 07:29:32 -0000

On Mon, Oct 14, 2019 at 6:57 PM Pascal Thubert (pthubert) <> wrote:

> Dear all :
> *   At the interim today we refined the idea of a Sequence counter in a
> DIO that increments when there is a change in a global option.*

Ok, but I think the incrimination to be different per different
changes  (changes possibilities with different increment number, so any
change case can be identified and corrected)

* For the lack of an acronym that results in SEAL, I’m using the RPL
> Configuration State Sequence (RCSS) for now. This concerns options that are
> fully set by the root and propagated unchanged. Seems that this means at
> this time:        1.  The Route Information Option (RIO)    2.  The Prefix
> Information Option (PIO)    3.  The DODAG Configuration Option (DCO)    4.
> The Extended MOP Option (MOPex)    5.  The Global Capabilities Option (GCO)
> *

options can be more or less depending on the LLN

> *  Note that this also means that the capabilities have to be split
> between the parent capabilities (not protected) and the network-wide that
> are (item 5 above). The alternate is that the RCSS covers everything a
> parent advertises in which case it is not set by the root but by individual
> parents.   Or do we need 2 counters? *

one counter per parent.