doc: Add RFC documents

1 files changed, 1081 insertions, 0 deletions

diff --git a/doc/rfc/rfc9354.txt b/doc/rfc/rfc9354.txt
new file mode 100644
index 0000000..beba29e
--- /dev/null
+++ b/doc/rfc/rfc9354.txt
@@ -0,0 +1,1081 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                            J. Hou
+Request for Comments: 9354                                        B. Liu
+Category: Standards Track                            Huawei Technologies
+ISSN: 2070-1721                                                Y-G. Hong
+                                                      Daejeon University
+                                                                 X. Tang
+                                                                  SGEPRI
+                                                              C. Perkins
+                                                             Lupin Lodge
+                                                            January 2023
+
+
+    Transmission of IPv6 Packets over Power Line Communication (PLC)
+                                Networks
+
+Abstract
+
+   Power Line Communication (PLC), namely using 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 those described in ITU-T G.9903,
+   IEEE 1901.1, and IEEE 1901.2.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9354.
+
+Copyright Notice
+
+   Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Requirements Notation and Terminology
+   3.  Overview of PLC
+     3.1.  Protocol Stack
+     3.2.  Addressing Modes
+     3.3.  Maximum Transmission Unit
+     3.4.  Routing Protocol
+   4.  IPv6 over PLC
+     4.1.  Stateless Address Autoconfiguration
+     4.2.  IPv6 Link-Local Address
+     4.3.  Unicast Address Mapping
+       4.3.1.  Unicast Address Mapping for IEEE 1901.1
+       4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T
+               G.9903
+     4.4.  Neighbor Discovery
+     4.5.  Header Compression
+     4.6.  Fragmentation and Reassembly
+   5.  Internet Connectivity Scenarios and Topologies
+   6.  Operations and Manageability Considerations
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+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 grids, and in Advanced Metering Infrastructure
+   (AMI) [SCENA].  The data-acquisition devices in these scenarios share
+   common features such as fixed position, large quantity of nodes, 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 scenarios related to the Internet of Things
+   (IoT) lie in the low voltage PLC networks with most applications in
+   the area of 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
+   autoconfiguration.
+
+   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 those described in [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
+   BCP 14 [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
+
+   6lo:  IPv6 over Networks of Resource-constrained Nodes
+
+   6LoWPAN:  IPv6 over Low-Power Wireless Personal Area Network
+
+   6LR:  6LoWPAN Router
+
+   AMI:  Advanced Metering Infrastructure
+
+   BBPLC:  Broadband Power Line Communication
+
+   Coordinator:  A device capable of relaying messages
+
+   DAD:  Duplicate Address Detection
+
+   EUI:  Extended Unique Identifier
+
+   IID:  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 that 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 document
+
+   RA:  Router Advertisement
+
+   RPL:  Routing Protocol for Low-Power and Lossy Networks
+
+   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 Coordinator |   Central   |      PAN      |      PAN      |
+     |                 | Coordinator |  Coordinator  |  Coordinator  |
+     +-----------------+-------------+---------------+---------------+
+     |   Coordinator   |    Proxy    | Full-Function |  Coordinator  |
+     |                 | Coordinator |     Device    |               |
+     +-----------------+-------------+---------------+---------------+
+     |      Device     |   Station   |   PAN Device  |   PLC Device  |
+     +-----------------+-------------+---------------+---------------+
+
+             Table 1: Terminology Mapping between PLC Standards
+
+3.  Overview of PLC
+
+   PLC technology enables convenient two-way communications for home
+   users and utility companies to monitor and control electrically
+   connected 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 Media Access Control
+   (MAC) and Physical (PHY) layers.  For example, standards for BBPLC
+   (1.8-250 MHz) include IEEE 1901 and ITU-T G.hn, and standards for
+   NBPLC (3-500 kHz) include ITU-T G.9902 (G.hnem), ITU-T G.9903
+   (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901.2 (a
+   combination of G3-PLC and PRIME PLC) [IEEE_1901.2], and IEEE 1901.2a
+   (an amendment to IEEE 1901.2) [IEEE_1901.2a].
+
+   IEEE 1901.1 [IEEE_1901.1], a PLC standard that is aimed at the medium
+   frequency band of less than 12 MHz, was 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 and PLC PHY layers correspond to the layers described in 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 Sections 3.4 and 4.4.
+
+                    +----------------------------------------+
+                    |           Application Layer            |
+                    +----------------------------------------+
+                    |            Transport Layer             |
+                    +----------------------------------------+
+                    |                                        |
+                    |               IPv6 Layer               |
+                    |                                        |
+                    +----------------------------------------+
+                    |   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) [RFC9031].
+
+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 an 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 a high-noise communication environment.  Thus, the 6lo
+   functions, including header compression, fragmentation, and
+   reassembly, are still applicable and useful.
+
+   The MTU for ITU-T G.9903 is 400 octets, which is insufficient for
+   supporting IPv6's MTU.  For this reason, fragmentation and reassembly
+   are required for G.9903-based networks to carry IPv6.
+
+3.4.  Routing Protocol
+
+   Routing protocols suitable for use in PLC networks include:
+
+   *  RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
+      is a Layer 3 routing protocol.  AODV-RPL [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 a Layer 3 routing protocol for
+      parent selection.
+
+   *  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).
+
+   *  LOADng (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 an Ethertype in a Layer 2 PLC PDU.  [RFC7973]
+   defines an 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, as described in [RFC4944], [RFC6282],
+   [RFC6775], and [RFC8505], provide useful functionality, including
+   link-local IPv6 addresses, stateless address autoconfiguration,
+   neighbor discovery, header compression, fragmentation, and
+   reassembly.  However, due to the different characteristics of the PLC
+   media, 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.
+
+   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 IID by inserting 0xFFFE at the fourth and fifth octets as
+   specified in [RFC2464].  The IPv6 IID is derived from the 64-bit IID
+   by inverting the U/L (Universal/Local) 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 IID MUST be derived by inserting the 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 a 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 IID MUST be derived by inserting the 16-bit 0xFFFE into
+   this 48-bit pseudo-address as follows:
+
+      YYYY:YYFF:FE00:0XXX
+
+   As investigated in [RFC7136], aside from the method discussed in
+   [RFC4291], other IID-generation methods defined by the IETF do not
+   imply any additional semantics for the Universal/Local (U/L) bit (bit
+   6) and the Individual/Group bit (bit 7).  Therefore, these two bits
+   are not reliable indicators.  Thus, when using an IID derived by a
+   short address, the operators of the PLC network can choose whether or
+   not to comply with the original meaning of these two bits.  If they
+   choose to comply with the original meaning, these two bits MUST both
+   be set to zero, since the IID derived from the short address is not
+   global.  In order to avoid any ambiguity in the derived IID, these
+   two bits MUST NOT be a valid part of the PAN ID (for IEEE 1901.2 and
+   ITU-T G.9903) or NID (for IEEE 1901.1).  For example, the PAN ID or
+   NID must always be chosen so that the two bits are zeros or the high
+   six bits in PAN ID or NID are left shifted by two bits.  If they
+   choose not to comply with the original meaning, 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 described 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 short
+   link-layer 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.  By default, the hash algorithm SHOULD
+   be SHA256, using the version number, the PAN ID or NID, and the short
+   address as the input arguments, and the 256-bit 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 (Neighbor Solicitation).  The
+   resolution is realized by the NCEs (neighbor cache entries) 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 Link-Layer Address and Target Link-Layer Address options
+   for IEEE_1901.1 used in the NS and Neighbor Advertisement (NA) 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 Link-Layer Address and Target Link-Layer Address options
+   for IEEE_1901.2 and ITU-T G.9903 used in the NS and NA 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
+
+4.4.  Neighbor Discovery
+
+   Neighbor discovery procedures for 6LoWPAN networks are described in
+   [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 (RSs) and Router
+   Advertisements (RAs) MAY be used as per [RFC6775].  If the PLC
+   network uses route-over mode, 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 dissemination of context information, RAs 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.
+
+   For address registration in route-over mode, a PLC device MUST
+   register its addresses by sending a unicast link-local NS to the 6LR.
+   If the registered address is link local, the 6LR SHOULD NOT further
+   register it to the registrar (6LBR or 6BBR).  Otherwise, the address
+   MUST be registered via an ARO (Address Registration Option) or EARO
+   (Extended Address Registration Option) included in the DAR (Duplicate
+   Address Request) [RFC6775] or EDAR (Extended Duplicate Address
+   Request) [RFC8505] messages.  For PLC devices compliant with
+   [RFC8505], the 'R' flag in the EARO MUST be set when sending NSs in
+   order to extract the status information in the replied NAs from the
+   6LR.  If DHCPv6 is used to assign addresses or the IPv6 address is
+   derived from the unique long or short link-layer address, Duplicate
+   Address Detection (DAD) SHOULD NOT be utilized.  Otherwise, 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 (Duplicate Address Confirmation) or EDAC (Extended
+   Duplicate Address Confirmation) message from the 6LBR and the NA from
+   the 6LR.  Section 6 of [RFC8505] shows how devices that only behave
+   as specified in [RFC6775] can work with devices that have been
+   updated per [RFC8505].
+
+   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
+
+   IPv6 header compression in PLC is based on [RFC6282] (which updates
+   [RFC4944]).  [RFC6282] specifies the compression format for IPv6
+   datagrams on top of IEEE 802.15.4; therefore, this format is used for
+   compression of IPv6 datagrams within PLC MAC frames.  For situations
+   when the PLC MAC MTU cannot support the 1280-octet IPv6 packet, the
+   headers MUST be compressed according to the encoding formats
+   specified in [RFC6282], including the Dispatch Header, the
+   LOWPAN_IPHC, and the compression residue carried inline.
+
+   For IEEE 1901.2 and ITU-T 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 Section 3.1 of [RFC6282], which is illustrated as follows.
+
+   SAM: Source Address Mode:
+
+   If SAC=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 inline, 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 inline.  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 mapping between the 16-bit short address and the
+         IID as provided by 0000:00ff:fe00:0XXX, where 0XXX are the 16
+         bits carried inline, 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 inline, 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 inline.  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 mapping between the 16-bit short address and the
+         IID as provided by 0000:00ff:fe00:0XXX, where 0XXX are the 16
+         bits carried inline, 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 functions of fragmentation
+   and reassembly.  However, fragmentation and reassembly are 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 a higher
+   transmission success rate, and the operator can choose to configure
+   smaller MTU at the 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
+   devices: 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 [RFC8505].  IPv6
+   over PLC networks are built as tree, mesh, or star topologies
+   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, and 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.
+
+                   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 as both 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 that 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.
+
+                          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 has many 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
+   [AODV-RPL] enables direct communication between PLC devices, without
+   being obliged to transmit frames through the PANC, which is a
+   requirement often cited for the 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
+
+6.  Operations and Manageability Considerations
+
+   Constrained PLC networks are not managed in the same way as
+   enterprise networks or carrier networks.  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 the IETF aims 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
+
+   This document has no IANA actions.
+
+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 device authentication, are
+   designed in the PLC technologies mentioned in this document.
+   Additionally, an 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 from joining 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 the TLS/DTLS
+   Profile [RFC7925] (exchanging pre-installed certificates over DTLS),
+   the Constrained Join Protocol (CoJP) [RFC9031] (which uses pre-shared
+   keys), and Zero-Touch Secure Join [ZEROTOUCH] (an IoT version of the
+   Bootstrapping Remote Secure Key Infrastructure (BRSKI), which uses an
+   Initial Device Identifier (IDevID) and a Manufacturer Authorized
+   Signing Authority (MASA) service to facilitate authentication).  It
+   is also possible to use Extensible Authentication Protocol (EAP)
+   methods such as the one defined in [RFC9140] via transports like
+   Protocol for Carrying Authentication for Network Access (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.  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 physical
+   attacks are considered to be relatively highly possible, per-device
+   credentials SHOULD be used.  Moreover, additional end-to-end security
+   services are complementary to the network-side security mechanisms,
+   e.g., if a device is compromised and has joined in the network, and
+   then it claims itself as the PANC and tries to make the rest of the
+   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 recognize 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 an IID is 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 compared to the link lifetime.  Consider a PLC
+   network with 1024 devices and a 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 suggested in Section 4.1, a hash
+   function can be used to generate a 64-bit 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.
+
+9.  References
+
+9.1.  Normative References
+
+   [IEEE_1901.1]
+              IEEE, "IEEE Standard for Medium Frequency (less than 12
+              MHz) Power Line Communications for Smart Grid
+              Applications", DOI 10.1109/IEEESTD.2018.8360785, IEEE
+              Std 1901.1, May 2018,
+              <https://ieeexplore.ieee.org/document/8360785>.
+
+   [IEEE_1901.2]
+              IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz)
+              Narrowband Power Line Communications for Smart Grid
+              Applications", DOI 10.1109/IEEESTD.2013.6679210, IEEE
+              Std 1901.2, December 2013,
+              <https://ieeexplore.ieee.org/document/6679210>.
+
+   [ITU-T_G.9903]
+              ITU-T, "Narrowband orthogonal frequency division
+              multiplexing power line communication transceivers for
+              G3-PLC networks", ITU-T Recommendation 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>.
+
+   [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>.
+
+9.2.  Informative References
+
+   [AODV-RPL] Perkins, C. E., Anand, S.V.R., Anamalamudi, S., and B.
+              Liu, "Supporting Asymmetric Links in Low Power Networks:
+              AODV-RPL", Work in Progress, Internet-Draft, draft-ietf-
+              roll-aodv-rpl-15, 30 September 2022,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-roll-
+              aodv-rpl-15>.
+
+   [EUI-64]   IEEE Standards Association, "Guidelines for Use of
+              Extended Unique Identifier (EUI), Organizationally Unique
+              Identifier (OUI), and Company ID (CID)", August 2017,
+              <https://standards.ieee.org/wp-
+              content/uploads/import/documents/tutorials/eui.pdf>.
+
+   [IEEE_1901.2a]
+              IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz)
+              Narrowband Power Line Communications for Smart Grid
+              Applications - Amendment 1",
+              DOI 10.1109/IEEESTD.2013.6679210, IEEE Std 1901.2a,
+              October 2015,
+              <https://ieeexplore.ieee.org/document/7286946>.
+
+   [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>.
+
+   [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>.
+
+   [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
+              Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
+              RFC 9031, DOI 10.17487/RFC9031, May 2021,
+              <https://www.rfc-editor.org/info/rfc9031>.
+
+   [RFC9140]  Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
+              Authentication for EAP (EAP-NOOB)", RFC 9140,
+              DOI 10.17487/RFC9140, December 2021,
+              <https://www.rfc-editor.org/info/rfc9140>.
+
+   [SCENA]    Cano, C., Pittolo, A., Malone, D., Lampe, L., Tonello, A.,
+              and A. Dabak, "State of the Art in Power Line
+              Communications: From the Applications to the Medium", IEEE
+              Journal on Selected Areas in Communications, Volume 34,
+              Issue 7, DOI 10.1109/JSAC.2016.2566018, July 2016,
+              <https://ieeexplore.ieee.org/document/7467440>.
+
+   [ZEROTOUCH]
+              Richardson, M., "6tisch Zero-Touch Secure Join protocol",
+              Work in Progress, Internet-Draft, draft-ietf-6tisch-
+              dtsecurity-zerotouch-join-04, 8 July 2019,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
+              dtsecurity-zerotouch-join-04>.
+
+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.
+   The authors wish to thank Carles Gomez for shepherding this document.
+   The authors also thank Paolo Volpato for delivering the presentation
+   at IETF 113.  Sincere acknowledgements to the valuable comments from
+   the following reviewers: Dave Thaler, Dan Romascanu, Murray
+   Kucherawy, Benjamin Kaduk, Alvaro Retana, Éric Vyncke, Meral
+   Shirazipour, Roman Danyliw, and Lars Eggert.
+
+Authors' Addresses
+
+   Jianqiang Hou
+   Huawei Technologies
+   101 Software Avenue,
+   Nanjing
+   210012
+   China
+   Email: houjianqiang@huawei.com
+
+
+   Bing Liu
+   Huawei Technologies
+   Haidian District
+   No. 156 Beiqing Rd.
+   Beijing
+   100095
+   China
+   Email: remy.liubing@huawei.com
+
+
+   Yong-Geun Hong
+   Daejeon University
+   Dong-gu
+   62 Daehak-ro
+   Daejeon
+   34520
+   Republic of 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