[Int-dir] Intdir telechat review of draft-ietf-6lo-plc-06

[Dave Thaler via Datatracker <[e-mail]>]

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 https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

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.

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.

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.

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.

I also have some editorial nits that can be found in a marked up copy at
https://www.microsoft.com/en-us/research/uploads/prod/2021/08/draft-ietf-6lo-plc-06.pdf

Dave