\
[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-hou-6lo-plc)  00 01 02 03 04 05         Standards Track
          06 07 08 09 10 11                                             
6Lo Working Group                                                 J. Hou
Internet-Draft                                                    B. Liu
Intended status: Standards Track                     Huawei Technologies
Expires: November 18, 2022                                     Y-G. Hong
                                                      Daejeon University
                                                                 X. Tang
                                                                  SGEPRI
                                                              C. Perkins
                                                             Lupin Lodge
                                                            May 17, 2022


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

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 existing electricity infrastructure
   facilitates the expansion of PLC deployments due to its potential
   advantages in terms of cost and convenience.  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 November 18, 2022.







Hou, et al.             Expires November 18, 2022               [Page 1]


Internet-Draft                IPv6 over PLC                     May 2022


Copyright Notice

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

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   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 . . . . . . . . . . .   8
     4.2.  IPv6 Link Local Address . . . . . . . . . . . . . . . . .   9
     4.3.  Unicast Address Mapping . . . . . . . . . . . . . . . . .   9
       4.3.1.  Unicast Address Mapping for IEEE 1901.1 . . . . . . .  10
       4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T
               G.9903  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Neighbor Discovery  . . . . . . . . . . . . . . . . . . .  11
     4.5.  Header Compression  . . . . . . . . . . . . . . . . . . .  12
     4.6.  Fragmentation and Reassembly  . . . . . . . . . . . . . .  13
   5.  Internet Connectivity Scenarios and Topologies  . . . . . . .  14
   6.  Operations and Manageability Considerations . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23








Hou, et al.             Expires November 18, 2022               [Page 2]


Internet-Draft                IPv6 over PLC                     May 2022


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.  Using the existing power grid to transmit messages, 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)
   [SCENA].  The data acquisition devices in these scenarios share
   common features 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
   resource-constrained IoT-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 efficient address auto-
   configuration.

   This document provides a brief overview of PLC technologies.  Some of
   them have LLN (low power and lossy network) characteristics, i.e.,
   limited power consumption, memory and processing resources.  This
   document specifies the transmission of IPv6 packets over those
   "constrained" PLC networks.  The general approach is to adapt
   elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area
   Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes)
   specifications, such as [RFC4944], [RFC6282], [RFC6775] and [RFC8505]
   to constrained 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 uses the following acronyms and terminologies:

   6BBR: 6LoWPAN Backbone Router

   6LBR: 6LoWPAN Border Router

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

   6lo:  IPv6 over Networks of Resource-constrained Nodes



Hou, et al.             Expires November 18, 2022               [Page 3]


Internet-Draft                IPv6 over PLC                     May 2022


   6LR:  6LoWPAN Router

   AMI:  Advanced Metering Infrastructure

   BBPLC:  Broadband Power Line Communication

   Coordinator:  A device capable of relaying messages

   DAD:  Duplicate Address Detection

   IID:  IPv6 Interface Identifier

   LLN:  Low power and Lossy Network

   MTU:  Maximum Transmission Unit

   NBPLC:  Narrowband Power Line Communication

   PAN:  Personal Area Network

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

   PLC:  Power Line Communication

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

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

   RA:   Router Advertisement

    Below is a mapping table of the terminology between [IEEE_1901.2],
             [IEEE_1901.1], [ITU-T_G.9903] and this document.

   +---------------+----------------+------------------+---------------+
   |  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 November 18, 2022               [Page 4]


Internet-Draft                IPv6 over PLC                     May 2022


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.  PLC can also
   be used in smart home scenarios, such as the control of indoor lights
   and switches.  Due to the large range of communication frequencies,
   PLC is generally classified into two categories: Narrowband PLC
   (NBPLC) for automation of sensors (which have a 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] (a combination of G3-PLC and PRIME
   PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2).

   A new PLC standard IEEE 1901.1 [IEEE_1901.1], which is aimed at the
   medium frequency band of less than 12 MHz, has been 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 November 18, 2022               [Page 5]


Internet-Draft                IPv6 over PLC                     May 2022


                    +----------------------------------------+
                    |           Application Layer            |
                    +----------------------------------------+
                    |            Transport Layer             |
                    +----------------------------------------+
                    |                                        |
                    |                  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-bits
   ([IEEE_1901.1]) or 64-bits ([IEEE_1901.2], [ITU-T_G.9903]) and a
   short address of 12-bits ([IEEE_1901.1]) or 16-bits ([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 (join registrar/
   coordinator) in CoJP (Constrained Join Protocol)
   [I-D.ietf-6tisch-minimal-security].

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 an MTU of 1576 octets (the
   original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]).
   Though these two technologies can support IPv6 originally 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 November 18, 2022               [Page 6]


Internet-Draft                IPv6 over PLC                     May 2022


   The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting
   IPv6's MTU.  For this reason, fragmentation and reassembly is
   required for G.9903-based networks to carry IPv6.

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.

   o  IEEE 1901.1 supports the mesh-under routing scheme.  Each PLC node
      maintains a 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).

   o  LOADng (The Lightweight On-demand Ad hoc Distance vector routing
      protocol, Next Generation) 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

   A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based
   on the equivalent of a EtherType in a layer-2 PLC PDU.  [RFC7973]
   defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this
   information can be carried in the IE field in the MAC header of
   [IEEE_1901.2] or [ITU-T_G.9903].  And regarding [IEEE_1901.1], the IP
   packet type has been defined with the corresponding MAC Service Data
   Unit (MSDU) type value 49.  And the 4-bit Internet Protocol version
   number in the IP header helps to distinguish between an IPv4 PDU and
   an IPv6 PDU.

   6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and
   [RFC8505] provide useful functionality including link-local IPv6
   addresses, stateless address auto-configuration, neighbor discovery,
   header compression, fragmentation, and reassembly.  However, due to
   the different characteristics of the PLC media, the 6LoWPAN



Hou, et al.             Expires November 18, 2022               [Page 7]


Internet-Draft                IPv6 over PLC                     May 2022


   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.

   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
   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 as
   follows:

       16_bit_PAN:0000: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) as
   follows:

       YYYY:YY00:0XXX

   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

   As investigated in [RFC7136], besides [RFC4291], some other IID
   generation methods defined in IETF do not imply any semantics for the
   "Universal/Local" (U/L) bit (bit 6) and the Individual/Group bit (bit
   7), so that these two bits are not reliable indicators for their
   original meanings.  Thus when using an IID derived by a short
   address, the operators of the PLC network can choose to comply with
   original meaning of these two bits or not.  If so, since the IID
   derived from the short address is not global, these two bits MUST



Hou, et al.             Expires November 18, 2022               [Page 8]


Internet-Draft                IPv6 over PLC                     May 2022


   both be set to zero.  In order to avoid any ambiguity in the derived
   Interface ID, these two bits MUST NOT be a valid part of the PANID
   (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1).  For
   example, the PANID or NID must always be chosen so that the two bits
   are zeros; or the high 6 bits in PANID or NID are left shifted by 2
   bits.  If not, the operator must be aware that these two bits are not
   reliable indicators, and the IID cannot be transformed back into a
   short link layer address via a reverse operation of the mechanism
   presented above.  However, the short address can still be obtained
   via the Unicast Address Mapping mechanism in Section 4.3.

   For privacy reasons, the IID derived from the MAC address (with
   padding and bit clamping) SHOULD only be used for link-local address
   configuration.  A PLC host SHOULD use the IID derived from the link-
   layer short address to configure IPv6 addresses used for
   communication with the public network; otherwise, the host's MAC
   address is exposed.  As per [RFC8065], when short addresses are used
   on PLC links, a shared secret key or version number from the
   Authoritative Border Router Option [RFC6775] can be used to improve
   the entropy of the hash input, thus the generated IID can be spread
   out to the full range of the IID address space while stateless
   address compression is still allowed.  The hash algorithm by default
   of the implementations SHOULD be SHA256, using the version number,
   the PANID/NID and the short address as the input arguments, and the
   256-bits hash output is truncated into the IID by taking the high 64
   bits.

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).

       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



Hou, et al.             Expires November 18, 2022               [Page 9]


Internet-Draft                IPv6 over PLC                     May 2022


   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

   TEI:  12-bit Terminal Equipment Identifier

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.











Hou, et al.             Expires November 18, 2022              [Page 10]


Internet-Draft                IPv6 over PLC                     May 2022


      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

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.

   For IPv6 prefix dissemination, Router Solicitations (RS) and Router
   Advertisements (RA) MAY be used as per [RFC6775].  If the PLC network
   uses route-over, the IPv6 prefix MAY be disseminated by the layer-3
   routing protocol, such as RPL, which may include the prefix in the
   DIO (DODAG Information Object) message.  As per [RFC9010], it is
   possible to have PLC devices configured as RPL-unaware-leaves, which
   do not participate in RPL at all, along with RPL-aware PLC devices.
   In this case, the prefix dissemination SHOULD use the RS/RA messages.

   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
   and/or address compression.





Hou, et al.             Expires November 18, 2022              [Page 11]


Internet-Draft                IPv6 over PLC                     May 2022


   For address registration in route-over mode, a PLC device MUST
   register its addresses by sending a 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 Solicitations 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
   from unique long or short link layer address, Duplicate Address
   Detection (DAD) SHOULD 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 fed back
   via the DAC or EDAC message from the 6LBR and the Neighbor
   Advertisement (NA) from the 6LR.  The section 6 of [RFC8505] how
   RFC6775-only devices work with RFC8505-updated devices.

   For address registration in mesh-under mode, since all the PLC
   devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC
   messages are not required.  A PLC device MUST register its addresses
   by sending a unicast NS message with an ARO or EARO.  The
   registration status is fed back 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 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, including the Dispatch Header, the LOWPAN_IPHC and
   the compression residu carried in-line.

   For IEEE 1901.2 and G.9903, the IP header compression follows the
   instruction in [RFC6282].  However, additional adaptation MUST be
   considered for IEEE 1901.1 since it has a short address of 12 bits
   instead of 16 bits.  The only modification is the semantics of the
   "Source Address Mode" and the "Destination Address Mode" when set as
   "10" in the section 3.1 of [RFC6282], which is illustrated as
   following.

   SAM: Source Address Mode:

   If SAC=0: Stateless compression





Hou, et al.             Expires November 18, 2022              [Page 12]


Internet-Draft                IPv6 over PLC                     May 2022


   10:   16 bits.  The first 112 bits of the address are elided.  The
         value of the first 64 bits is the link-local prefix padded with
         zeros.  The following 64 bits are 0000:00ff:fe00:0XXX, where
         0XXX are the 16 bits carried in-line, in which the first 4 bits
         are zero.

   If SAC=1: stateful context-based compression

   10:   16 bits.  The address is derived using context information and
         the 16 bits carried in-line.  Bits covered by context
         information are always used.  Any IID bits not covered by
         context information are taken directly from their corresponding
         bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX,
         where 0XXX are the 16 bits carried in-line, in which the first
         4 bits are zero.  Any remaining bits are zero.

   DAM: Destination Address Mode:

   If M=0 and DAC=0: Stateless compression

   10:   16 bits.  The first 112 bits of the address are elided.  The
         value of the first 64 bits is the link-local prefix padded with
         zeros.  The following 64 bits are 0000:00ff: fe00:0XXX, where
         0XXX are the 16 bits carried in-line, in which the first 4 bits
         are zero.

   If M=0 and DAC=1: stateful context-based compression

   10:   16 bits.  The address is derived using context information and
         the 16 bits carried in-line.  Bits covered by context
         information are always used.  Any IID bits not covered by
         context information are taken directly from their corresponding
         bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX,
         where 0XXX are the 16 bits carried in- line, in which the first
         4 bits are zero.  Any remaining bits are zero.

4.6.  Fragmentation and Reassembly

   The constrained PLC MAC layer provides the function of fragmentation
   and reassembly.  However, 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, smaller packets have higher transmission
   success rate, the operator can choose to configure smaller MTU at the




Hou, et al.             Expires November 18, 2022              [Page 13]


Internet-Draft                IPv6 over PLC                     May 2022


   MAC layer.  If the configured MTU is smaller than 1280 octets, 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 the 6lo adaptation layer MUST be
   provided as specified in [RFC4944].

   [RFC4944] uses a 16-bit datagram tag to identify the fragments of the
   same IP packet.  [RFC4963] specifies that at high data rates, the
   16-bit IP identification field is not large enough to prevent
   frequent incorrectly assembled IP fragments.  For constrained PLC,
   the data rate is much lower than the situation mentioned in RFC4963,
   thus the 16-bit tag is sufficient to assemble the fragments
   correctly.

5.  Internet Connectivity Scenarios and Topologies

   The PLC network model can be simplified to two kinds of network
   device: PAN Coordinator (PANC) and PLC Device.  The PANC is the
   primary coordinator of the PLC subnet and can be seen as a primary
   node; PLC Devices are typically PLC meters and sensors.  The address
   registration and DAD features can also be deployed on the PANC, for
   example the 6LBR [RFC6775] or the routing registrar in [RFC8505].
   IPv6 over PLC networks are built as trees, meshes or stars topology
   according to the use cases.  Generally, each PLC network has one
   PANC.  In some cases, the PLC network can have alternate coordinators
   to replace the PANC when the PANC leaves the network for some reason.
   Note that the PLC topologies in this section are based on logical
   connectivity, not physical links.  The term "PLC subnet" refers to a
   multilink subnet, in which the PLC devices share the same address
   prefix.

   The star topology is common in current PLC scenarios.  In single-hop
   star topologies, communication at the link layer only takes place
   between a PLC Device and a PANC.  The PANC typically collects data
   (e.g., a meter reading) from the PLC devices, and then concentrates
   and uploads the data through Ethernet or Cellular networks (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 topology has been widely applied in the deployment of
   smart meters, especially in apartment buildings.








Hou, et al.             Expires November 18, 2022              [Page 14]


Internet-Draft                IPv6 over PLC                     May 2022


                   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
   the 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 PLC 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 a PLC tree network
   is depicted in Figure 6.  This topology can be applied in 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, and
   humidity.  The data transmission distance in the street lighting
   scenario is normally above several kilometers, thus a 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 November 18, 2022              [Page 15]


Internet-Draft                IPv6 over PLC                     May 2022


                          PLC Device
                               \                   +---------
               PLC Device A     \                 /
                       \         \               +
                        \         \              |
                 PLC Device B -- 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), a 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
   ([I-D.ietf-roll-aodv-rpl]) enables direct PLC device to PLC 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







Hou, et al.             Expires November 18, 2022              [Page 16]


Internet-Draft                IPv6 over PLC                     May 2022


6.  Operations and Manageability Considerations

   The constrained PLC networks are not managed in the same way as an
   enterprise network or a carrier network.  Constrained PLC networks,
   like the other IoT networks, are designed to be self-organized and
   self-managed.  The software or firmware is flashed into the devices
   before deployment by the vendor or operator.  And during the
   deployment process, the devices are bootstrapped, and no extra
   configuration is needed to get the devices connected to each other.
   Once a device becomes offline, it goes back to the bootstrapping
   stage and tries to rejoin the network.  The onboarding status of the
   devices and the topology of the PLC network can be visualized via the
   PANC.  The recently-formed iotops WG in IETF is aiming to identify
   the requirements in IoT network management, and operational practices
   will be published.  Developers and operators of PLC networks should
   be able to learn operational experiences from this WG.

7.  IANA Considerations

   There are no IANA considerations related to this document.

8.  Security Considerations

   Due to the high accessibility of power grids, 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.  Link layer security
   mechanisms, such as payload encryption and devcie authentication, are
   designed in the PLC technologies mentioned in this document.
   Additionally, on-path malicious PLC device could eavesdrop or modify
   packets sent through it if appropriate confidentiality and integrity
   mechanisms are not implemented.

   Malicious PLC devices could paralyze the whole network via DOS
   attacks, e.g., keep joining and leaving the network frequently, or
   sending multicast routing messages containing fake metrics.  A device
   may also inadvertently join a wrong or even malicious network,
   exposing its data to malicious users.  When communicating with a
   device outside the PLC network, the traffic has to go through the
   PANC.  Thus the PANC must be a trusted entity.  Moreover, the PLC
   network must prevent malicious devices to join in the network.  Thus
   Mutual authentication of a PLC network and a new device is important,
   and it 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] (a IoT version of BRSKI,
   which uses IDevID and MASA service to facilitate authentication).  It



Hou, et al.             Expires November 18, 2022              [Page 17]


Internet-Draft                IPv6 over PLC                     May 2022


   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.  In some cases, the PLC devices can be
   deployed in uncontrolled places, where the devices may be accessed
   physically and be compromised via key extraction.  Since the
   compromised device may be still able to join in the network since its
   credentials are still valid.  When group-shared symmetric keys are
   used in the network, the consequence is even more severe, i.e., the
   whole network or a large part of the network is at risk.  Thus in
   scenarios where the physical attacks is considered to be relatively
   highly possible, per device credentials SHOULD be used.  Moreover,
   additional end-to-end security services" is a complementary to the
   network side security mechanisms, e.g., if a devices is compromised
   and it has joined in the network, and then it claims itself as the
   PANC and try to make the rest devices join its network.  In this
   situation, the real PANC can send an alarm to the operator to
   acknowledge the risk.  Other behavior analysis mechanisms can be
   deployed to recoginize the malicious PLC devices by inspecting the
   packets and the data.

   IP addresses may be used to track devices on the Internet; such
   devices can often 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.  [RFC8065] discusses the privacy
   threats when interface identifiers (IID) are generated without
   sufficient entropy, including correlation of activities over time,
   location tracking, device-specific vulnerability exploitation, and
   address scanning.  And an effective way to deal with these threats is
   to have enough entropy in the IID compairing to the link lifetime.
   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 suggest in the
   section 4.1, 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.  Other schemes such as limited
   lease period in DHCPv6 [RFC8415], Cryptographically Generated
   Addresses (CGAs) [RFC3972], Temporary Address Extensions [RFC8981],
   Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque
   addresses [RFC7217] SHOULD be used to enhance the IID privacy.






Hou, et al.             Expires November 18, 2022              [Page 18]


Internet-Draft                IPv6 over PLC                     May 2022


9.  Acknowledgements

   We gratefully acknowledge suggestions from the members of the IETF
   6lo working group.  Great thanks to Samita Chakrabarti and Gabriel
   Montenegro for their feedback and support in connecting the IEEE and
   ITU-T sides.  The authors thank Scott Mansfield, Ralph Droms, and Pat
   Kinney for their guidance in the liaison process.  The authors wish
   to thank Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu, and
   Michael Richardson for their valuable comments and contributions.

10.  References

10.1.  Normative References

   [IEEE_1901.1]
              IEEE-SA Standards Board, "Standard for Medium Frequency
              (less than 15 MHz) Power Line Communications for Smart
              Grid Applications", IEEE 1901.1, May 2018,
              <https://ieeexplore.ieee.org/document/8360785>.

   [IEEE_1901.2]
              IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
              (less than 500 kHz) Narrowband Power Line Communications
              for Smart Grid Applications", IEEE 1901.2, October 2013,
              <https://standards.ieee.org/findstds/
              standard/1901.2-2013.html>.

   [ITU-T_G.9903]
              International Telecommunication Union, "Narrowband
              orthogonal frequency division multiplexing power line
              communication transceivers for G3-PLC networks",
              ITU-T G.9903, August 2017,
              <https://www.itu.int/rec/T-REC-G.9903>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <https://www.rfc-editor.org/info/rfc2464>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.





Hou, et al.             Expires November 18, 2022              [Page 19]


Internet-Draft                IPv6 over PLC                     May 2022


   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <https://www.rfc-editor.org/info/rfc7136>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

10.2.  Informative References

   [EUI-64]   IEEE-SA Standards Board, "Guidelines for 64-bit Global
              Identifier (EUI-64) Registration Authority", IEEE EUI-64,
              March 1997, <https://standards.ieee.org/content/dam/ieee-
              standards/standards/web/documents/tutorials/eui.pdf>.



Hou, et al.             Expires November 18, 2022              [Page 20]


Internet-Draft                IPv6 over PLC                     May 2022


   [I-D.ietf-6tisch-dtsecurity-zerotouch-join]
              Richardson, M., "6tisch Zero-Touch Secure Join protocol",
              draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
              progress), July 2019.

   [I-D.ietf-6tisch-minimal-security]
              Vucinic, M., Simon, J., Pister, K., and M. Richardson,
              "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-
              6tisch-minimal-security-15 (work in progress), December
              2019.

   [I-D.ietf-emu-eap-noob]
              Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
              Authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap-
              noob-06 (work in progress), September 2021.

   [I-D.ietf-roll-aodv-rpl]
              Perkins, C. E., Anand, S., Anamalamudi, S., and B. Liu,
              "Supporting Asymmetric Links in Low Power Networks: AODV-
              RPL", draft-ietf-roll-aodv-rpl-13 (work in progress),
              March 2022.

   [IEEE_1901.2a]
              IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
              (less than 500 kHz) Narrowband Power Line Communications
              for Smart Grid Applications - Amendment 1", IEEE 1901.2a,
              September 2015, <https://standards.ieee.org/findstds/
              standard/1901.2a-2015.html>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
              <https://www.rfc-editor.org/info/rfc3972>.

   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
              Errors at High Data Rates", RFC 4963,
              DOI 10.17487/RFC4963, July 2007,
              <https://www.rfc-editor.org/info/rfc4963>.

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <https://www.rfc-editor.org/info/rfc5191>.

   [RFC5535]  Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
              DOI 10.17487/RFC5535, June 2009,
              <https://www.rfc-editor.org/info/rfc5535>.





Hou, et al.             Expires November 18, 2022              [Page 21]


Internet-Draft                IPv6 over PLC                     May 2022


   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC7925]  Tschofenig, H., Ed. and T. Fossati, "Transport Layer
              Security (TLS) / Datagram Transport Layer Security (DTLS)
              Profiles for the Internet of Things", RFC 7925,
              DOI 10.17487/RFC7925, July 2016,
              <https://www.rfc-editor.org/info/rfc7925>.

   [RFC7973]  Droms, R. and P. Duffy, "Assignment of an Ethertype for
              IPv6 with Low-Power Wireless Personal Area Network
              (LoWPAN) Encapsulation", RFC 7973, DOI 10.17487/RFC7973,
              November 2016, <https://www.rfc-editor.org/info/rfc7973>.

   [RFC8036]  Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
              Statement for the Routing Protocol for Low-Power and Lossy
              Networks (RPL) in Advanced Metering Infrastructure (AMI)
              Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
              <https://www.rfc-editor.org/info/rfc8036>.

   [RFC8065]  Thaler, D., "Privacy Considerations for IPv6 Adaptation-
              Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
              February 2017, <https://www.rfc-editor.org/info/rfc8065>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions for Stateless Address
              Autoconfiguration in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,
              <https://www.rfc-editor.org/info/rfc8981>.

   [RFC9010]  Thubert, P., Ed. and M. Richardson, "Routing for RPL
              (Routing Protocol for Low-Power and Lossy Networks)
              Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
              <https://www.rfc-editor.org/info/rfc9010>.

   [SCENA]    Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of
              the Art in Power Line Communications: From the
              Applications to the Medium", July 2016,
              <https://ieeexplore.ieee.org/document/7467440>.



Hou, et al.             Expires November 18, 2022              [Page 22]


Internet-Draft                IPv6 over PLC                     May 2022


Authors' Addresses

   Jianqiang Hou
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China

   Email: houjianqiang@huawei.com


   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District,
   Beijing 100095
   China

   Email: remy.liubing@huawei.com


   Yong-Geun Hong
   Daejeon University
   62 Daehak-ro, Dong-gu
   Daejeon  34520
   Korea

   Email: yonggeun.hong@gmail.com


   Xiaojun Tang
   State Grid Electric Power Research Institute
   19 Chengxin Avenue
   Nanjing 211106
   China

   Email: itc@sgepri.sgcc.com.cn


   Charles E. Perkins
   Lupin Lodge

   Email: charliep@computer.org









Hou, et al.             Expires November 18, 2022              [Page 23]