Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

Michael Richardson <> Fri, 21 February 2020 12:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 963E9120220; Fri, 21 Feb 2020 04:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RY3Q5t7Fi1iW; Fri, 21 Feb 2020 04:39:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD78212080D; Fri, 21 Feb 2020 04:39:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id DA9271F483; Fri, 21 Feb 2020 12:39:28 +0000 (UTC)
Received: by (Postfix, from userid 179) id 925CC1A3B74; Thu, 20 Feb 2020 19:34:41 +0100 (CET)
From: Michael Richardson <>
To: Alissa Cooper <>
cc: "The IESG" <>,,,,
In-reply-to: <>
References: <>
Comments: In-reply-to Alissa Cooper via Datatracker <> message dated "Wed, 19 Feb 2020 13:18:01 -0800."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 20 Feb 2020 19:34:41 +0100
Message-ID: <1950.1582223681@dooku>
Archived-At: <>
Subject: Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2020 12:39:33 -0000

Alissa Cooper via Datatracker <> wrote:
    > == Section 2 ==

    > "If this field is not present, then IID is derived from the layer-2
    > address of the sender as per SLAAC ({?RFC4662})."

    > RFC 8064 recommends that the default IID generation scheme for use with
    > SLAAC is not to use the layer-2 address, but to use the mechanism
    > specified in RFC 7217. Is there a reason this specification is making a
    > different recommendation?

We have this conversation pretty much every single time that 802.15.4 is discussed.

1) 6lowpan compression depends upon the layer-3 address being derived from
   the layer-2 address so that the usless bytes are not transmitted every
   single time.

2) however, 802.15.4 beacons are always sent using the 64-bit EUI64 L2 source
   addresses.  The device does not have to use IEEE OUI assigned addresses,
   but could use IEEE randomized MAC addresses if the firmware decides to do

3) 802.15.4 prefers to use assign 2-byte short addresses (and to derive the
   L3 address from that short-address).
   The recently approved 6tisch-minimal-security CoJP protocol includes
   assignment of 2-byte address using a central process.  As such, during
   normal operation neither the L2 and L3 addresses have manufacturer
   specific OUI content.

I believe that other documents have said this already, so I don't think there
needs to be any further repeating.  Let me know if you feel differently.

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > == Section 1.3 ==

    > This sentence is not comprehensible:

    > "Although However, even in this case, a unicast RS may be transmitted
    > in response[RFC6775] reduces the amount of multicast necessary to do
    > address resolution via Neighbor Solicitation (NS) messages, it still
    > requires multicast of either RAs or RS."

    > == Section 2 ==

    > s/({?RFC4662})/[RFC4862]

both already fixed.

    > == Section 4 ==

    > A network doesn't have privacy considerations. The draft might want to
    > discuss how this specification reveals information about network
    > topology, but that isn't a privacy consideration.

I think that every single draft should have privacy considerations.
If you have a LLN as part of your household automation, then being able to
map the extent of the LLN reveals which parts of the building belong to you.

If I had a house with many pieces (parking spot, storage in the basement,
etc) and I had active nodes in those places, I would want to consider whether
or not I want to use the same subnet (with backbone), or whether I'd want to
split things up.

    > DODAGID needs to be expanded on first use and needs a citation to be
    > provided.

DODAG was previously expanded. DODAG expands to DODAG-Identity.
I will cite RFC6550 here.

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

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