[6lo] Shepherd review of draft-ietf-6lo-plc

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Mon, 03 August 2020 15:01 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7033A0B52; Mon, 3 Aug 2020 08:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.005
X-Spam-Level:
X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QAsL7EAB0Y1t; Mon, 3 Aug 2020 08:01:03 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FAB3A0B5F; Mon, 3 Aug 2020 08:01:01 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 073F0w1b011313; Mon, 3 Aug 2020 17:00:59 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D09391D53C1; Mon, 3 Aug 2020 17:00:58 +0200 (CEST)
Received: from 83.53.65.249 by webmail.entel.upc.edu with HTTP; Mon, 3 Aug 2020 17:00:58 +0200
Message-ID: <5af4c5b467e8c88af4adb50437b067af.squirrel@webmail.entel.upc.edu>
Date: Mon, 3 Aug 2020 17:00:58 +0200
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: draft-ietf-6lo-plc@ietf.org
Cc: 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Mon, 03 Aug 2020 17:00:59 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/fh6irchFWLICjJ8XGAge3VtIh2I>
Subject: [6lo] Shepherd review of draft-ietf-6lo-plc
X-BeenThere: 6lo@ietf.org
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." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 15:01:06 -0000

Dear draft-ietf-6lo-plc authors,

Thanks for your work on this document. I think that it is very readable.

Please find my shepherd review of the document at the end of this message.
My comments are shown as non-indented text.

Please update the draft taking into account this review. (Of course, feel
free to let me know if you disagree with, or further discussion is needed
for, any point.)

Cheers,

Carles


------------------------------------------------------------------------


  6Lo Working Group                                                 J. Hou
  Internet-Draft                                                    B. Liu
  Intended status: Standards Track                     Huawei Technologies
  Expires: December 5, 2020                                      Y-G. Hong
                                                                      ETRI
                                                                   X. Tang
                                                                    SGEPRI
                                                                C. Perkins
                                                              June 3, 2020


               Transmission of IPv6 Packets over PLC Networks
                           draft-ietf-6lo-plc-04

  Abstract

     Power Line Communication (PLC), namely using the electric-power lines
     for indoor and outdoor communications, has been widely applied to
     support Advanced Metering Infrastructure (AMI), especially smart
     meters for electricity.  The inherent advantage of existing
     electricity infrastructure facilitates the expansion of PLC
     deployments, and moreover, a wide variety of accessible devices
     raises the potential demand of IPv6 for future applications.  This
     document describes how IPv6 packets are transported over constrained
     PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2  .

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on December 5, 2020.

  Copyright Notice

     Copyright (c) 2020 IETF Trust and the persons identified as the
     document authors.  All rights reserved.


  Hou, et al.             Expires December 5, 2020                [Page 1]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Notation and Terminology . . . . . . . . . . . .   3
     3.  Overview of PLC . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Addressing Modes  . . . . . . . . . . . . . . . . . . . .   6
       3.3.  Maximum Transmission Unit . . . . . . . . . . . . . . . .   6
       3.4.  Routing Protocol  . . . . . . . . . . . . . . . . . . . .   7
     4.  IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Stateless Address Autoconfiguration . . . . . . . . . . .   7
       4.2.  IPv6 Link Local Address . . . . . . . . . . . . . . . . .   8
       4.3.  Unicast Address Mapping . . . . . . . . . . . . . . . . .   9
         4.3.1.  Unicast Address Mapping for IEEE 1901.1 . . . . . . .   9
         4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T
                 G.9903  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.4.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .  10
       4.5.  Header Compression  . . . . . . . . . . . . . . . . . . .  11
       4.6.  Fragmentation and Reassembly  . . . . . . . . . . . . . .  12
     5.  Internet Connectivity Scenarios and Topologies  . . . . . . .  12
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     7.  Security Consideration  . . . . . . . . . . . . . . . . . . .  15
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

  1.  Introduction

     The idea of using power lines for both electricity supply and
     communication can be traced back to the beginning of the last
     century.  With the advantage of existing power grid, Power Line
     Communication (PLC) is a good candidate for supporting various
     service scenarios such as in houses and offices, in trains and
     vehicles, in smart grid and advanced metering infrastructure (AMI).
     The data acquisition devices in these scenarios share common features




  Hou, et al.             Expires December 5, 2020                [Page 2]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     such as fixed position, large quantity, low data rate and low power
     consumption.

     Although PLC technology has evolved over several decades, it has not
     been fully adapted for IPv6 based constrained networks.  The 6lo
     related scenarios lie in the low voltage PLC networks with most
     applications in the area of Advanced Metering Infrastructure (AMI),
     Vehicle-to-Grid communications, in-home energy management and smart
     street lighting.  IPv6 is important for PLC networks, due to its
     large address space and efficent address auto-configuration.  A
     comparison among various existing PLC standards is provided to
     facilitate the selection of the most applicable standard in
     particular scenarios.

     This specification provides a brief overview of PLC technologies.
     Some of them have LLN characteristics, i.e. limited power

Just a weak suggestion: LLN is a recognized term in many domains.
Nevertheless, feel free to consider using "Constrained-Node Network (CNN)
(see RFC 7228).

     consumption, memory and processing resources.  This specification is
     focused on the transmission of IPv6 packets over those "constrained"
     PLC networks.  The general approach is to adapt elements of the
     6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to

6LoWPAN and 6lo specifications [RFC4944], [RFC6282], [RFC6775], [RFC8505]

     constrained PLC networks.  There was work previously proposed as
     [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], which did not
     reach consensus.  This document provides a more structured
     specification than the previous work, expanding to a larger variety
     of PLC networks.

  2.  Requirements Notation and Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     This document often uses the following acronyms and terminologies:

Remove "often"?

     6LoWPAN:  IPv6 over Low-Power Wireless Personal Area Network

     AMI:  Advanced Metering Infrastructure

     BBPLC:  Broadband Power Line Communication

     CID:  Context ID

     Coordinator:  A device capable of relaying messages.

     DAD:  Duplicate Address Detection




  Hou, et al.             Expires December 5, 2020                [Page 3]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     EV:   Electric Vehicle

     IID:  IPv6 Interface Identifier

     IPHC: IP Header Compression

     LAN:  Local Area Network

     MSDU: MAC Service Data Unit

     MTU:  Maximum Transmission Unit

     NBPLC:  Narrowband Power Line Communication

     OFDM: Orthogonal Frequency Division Multiplexing

     PANC: PAN Coordinator, a coordinator which also acts as the primary
           controller of a PAN.

     PLC:  Power Line Communication

     PLC device:  An entity follows the PLC standards and implements the
           protocol stack described in this draft.

s/An entity follows/An entity that follows

     PSDU: PHY Service Data Unit

     RPL:  IPv6 Routing Protocol for Low-Power and Lossy Networks

     RA:   Router Advertisement

     WAN:  Wide Area Network

        The terminology used in this draft is aligned with IEEE 1901.2

     +---------------+----------------+------------------+---------------+
     |  IEEE 1901.2  |  IEEE 1901.1   |   ITU-T G.9903   | This document |
     +---------------+----------------+------------------+---------------+
     |      PAN      |    Central     | PAN Coordinator  |      PAN      |
     |  Coordinator  |  Coordinator   |                  |  Coordinator  |
     |               |                |                  |               |
     |  Coordinator  |     Proxy      |  Full-function   |  Coordinator  |
     |               |  Coordinator   |      device      |               |
     |               |                |                  |               |
     |     Device    |    Station     |    PAN Device    |   PLC Device  |
     +---------------+----------------+------------------+---------------+

              Table 1: Terminology Mapping between PLC standards




  Hou, et al.             Expires December 5, 2020                [Page 4]
  
  Internet-Draft                IPv6 over PLC                    June 2020


  3.  Overview of PLC

     PLC technology enables convenient two-way communications for home
     users and utility companies to monitor and control electric plugged
     devices such as electricity meters and street lights.  Due to the
     large range of communication frequencies, PLC is generally classified
     into two categories: Narrowband PLC (NBPLC) for automation of sensors
     (which have low frequency band and low power cost), and Broadband PLC
     (BBPLC) for home and industry networking applications.

     Various standards have been addressed on the MAC and PHY layers for
     this communication technology, e.g., BBPLC (1.8-250 MHz) including
     IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T
     G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904
     (PRIME), IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME
     PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2) .

     Moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1],
     which aims at the medium frequency band less than 12 MHz, has been

frequency band of less than 12 MHz

     published by the IEEE standard for Smart Grid Powerline Communication
     Working Group (SGPLC WG).  IEEE 1901.1 balances the needs for
     bandwidth versus communication range, and is thus a promising option
     for 6lo applications.

     This specification is focused on IEEE 1901.1, IEEE 1901.2 and ITU-T
     G.9903.

  3.1.  Protocol Stack

     The protocol stack for IPv6 over PLC is illustrated in Figure 1.  The
     PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T
     G.9903.  The 6lo adaptation layer for PLC is illustrated in
     Section 4.  For multihop tree and mesh topologies, a routing protocol
     is likely to be necessary.  The routes can be built in mesh-under
     mode at layer 2 or in route-over mode at layer 3, as explained in
     Section 3.4.















  Hou, et al.             Expires December 5, 2020                [Page 5]
  
  Internet-Draft                IPv6 over PLC                    June 2020


                      +----------------------------------------+
                      |           Application Layer            |
                      +----------------------------------------+
                      |                TCP/UDP                 |
                      +----------------------------------------+
                      |                                        |
                      |                  IPv6                  |
                      |                                        |
                      +----------------------------------------+
                      |   Adaptation layer for IPv6 over PLC   |
                      +----------------------------------------+
                      |             PLC MAC Layer              |
                      +----------------------------------------+
                      |             PLC PHY Layer              |
                      +----------------------------------------+

                         Figure 1: PLC Protocol Stack

  3.2.  Addressing Modes

     Each PLC device has a globally unique long address of 48-bit
     ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short
     address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2],
     [ITU-T_G.9903]).  The long address is set by the manufacturer
     according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address.
     Each PLC device joins the network by using the long address and
     communicates with other devices by using the short address after
     joining the network.  Short addresses can be assigned during the
     onboarding process, by the PANC or the JRC in CoJP
     [I-D.ietf-6tisch-minimal-security].

Please expand the acronyms JRC and CoJP.


  3.3.  Maximum Transmission Unit

     The Maximum Transmission Unit (MTU) of the MAC layer determines
     whether fragmentation and reassembly are needed at the adaptation
     layer of IPv6 over PLC.  IPv6 requires an MTU of 1280 octets or
     greater; thus for a MAC layer with MTU lower than this limit,
     fragmentation and reassembly at the adaptation layer are required.

     The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets.
     The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the
     original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]).
     Though these two technologies can support IPv6 natively without
     fragmentation and reassembly, it is possible to configure a smaller
     MTU in high-noise communication environment.  Thus the 6lo functions,
     including header compression, fragmentation and reassembly, are still
     applicable and useful.




  Hou, et al.             Expires December 5, 2020                [Page 6]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting
     IPv6's MTU.  For this reason, fragmentation and reassembly as per
     [RFC4944] MUST be enabled for G.9903-based networks.

  3.4.  Routing Protocol

     Routing protocols suitable for use in PLC networks include:

     o  RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
        is a layer 3 routing protocol.  AODV-RPL [I-D.ietf-roll-aodv-rpl]
        updates RPL to include reactive, point-to-point, and asymmetric
        routing.  IEEE 1901.2 specifies Information Elements (IEs) with
        MAC layer metrics, which can be provided to L3 routing protocol
        for parent selection.  For IPv6-addressable PLC networks, a
        layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be
        supported in the standard.

Why "SHOULD"?  And if "SHOULD" is the right term here, perhaps add some
clarification on reasons or circumstances motivating using a protocol
different from RPL and/or AODV-RPL?

"in the standard". What does "the standard" refer to here?

     o  IEEE 1901.1 supports L2 routing.  Each PLC node maintains a L2
        routing table, in which each route entry comprises the short
        addresses of the destination and the related next hop.  The route
        entries are built during the network establishment via a pair of
        association request/confirmation messages.  The route entries can
        be changed via a pair of proxy change request/confirmation
        messages.  These association and proxy change messages MUST be
        approved by the central coordinator (PANC in this document).

Regarding the "MUST": is this behavior required by IEEE 1901.1 (i.e. there
is a "MUST" requirement level in IEEE 1901.1 for this?) If yes, then it is
not necessary to capitalize the "MUST" here.

     o  LOADng is a reactive protocol operating at layer 2 or layer 3.
        Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and
        the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based
        networks.

  4.  IPv6 over PLC

     6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful

6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and [RFC8505]
provide useful...

     functionality including link-local IPv6 addresses, stateless address
     auto-configuration, neighbor discovery and header compression.

Add "fragmentation and reassembly".

     However, due to the different characteristics of the PLC media, the
     6LoWPAN adaptation layer cannot perfectly fulfill the requirements.

the 6LoWPAN adaptation layer, as it is, cannot perfectly fulfill the
requirements of PLC environments.

     These considerations suggest the need for a dedicated adaptation
     layer for PLC, which is detailed in the following subsections.

4.1.  Stateless Address Autoconfiguration

     To obtain an IPv6 Interface Identifier (IID), a PLC device performs
     stateless address autoconfiguration [RFC4944].  The autoconfiguration
     can be based on either a long or short link-layer address.





  Hou, et al.             Expires December 5, 2020                [Page 7]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     The IID can be based on the device's 48-bit MAC address or its EUI-64
     identifier [EUI-64].  A 48-bit MAC address MUST first be extended to

Reference [EUI-64] is missing in the "References" section.

     a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth
     octets as specified in [RFC2464].  The IPv6 IID is derived from the
     64-bit Interface ID by inverting the U/L bit [RFC4291].

     For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed
     by the 16-bit PAN ID, 16 zero bits and the 16-bit short address.
     Then, the 64-bit Interface ID MUST be derived by inserting 16-bit
     0xFFFE into as follows:

         16_bit_PAN:00FF:FE00:16_bit_short_address

     For the 12-bit short addresses used by IEEE 1901.1, the 48-bit
     pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY),
     12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX).
     The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE
     into this 48-bit pseudo-address as follows:

         YYYY:YYFF:FE00:0XXX

     Since the derived Interface ID is not global, the "Universal/Local"
     (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both
     be set to zero.  In order to avoid any ambiguity in the derived
     Interface ID, these two bits MUST NOT be used to generate the PANID
     (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1).  In
     other words, the PANID or NID MUST always be chosen so that these
     bits are zeros.

     For privacy reasons, the IID derived by the MAC address SHOULD only
     be used for link-local address configuration.  A PLC host SHOULD use
     the IID derived by the link-layer short address to configure the IPv6
     address used for communication with the public network; otherwise,
     the host's MAC address is exposed.  Implementations should look at
     [RFC8064] as well, in order to generate a stable IPv6 address using
     an opaque IID.

derived "by" or "derived from" ?

s/Implementations/Implementers


  4.2.  IPv6 Link Local Address

     The IPv6 link-local address [RFC4291] for a PLC interface is formed
     by appending the IID, as defined above, to the prefix FE80::/64 (see
     Figure 2).









  Hou, et al.             Expires December 5, 2020                [Page 8]
  
  Internet-Draft                IPv6 over PLC                    June 2020


         10 bits           54 bits                   64 bits
       +----------+-----------------------+----------------------------+
       |1111111010|        (zeros)        |    Interface Identifier    |
       +----------+-----------------------+----------------------------+

             Figure 2: IPv6 Link Local Address for a PLC interface

  4.3.  Unicast Address Mapping

     The address resolution procedure for mapping IPv6 unicast addresses
     into PLC link-layer addresses follows the general description in
     section 7.2 of [RFC4861].  [RFC6775] improves this procedure by
     eliminating usage of multicast NS.  The resolution is realized by the
     NCEs (neighbor cache entry) created during the address registration
     at the routers.  [RFC8505] further improves the registration
     procedure by enabling multiple LLNs to form an IPv6 subnet, and by
     inserting a link-local address registration to better serve proxy
     registration of new devices.

  4.3.1.  Unicast Address Mapping for IEEE 1901.1

     The Source/Target Link-layer Address options for IEEE_1901.1 used in
     the Neighbor Solicitation and Neighbor Advertisement have the
     following form.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length=1   |              NID              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :NID (continued)|  Padding (all zeros)  |          TEI          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Unicast Address Mapping for IEEE 1901.1

     Option fields:

     Type: 1 for Source Link-layer Address and 2 for Target Link-layer
           Address.

     Length:  The length of this option (including type and length fields)
           in units of 8 octets.  The value of this field is 1 for the
           12-bit IEEE 1901.1 PLC short addresses.

     NID:  24-bit Network IDentifier

     Padding:  12 zero bits




  Hou, et al.             Expires December 5, 2020                [Page 9]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     TEI:  12-bit Terminal Equipment Identifier

     In order to avoid the possibility of duplicated IPv6 addresses, the
     value of the NID MUST be chosen so that the 7th and 8th bits of the
     first byte of the NID are both zero.

  4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903

     The Source/Target Link-layer Address options for IEEE_1901.2 and
     ITU-T G.9903 used in the Neighbor Solicitation and Neighbor
     Advertisement have the following form.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length=1   |             PAN ID            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Padding (all zeros)     |         Short Address         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: Unicast Address Mapping for IEEE 1901.2

     Option fields:

     Type: 1 for Source Link-layer Address and 2 for Target Link-layer
           Address.

     Length:  The length of this option (including type and length fields)
           in units of 8 octets.  The value of this field is 1 for the
           16-bit IEEE 1901.2 PLC short addresses.

     PAN ID:  16-bit PAN IDentifier

     Padding:  16 zero bits

     Short Address:  16-bit short address

     In order to avoid the possibility of duplicated IPv6 addresses, the
     value of the PAN ID MUST be chosen so that the 7th and 8th bits of
     the first byte of the PAN ID are both zero.

  4.4.  Neighbor Discovery

     Neighbor discovery procedures for 6LoWPAN networks are described in
     Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505].
     These optimizations support the registration of sleeping hosts.
     Although PLC devices are electrically powered, sleeping mode SHOULD
     still be used for power saving.



  Hou, et al.             Expires December 5, 2020               [Page 10]
  
  Internet-Draft                IPv6 over PLC                    June 2020


     For IPv6 address prefix dissemination, Router Solicitations (RS) and
     Router Advertisements (RA) MAY be used as per [RFC6775].  If the PLC
     network uses route-over mesh, the IPv6 prefix MAY be disseminated by

remove "mesh"

     the layer 3 routing protocol, such as RPL which includes the prefix

such as RPL, which may include

     in the DIO message.  As per [I-D.ietf-roll-unaware-leaves], it is
     possible to have PLC devices configured as RPL-unaware-leaves, which
     don't not participate to RPL at all, along with RPL-aware PLC

s/don't not/do not

     devices.  In this case, the prefix dissemination SHOULD use the RS/RA
     messages.

I understand that the route-over routing protocol is not specified, right?
I.e. this document supports any route-over routing protocol. If yes, then
you may want to use more generic terms, such as "If the route-over routing
protocol does not support prefix dissemination", which replaces "In this
case".

     For context information dissemination, Router Advertisements (RA)
     MUST be used as per [RFC6775].  The 6LoWPAN context option (6CO) MUST
     be included in the RA to disseminate the Context IDs used for prefix
     compression.

s/prefix compression/prefix and/or address compression

     For address registration in route-over mode, a PLC device MUST
     register its addresses by sending unicast link-local Neighbor
     Solicitation to the 6LR.  If the registered address is link-local,
     the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR).
     Otherwise, the address MUST be registered via an ARO or EARO included
     in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages.  For RFC8505
     compliant PLC devices, the 'R' flag in the EARO MUST be set when
     sending Neighbor Solicitaitons in order to extract the status
     information in the replied Neighbor Advertisements from the 6LR.  If
     DHCPv6 is used to assign addresses or the IPv6 address is derived by

derived "from"?

     unique long or short link layer address, Duplicate Address Detection
     (DAD) MUST NOT be utilized.  Otherwise, the DAD MUST be performed at
     the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as
     per [RFC8505]).  The registration status is feedbacked via the DAC or
     EDAC message from the 6LBR and the Neighbor Advertisement (NA) from
     the 6LR.

     For address registration in mesh-under mode, since all the PLC
     devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/

s/are the link-local/are link-local

     EDAC messages are not required.  A PLC device MUST register its
     addresses by sending the unicast NS message with an ARO or EARO.  The

s/the unicast/a unicast

     registration status is feedbacked via the NA message from the 6LBR.

  4.5.  Header Compression

     The compression of IPv6 datagrams within PLC MAC frames refers to
     [RFC6282], which updates [RFC4944].  Header compression as defined in
     [RFC6282] which specifies the compression format for IPv6 datagrams
     on top of IEEE 802.15.4, is included in this document as the basis

s/is included in this document as the basis/is the basis

     for IPv6 header compression in PLC.  For situations when PLC MAC MTU
     cannot support the 1280-octet IPv6 packet, headers MUST be compressed
     according to [RFC6282] encoding formats.

IEEE 1901.1 supports 12-bit and 48-bit addresses. Header compression over
IEEE 1901.1 will need some form of adaptation, since RFC 6282 refers to
16-bit and 64-bit addresses.


  Hou, et al.             Expires December 5, 2020               [Page 11]
  
  Internet-Draft                IPv6 over PLC                    June 2020


  4.6.  Fragmentation and Reassembly

     PLC differs from other wired technologies in that the communication
     medium is not shielded; thus, to successfully transmit data through
     power lines, PLC Data Link layer provides the function of
     segmentation and reassembly.  A Segment Control Field is defined in
     the MAC frame header regardless of whether segmentation is required.
     The number of data octets of the PHY payload can change dynamically
     based on channel conditions, thus the MAC payload segmentation in the
     MAC sublayer is enabled and guarantees a reliable one-hop data
     transmission.  Fragmentation and reassembly is still required at the
     adaptation layer, if the MAC layer cannot support the minimum MTU
     demanded by IPv6, which is 1280 octets.

     In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as
     big as 2031 octets and 1576 octets respectively.  However when the
     channel condition is noisy, it is possible to configure smaller MTU
     at the MAC layer.  If the configured MTU is smaller than 1280
     octects, the fragmentation and reassembly defined in [RFC4944] MUST
     be used.

     In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets,
     so to cope with the required MTU of 1280 octets by IPv6,
     fragmentation and reassembly at 6lo adaptation layer MUST be provided
     referring to [RFC4944].

  5.  Internet Connectivity Scenarios and Topologies

   The network model can be simplified to two kinds of network devices:

s/The network model/The PLC network model

   PAN Coordinator (PANC) and PAN Device.  The PANC is the primary
   coordinator of the PLC subnet and can be seen as a master node; PAN
   Devices are typically PLC meters and sensors.  The PANC also serves
   as the Routing Registrar for proxy registration and DAD procedures,
   making use of the updated registration procedures in [RFC8505].  IPv6
   over PLC networks are built as tree, mesh or star according to the
   use cases.  Every network requires at least one PANC to communicate
   with each PAN Device.

The last sentence was unclear. Who/What communicates with each PAN Device?

                         Note that the PLC topologies in this section
   are based on logical connectivity, not physical links.

   The star topology is common in current PLC scenarios.  In single-hop
   star topologies, communication at the link layer only takes place
   between a PAN Device and a PANC.  The PANC typically collects data
   (e.g., a meter reading) from the PAN devices, and then concentrates
   and uploads the data through Ethernet or LPWAN (see Figure 5).  The
   collected data is transmitted by the smart meters through PLC,
   aggregated by a concentrator, sent to the utility and then to a Meter
   Data Management System for data storage, analysis and billing.  This




  Hou, et al.             Expires December 5, 2020               [Page 12]
  
  Internet-Draft                IPv6 over PLC                    June 2020


   topology has been widely applied in the deployment of smart meters,
   especially in apartment buildings.

                   PLC Device   PLC Device
                         \        /           +---------
                          \      /           /
                           \    /           +
                            \  /            |
          PLC Device ------ PANC ===========+  Internet
                            /  \            |
                           /    \           +
                          /      \           \
                         /        \           +---------
                   PLC Device   PLC Device

                <---------------------->
               PLC subnet (IPv6 over PLC)

           Figure 5: PLC Star Network connected to the Internet

   A tree topology is useful when the distance between a device A and
   PANC is beyond the PLC allowed limit and there is another device B in
   between able to communicate with both sides.  Device B in this case
   acts both as a PAN Device and a Coordinator.  For this scenario, the
   link layer communications take place between device A and device B,
   and between device B and PANC.  An example of PLC tree network is
   depicted in Figure 6.  This topology can be applied in the smart
   street lighting, where the lights adjust the brightness to reduce
   energy consumption while sensors are deployed on the street lights to
   provide information such as light intensity, temperature, humidity.
   Data transmission distance in the street lighting scenario is
   normally above several kilometers thus the PLC tree network is
   required.  A more sophisticated AMI network may also be constructed
   into the tree topology which is depicted in [RFC8036].  A tree
   topology is suitable for AMI scenarios that require large coverage
   but low density, e.g., the deployment of smart meters in rural areas.
   RPL is suitable for maintenance of a tree topology in which there is
   no need for communication directly between PAN devices.













  Hou, et al.             Expires December 5, 2020               [Page 13]
  
  Internet-Draft                IPv6 over PLC                    June 2020


                          PLC Device
                               \                   +---------
                  PLC Device    \                 /
                       \         \               +
                        \         \              |
                   PLC Device -- PANC ===========+  Internet
                        /         /              |
                       /         /               +
      PLC Device---PLC Device   /                 \
                               /                   +---------
              PLC Device---PLC Device

            <------------------------->
            PLC subnet (IPv6 over PLC)

           Figure 6: PLC Tree Network connected to the Internet

   Mesh networking in PLC is of great potential applications and has
   been studied for several years.  By connecting all nodes with their
   neighbors in communication range (see Figure 7), mesh topology
   dramatically enhances the communication efficiency and thus expands
   the size of PLC networks.  A simple use case is the smart home
   scenario where the ON/OFF state of air conditioning is controlled by
   the state of home lights (ON/OFF) and doors (OPEN/CLOSE).  AODV-RPL
   enables direct PAN device to PAN device communication, without being
   obliged to transmit frames through the PANC, which is a requirement
   often cited for AMI infrastructure.

                PLC Device---PLC Device
                    / \        / \                   +---------
                   /   \      /   \                 /
                  /     \    /     \               +
                 /       \  /       \              |
          PLC Device--PLC Device---PANC ===========+  Internet
                 \       /  \       /              |
                  \     /    \     /               +
                   \   /      \   /                 \
                    \ /        \ /                   +---------
                PLC Device---PLC Device

        <------------------------------->
            PLC subnet (IPv6 over PLC)

           Figure 7: PLC Mesh Network connected to the Internet


What is the subnet model for the scenarios illustrated in this section?
For example, is the "PLC subnet" a multilink subnet? Is each link in the
"PLC subnet" a subnet?

Perhaps this text from RFC 7668 may be useful for reference:

   "In the Bluetooth LE case, the benefits of treating
   the collection of point-to-point links between a central and its
   connected peripherals as a single multilink subnet rather than a
   multiplicity of separate subnets are considered to outweigh the
   multilink model's drawbacks as described in [RFC4903]."


  Hou, et al.             Expires December 5, 2020               [Page 14]
  
  Internet-Draft                IPv6 over PLC                    June 2020


  6.  IANA Considerations

   There are no IANA considerations related to this document.

  7.  Security Consideration

   Due to the high accessibility of power grid, PLC might be susceptible
   to eavesdropping within its communication coverage, e.g., one
   apartment tenant may have the chance to monitor the other smart
   meters in the same apartment building.  For security consideration,
   link layer security is guaranteed in every PLC technology.

   Malicious PLC devices could paralyze the whole network via DOS
   attacks, e.g., keep joining and leaving the network frequently, or
   multicast routing messages containing fake metrics.  A device may
   also join a wrong or even malicious network, exposing its data to
   illegal users.  Mutual authentication of network and new device can
   be conducted during the onboarding process of the new device.
   Methods include protocols such as [RFC7925] (exchanging pre-installed
   certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which
   uses pre-shared keys), and
   [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and
   MASA service).  It is also possible to use EAP methods such as
   [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191].  No
   specific mechanism is specified by this document as an appropriate
   mechanism will depend upon deployment circumstances.  The network
   encryption key appropriate for the layer-2 can also be acquired
   during the onboarding process.

   IP addresses may be used to track devices on the Internet; such
   devices can in turn be linked to individuals and their activities.
   Depending on the application and the actual use pattern, this may be
   undesirable.  To impede tracking, globally unique and non-changing
   characteristics of IP addresses should be avoided, e.g., by
   frequently changing the global prefix and avoiding unique link-layer
   derived IIDs in addresses.  [RFC3315], [RFC3972], [RFC4941],
   [RFC5535], [RFC7217], and [RFC8065] provide valuable information for
   IID formation with improved privacy, and are RECOMMENDED for IPv6
   networks.