Re: [6lo] Intdir telechat review of draft-ietf-6lo-plc-06

"Liubing (Remy)" <> Tue, 31 August 2021 01:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B670C3A2AAE; Mon, 30 Aug 2021 18:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dNu40EVlxkIe; Mon, 30 Aug 2021 18:33:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E6803A2AAC; Mon, 30 Aug 2021 18:33:04 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Gz8mD4SBSz67FBw; Tue, 31 Aug 2021 09:31:24 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 31 Aug 2021 03:33:00 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 31 Aug 2021 09:32:58 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Tue, 31 Aug 2021 09:32:58 +0800
From: "Liubing (Remy)" <>
To: Dave Thaler <>, "" <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Intdir telechat review of draft-ietf-6lo-plc-06
Thread-Index: AdeaLH6f+W9ga8xIQze7l97xe1eBFA==
Date: Tue, 31 Aug 2021 01:32:58 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [6lo] Intdir telechat review of draft-ietf-6lo-plc-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Aug 2021 01:33:10 -0000

Hello Dave,

Many thanks to your comments. It helps a lot. We will include the modifications in the next version.

Please see our feedback below.

Best regards,

发件人: Dave Thaler via Datatracker [] 
发送时间: 2021年8月7日 10:03
主题: Intdir telechat review of draft-ietf-6lo-plc-06

Reviewer: Dave Thaler
Review result: Almost Ready

I am an assigned INT directorate reviewer for draft-ietf-6lo-plc-06.txt. These comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see

Overall I found the document to be fairly well written and understandable. 
There were a couple of areas though where I think additional elaboration is needed.

Technical comments:

1) Page 8 talks about "the" IPv6 address used for communication with the public network, implying there can only be one at a time.  This is not normal in IPv6, where you can have a public address, the current temporary address, and the previous temporary address (to allow for transition to a new one), all at the
same time.   Should this be changed to be plural?  If not, how do you support
privacy addresses in IPv6?  What about cases where you have external connectivity to two public networks each with its own prefix?  I don't see this answered anywhere in the doc.
[Remy] You're right about that. Actually we don't prevent to have multiple IPv6 addresses at the same time. We will change it to plural.

2) Page 8 also mentions that a shared secret "or" version number can be used in a hash to derive an IID, but never defines any hash details.  To me, that implies that this document currently does not provide any guarantee of interoperability, in which case why do you need an IETF RFC at all if every device has to come from the same vendor with an algorithm not specified in the
standard?   I expected this document to specify the details of a hash algorithm
that must be implemented.
[Remy] That's a good suggestion. We suggest to use SHA256 as the hash algorithm, and the version number, the PANID/NID and the short address as the input arguments. Then the 256 bits hash output is truncated by taking the high 64 bits.

3) RFC 8065 explains that privacy of IPv6 link-local addresses is typically uninteresting because on broadcast media all devices can see all the link-layer
addresses and mappings anyway.   At least in the star and tree topologies, I
suspect this is not the case.   However the document doesn't seem to contain
any discussion of the privacy considerations in such a case.
[Remy] The different topologies don't require additional considerations. The topology of the PLC network is decided by the link condition and distance between the devices. Only if a device can hear from another and the link condition is good enough, the two devices are "linked". In star and tree topology, a device may be able to hear a part of the network. For this partition of the network, the privacy of IPv6 link-local addresses is uninteresting. For the rest of the network, the link layer address and IPv6 link local address is not visible to this specific device.

4) RFC 8065 section 4 provides a checklist of what adaptation layer documents like this need to address. I'd recommend addressing each point separately in the Security Considerations section, so it's clear that the draft addresses the whole checklist.  For example, there's nothing in the document that mentions what the typical link lifetime is (years maybe?) As another example, it's really hard to tell from reading the last paragraph of section 4.5 of this draft how it addresses RFC 8065's statement that "any specification using Short Addresses should carefully construct an IID generation mechanism so as to provide sufficient entropy compared to the link lifetime" so elaboration here is warranted here in my opinion.
[Remy] Consider a PLC network with 1024 devices and its link lifetime is 8 years, according to the formula in RFC8065, an entropy of 40 bits is sufficient. Padding the short address (12 or 16 bits) to generate the IID of a routable IPv6 address in the public network may be vulnerable to deal with address scans. Thus As explained in the comment #2, a hash function can be used to generate a 64 bits IID. When the version number of the PLC network is changed, the IPv6 addresses can be changed as well. In another way, the IPv6 addresses can be assigned and changed via DHCP. In a normal situation, a PLC device doesn't "roam". The device leaves the network first and joins in another. And the short address and the IPv6 address should change during this process.

I also have some editorial nits that can be found in a marked up copy at