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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 02 March 2020 08:46 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907203A1004; Mon, 2 Mar 2020 00:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cx/dDwRw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JJWeKXGj
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hod45in14W9E; Mon, 2 Mar 2020 00:46:11 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B36B3A1002; Mon, 2 Mar 2020 00:46:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5598; q=dns/txt; s=iport; t=1583138771; x=1584348371; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MminhNzcVAiAFsHnzda8pvGtDKjmJLmD0b04ASh0yyA=; b=cx/dDwRwEQwOsmsSbaDmxgAo7fIZAvU9OhxMAnn7BbkhhD7kA/wOWimb r9+zGxMe7hOMCXqrECBdg2e8fSfDEX2WcI6exuPKFyjYiStRer4WU9f97 u4iKvoc4NGFxDnDIJF2xQhQ+nDb7kMZf7dPLYUGTiTxZKxB3hURuSmHHx M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AB1wTXhyKRLHyuafXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBQBpxlxe/5hdJa1dCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gVRQBWxYIAQLKgqHUAOKZoJfgQGXFIFCgRADVAkBAQEMAQE?= =?us-ascii?q?fDgIEAQGBTIJ0AoILJDgTAgMNAQEFAQEBAgEFBG2FVgyFYwEBAQEDEi4BATc?= =?us-ascii?q?BCwQCAQgRBAEBASMLMh0IAgQBDQUIGoMFgkoDLgEDn3UCgTmIYoIngn8BAQW?= =?us-ascii?q?FEBiCDAmBOIUghwUagUE/gRFHghg1PoQfEgQYg0GCLI1wFolYmEEKgjySNIR?= =?us-ascii?q?OgkmIH5BJg0+LI4FNmX0CBAIEBQIOAQEFgWkigVhwFYMnCUcYDYRXiUYJAxc?= =?us-ascii?q?VgmdUilV0gSmNaoEyAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.70,506,1574121600"; d="scan'208";a="463890386"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Mar 2020 08:46:10 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0228kAX0002897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2020 08:46:10 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 02:46:10 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 02:46:09 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 2 Mar 2020 03:46:08 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DQfntoNcUFAH45oYKWf5nCydrPOlNLj48ugjG7CvgIeHntYVNer4uuZM3c/RGC?= =?utf-8?q?1OeQnAoJ1jHLroXAwEWDP97kQa5KMW221ZTB1AkbBZIgAB29NWUq/PUN4mrZ6DIjS?= =?utf-8?q?l0bNk0SgXNFRTQqZWpXLrZyYDc9IzXprer1+6yL4rMnQrZcO4rkGnqlsWDxslJJPL?= =?utf-8?q?wfr+xKVgkgBFe3WMYx85hiQWJf2Wq15BMoKPwMWY0WtkGTjYE9kzsO2ManzTF+8PV?= =?utf-8?q?JwKBrroOF/P9e8SSKU3/drvbk0GP4At833ATBCIrExZA0NYBDz0xXss+bII/Y3kiv?= =?utf-8?q?VAOVgghf5s4cLAF5Dlg1g=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DyT6blLtD223TjjGJ9XeF2Q6HDDwePQHKXbWG0JHs9Pk=3D=3B_b=3DLC1bFw?= =?utf-8?q?4V0YdxFrGSKCZNGYXIONoIY7IUUIRkmxqTB+kaO764tXi1nTSiQ9yMO7UZg4aRCQ9?= =?utf-8?q?qs4sXhvJQVb0+5ZpyrI4yJjs9jCQ2I6XilFHsOFafvSt3KqNvR4zkoUjZg9DM5bMN?= =?utf-8?q?AE4hXoHbgg5Tlpn28eqOO2LVIsYU6cBIXjr/OmJi8ynZ7/ZghOLNvhRi03adPQYhd?= =?utf-8?q?leRfh6FDzOozYmkw+RcvQxqF9WAvObKCQtsZZV/ph4SaNhvGk5acpQk4IYJz4wjl+?= =?utf-8?q?tbu8gIF63xpJdj0ErPF6tyr4vDwfajH4kgq3+HvE4SxetjoKS0qwqmztMhU6Ys/TD?= =?utf-8?q?KcGDQOD1ORA=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DyT6blLtD223TjjGJ9XeF2Q6HDDwePQHKXbWG0JHs9Pk=3D=3B_b?= =?utf-8?q?=3DJJWeKXGjlbvZwAQOZf3GVNV4q77nybrqQyPLN2U1/pMh01bKQKigWWNdWw0v+n?= =?utf-8?q?Msv7GZdA8/LDs8iZKWXDZfPIe5EKoTgtmSoMckhEtqSjEkhXTMX6N7NWVzHYteyZv?= =?utf-8?q?NSN8k5mzF9YWxM7gEE2jouEU+yEO4eLiThxSC5UfEutg=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4158.namprd11.prod.outlook.com (2603:10b6:208:155::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.16; Mon, 2 Mar 2020 08:46:08 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24%6]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 08:46:08 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Alissa Cooper <alissa@cooperw.in>
CC: The IESG <iesg@ietf.org>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org" <draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org>
Thread-Topic: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
Thread-Index: AQHV52oZ3ikhZoNTRE+qTjnyVXwIhqgkaf+AgBCd0wA=
Date: Mon, 2 Mar 2020 08:46:03 +0000
Deferred-Delivery: Mon, 2 Mar 2020 08:45:37 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB3565044A01124E3774C38DB1D8E70=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158214708113.17592.6654776663880425456.idtracker@ietfa.amsl.com> <1950.1582223681@dooku>
In-Reply-To: <1950.1582223681@dooku>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2.15.172.153]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ccd91c5-aecf-4fea-1de4-08d7be8626b2
x-ms-traffictypediagnostic: MN2PR11MB4158:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB41584D930E8E280B79495D2AD8E?= =?utf-8?q?70=40MN2PR11MB4158=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNDYwMDIpKDM5NjAwMykoMzc2MDAyKSgzOTg2MDQwMDAwMikoMzY2?= =?utf-8?b?MDA0KSgxMzYwMDMpKDE4OTAwMykoMTk5MDA0KSgxMTAxMzYwMDUpKDc2OTYwMDUp?= =?utf-8?b?KDY2NTc0MDEyKSg4NjM2MjAwMSkoNjUwNjAwNykoOTY2MDA1KSgyOTA2MDAyKSg1?= =?utf-8?q?3546011=29=2871200400001=29=288936002=29=2881166006=29=2881156014?= =?utf-8?b?KSg4Njc2MDAyKSg2NjY2MDA0KSgzMTYwMDIpKDU0OTA2MDAzKSg1NjYwMzAw?= =?utf-8?b?MDAyKSgxODYwMDMpKDUyNTM2MDE0KSg2Njk0NjAwNykoNzYxMTYwMDYpKDY0?= =?utf-8?q?756008=29=2866476007=29=2866556008=29=2866446008=29=2833656002=29?= =?utf-8?b?KDI2MDA1KSg5Njg2MDAzKSg1NTAxNjAwMikoNDc4NjAwMDAxKSg0MzI2MDA4KTs=?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4158; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?YhwcWTp7ttME0gfD+y7bar4kT/dyrRk?= =?utf-8?q?Nx/LI15A8rM3E2oJi5n4HELoCNl+hHO0c187APnoJShNF+VkU3bxYj3aSwdgSN93g?= =?utf-8?q?vzv7MTChBeF+VxkS8cAl44YnSaUAFlepgmNCfHhzRhHzLxCJFx96vw45GRayJdh6L?= =?utf-8?q?r74cLmpqaw1oFKauKyHD4OlPjbVyJ3fp8VFO4AndXx02Sp9R2wA6JVjUpRa0a+vcW?= =?utf-8?q?yBXSd03fsTuK4LOpOXpli+sGxBMtCvajITe7NYBACToyI4Jz148ViQlm5vrPh9Lmt?= =?utf-8?q?9g9L+8Xvw8ASOCpi67bjDqiVilP4FJUm8DsGWBDmAFkM+F8yyGPxXrme0yLo/M4p6?= =?utf-8?q?FFhWp66WGjr3qLCQHOCNsdSdtCfXbcI46A+xtfeUILaDX3eB5s2NbFleeAGmZweCA?= =?utf-8?q?Z/rJhFptl7sizxHxdqZbMGhcoDfh230t3jf4GsW9nt8Mgl9oQ2Om8fcu3wXKQd3xs?= =?utf-8?q?F0kZDJ1vv/SxOwVnhXdU8g6LwqJZFkHtge89ORUuLofAopyw=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?Pz/Buu95hKjDjJ1w/Xsrpw58P/tg/M?= =?utf-8?q?A7AHEI2KdFVsq+uUhz7oJEm4203v8WhZa3IBEW9uubehxezW1CrISzezrb//+2gd1?= =?utf-8?q?fNjyBuOGM73g1VpnC8d7KCILIXYn53MDAd4QYFdq/zjOR8Jl97+oRZQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ccd91c5-aecf-4fea-1de4-08d7be8626b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 08:46:07.8437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?ETYeMNd3FejMyv/rA3JEA?= =?utf-8?q?GrbUIJKYy285PmyhhZKPHcubQ0vt/OsHJciCqzsNnt8BJhPhYM6MkVsHTpfJ7xS9w?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4158
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/udzHkoIH_sfPdj9Yp_xImm8QVhA>
Subject: Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 08:46:14 -0000

Hello Alissa and Michael

(chair hat on)

Please keep in mind that this draft does not have vocation to update RFC 4944. 6TiSCH does not have that vocation either. If something was needed, it would belong to 6lo. 
Arguably the art of 6LoWPAN allows a node to apply RFC 8064/8065 if it likes. I expect it will become more common as larger MTUs arise. 

Using short addresses and deriving IPv6 addresses from them is how RFC 4944 enabled IPv6 in some environments where it was not applied before (because IPv6 was deemed impossible with a MTU of 127 bytes or below).  IEEE std 802.15.4 short addresses can be renewed, which will cause the IPv6 addresses that are derived from them will change too. If short addresses are chosen pseudo-randomly and renewed periodically, privacy can be improved at the expense of complexity, a trade off that each use case will have to make.

As most of the 6TiSCH standard track work, this draft operates at the interface between IETF and IEEE. A spec that modifies IEEE beacons is probably not the best place to discuss address allocation.
The draft does not make a "recommendation" on which mechanism to use, it  just enables to signal which of the existing mechanisms is used. 

All in all, I believe that the DISCUSS should be removed; point taken to discuss this more at 6lo, though.

Take care,

Pascal


> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: jeudi 20 février 2020 19:35
> To: Alissa Cooper <alissa@cooperw.in>
> Cc: The IESG <iesg@ietf.org>rg>; Pascal Thubert (pthubert)
> <pthubert@cisco.com>om>; 6tisch-chairs@ietf.org; 6tisch@ietf.org; draft-ietf-
> 6tisch-enrollment-enhanced-beacon@ietf.org
> Subject: Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-
> enhanced-beacon-13: (with DISCUSS and COMMENT)
> 
> 
> Alissa Cooper via Datatracker <noreply@ietf.org> 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?
> 
> Yes.
> 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
>    this.
> 
> 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  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>