wdiff rfc9354.alt-original rfc9354.txt

6Lo Working Group

Internet Engineering Task Force (IETF) J. Hou
Internet-Draft
Request for Comments: 9354 B. Liu
Intended status:
Category: Standards Track Huawei Technologies
Expires: November 18, 2022
ISSN: 2070-1721 Y-G. Hong
Daejeon University
X. Tang
SGEPRI
C. Perkins
Lupin Lodge
May 17, 2022
January 2023

Transmission of IPv6 Packets over PLC Power Line Communication (PLC)
Networks
draft-ietf-6lo-plc-11

Abstract

Power Line Communication (PLC), namely using the electric-power 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 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 an Internet Standards Track document.

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

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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.
https://www.rfc-editor.org/info/rfc9354.

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 Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Simplified Revised 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 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23

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 grids, and advanced metering infrastructure in Advanced Metering Infrastructure
(AMI) [SCENA]. The data acquisition data-acquisition devices in these scenarios share
common features such as fixed position, large quantity, quantity of nodes, low
data rate 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 related to the Internet of Things
(IoT) lie in the low voltage PLC networks with most applications in
the area of Advanced Metering
Infrastructure (AMI), Vehicle-to-Grid 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.
autoconfiguration.

This document provides a brief overview of PLC technologies. Some of
them have LLN (low power (Low-Power and lossy network) Lossy Network) characteristics, i.e.,
limited power consumption, memory memory, and processing resources. This
document specifies the transmission of IPv6 packets over those
"constrained"
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]
[RFC6775], and [RFC8505] [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
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

6lo: IPv6 over Networks of Resource-constrained Nodes

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: IPv6 Interface Identifier

LLN: Low power Low-Power and Lossy Network

MTU: Maximum Transmission Unit

NBPLC: Narrowband Power Line Communication

PAN: Personal Area Network

PANC: PAN Coordinator, a coordinator which 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 draft document

RA: Router Advertisement

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] [ITU-T_G.9903], and this document.

+---------------+----------------+------------------+---------------+

Table 1: Terminology Mapping between PLC standards Standards

3. Overview of PLC

PLC technology enables convenient two-way communications for home
users and utility companies to monitor and control electric plugged 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), cost) and Broadband PLC (BBPLC) for home
and industry networking applications.

Various standards have been addressed on the MAC Media Access Control
(MAC) and PHY layers Physical (PHY) layers. For example, standards for
this communication technology, e.g., BBPLC
(1.8-250 MHz) including include IEEE 1901 and ITU-T G.hn, and standards for
NBPLC (3-500 kHz) including 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 [IEEE_1901.2] (a
combination of G3-PLC and PRIME PLC) [IEEE_1901.2], and IEEE 1901.2a [IEEE_1901.2a]
(an amendment to IEEE 1901.2).

A new PLC standard 1901.2) [IEEE_1901.2a].

IEEE 1901.1 [IEEE_1901.1], which a PLC standard that is aimed at the medium
frequency band of less than 12 MHz, has been 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, 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 MAC and PLC PHY layers correspond to the layers described in IEEE
1901.1, IEEE 1901.2 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 Layer 2 or in route-over mode at layer-3,
Layer 3, as explained in
Section 3.4. Sections 3.4 and 4.4.

+----------------------------------------+
| Application Layer |
+----------------------------------------+
| Transport Layer |
+----------------------------------------+
| |
| IPv6 Layer |
| |
+----------------------------------------+
| Adaptation layer 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]) 48 bits
[IEEE_1901.1] or 64-bits ([IEEE_1901.2], [ITU-T_G.9903]) 64 bits [IEEE_1901.2] [ITU-T_G.9903] and a short
address of 12-bits ([IEEE_1901.1]) 12 bits [IEEE_1901.1] or 16-bits ([IEEE_1901.2],
[ITU-T_G.9903]). 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]. [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 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 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 Thus, the 6lo
functions, including header compression, fragmentation 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 is
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 Layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-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 L3 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 (The Lightweight (Lightweight On-demand Ad hoc Distance vector routing
protocol, Next Generation) is a reactive protocol operating at
layer-2
Layer 2 or layer-3. 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 an Ethertype in a layer-2 Layer 2 PLC PDU. [RFC7973]
defines a 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 standards, as described in [RFC4944], [RFC6282],
[RFC6775], and
[RFC8505] [RFC8505], provide useful functionality functionality, including
link-local IPv6 addresses, stateless address auto-configuration, 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 Interface ID IID by inserting 0xFFFE at the fourth and fifth octets as
specified in [RFC2464]. The IPv6 IID is derived from the 64-bit Interface ID 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 bits, and the 16-bit short address as
follows:

16_bit_PAN:0000:16_bit_short_address

Then, the 64-bit Interface ID 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, Identifier,
YYYYYY), 12 zero bits bits, and a 12-bit TEI (Terminal Equipment
Identifier, XXX) as follows:

YYYY:YY00:0XXX

The 64-bit Interface ID 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], besides aside from the method discussed in
[RFC4291], some other IID
generation IID-generation methods defined in by the IETF do not
imply any additional semantics for the
"Universal/Local" Universal/Local (U/L) bit (bit
6) and the Individual/Group bit (bit
7), so that 7). Therefore, these two bits
are not reliable indicators for their
original meanings. Thus 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 or not. bits. If so, 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, these two bits MUST
both be set to zero.
global. In order to avoid any ambiguity in the derived
Interface ID, IID, these
two bits MUST NOT be a valid part of the PANID PAN ID (for IEEE 1901.2 and
ITU-T G.9903) or NID (for IEEE 1901.1). For example, the PANID PAN ID or
NID must always be chosen so that the two bits are zeros; zeros or the high 6
six bits in PANID PAN ID or NID are left shifted by 2 two bits. If not, 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 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 link-
layer 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 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 By default, the hash algorithm by default
of the implementations SHOULD
be SHA256, using the version number, the PANID/NID PAN ID or NID, and the short
address as the input arguments, and the
256-bits 256-bit hash output is
truncated into the IID by taking the high 64 bits.

4.2. IPv6 Link Local 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 Link-Local Address for a PLC interface Interface

4.3. Unicast Address Mapping

The address resolution address-resolution procedure for mapping IPv6 unicast addresses
into PLC link-layer addresses follows the general description in
section
Section 7.2 of [RFC4861]. [RFC6775] improves this procedure by
eliminating usage of multicast NS. NS (Neighbor Solicitation). The
resolution is realized by the NCEs (neighbor cache entry) entries) created
during the address registration at the routers. [RFC8505] further
improves the registration procedure by enabling multiple LLNs to form
an IPv6 subnet, 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 Source Link-Layer Address and Target Link-Layer Address options
for IEEE_1901.1 used in the Neighbor Solicitation 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 Link-Layer Address and 2 for Target Link-layer Link-Layer
Address.

Length: The length of this option (including type Type and length 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 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 Source Link-Layer Address and Target Link-Layer Address options
for IEEE_1901.2 and ITU-T G.9903 used in the Neighbor Solicitation NS and Neighbor
Advertisement NA have the
following form.

Figure 4: Unicast Address Mapping for IEEE 1901.2

Option fields:

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

Length: The length of this option (including type Type and length 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) (RSs) and Router
Advertisements (RA) (RAs) MAY be used as per [RFC6775]. If the PLC
network uses route-over, route-over mode, the IPv6 prefix MAY be disseminated by
the layer-3 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, 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 dissemination, Router Advertisements (RA) 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 Neighbor
Solicitation NS to the 6LR.
If the registered address is link-local, link local, the 6LR SHOULD NOT further
register it to the registrar (6LBR, (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 ([RFC6775]) (Duplicate
Address Request) [RFC6775] or EDAR ([RFC8505]) (Extended Duplicate Address
Request) [RFC8505] messages. For RFC8505
compliant PLC devices, devices compliant with
[RFC8505], the 'R' flag in the EARO MUST be set when sending Neighbor Solicitations NSs in
order to extract the status information in the replied Neighbor Advertisements 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 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 (Duplicate Address Confirmation) or EDAC (Extended
Duplicate Address Confirmation) message from the 6LBR and the Neighbor
Advertisement (NA) NA from
the 6LR. The section Section 6 of [RFC8505] shows how
RFC6775-only devices that only behave
as specified in [RFC6775] can work with RFC8505-updated devices. 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

The compression of

IPv6 datagrams within PLC MAC frames refers to
[RFC6282], which updates [RFC4944]. Header header compression as defined in PLC is based on [RFC6282] (which updates
[RFC4944]). [RFC6282] which specifies the compression format for IPv6
datagrams on top of IEEE 802.15.4, 802.15.4; therefore, this format is the basis used for IPv6 header
compression in
PLC. 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 [RFC6282] the encoding formats, formats
specified in [RFC6282], including the Dispatch Header, the LOWPAN_IPHC
LOWPAN_IPHC, and the compression residu residue carried in-line. 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 the section Section 3.1 of [RFC6282], which is illustrated as
following. 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 in-line, inline, in which the first 4 bits
are zero.

If SAC=1: stateful Stateful context-based compression

10: 16 bits. The address is derived using context information and
the 16 bits carried in-line. 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 to short address and the
IID mapping given as provided by 0000:00ff:fe00:0XXX, where 0XXX are the 16
bits carried in-line, 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, 0000:00ff:fe00:0XXX, where
0XXX are the 16 bits carried in-line, inline, in which the first 4 bits
are zero.

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

10: 16 bits. The address is derived using context information and
the 16 bits carried in-line. 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 to short address and the
IID mapping given as provided by 0000:00ff:fe00:0XXX, where 0XXX are the 16
bits carried in- line, 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 function functions of fragmentation
and reassembly. However, fragmentation and reassembly is are still
required at the adaptation layer, 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 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
[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:
devices: PAN Coordinator (PANC) and PLC Device. device. The PANC is the
primary coordinator of the PLC subnet and can be seen as a primary
node; PLC Devices devices are typically PLC meters and sensors. The address
registration and DAD features can also be deployed on the PANC, for
example
example, the 6LBR [RFC6775] or the routing registrar in [RFC8505]. IPv6
over PLC networks are built as trees, meshes tree, mesh, or stars topology 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 device and a PANC. The PANC typically collects data
(e.g., a meter reading) from the PLC devices, devices and then concentrates
and uploads the data through Ethernet or Cellular 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
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 Connected to the Internet

A tree topology is useful when the distance between a device A and
the PANC is beyond the PLC allowed 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 both a PLC Device device and a Coordinator. For this scenario,
the link layer 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 street lights to
provide information such as light intensity, temperature, and
humidity. The data transmission data-transmission distance in the street lighting
scenario is normally above several kilometers, thus kilometers; thus, a PLC tree
network is required. A more sophisticated AMI network may also be
constructed into the tree topology which 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 Connected to the Internet

Mesh networking in PLC is of great 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
([I-D.ietf-roll-aodv-rpl])
[AODV-RPL] enables direct communication between PLC device to PLC device
communication, 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 Connected to the Internet

6. Operations and Manageability Considerations

The constrained

Constrained PLC networks are not managed in the same way as an
enterprise network networks or a carrier network. 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 recently formed IOTOPS WG in the IETF is aiming 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

There are

This document has no IANA considerations related to this document. 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 Link-layer security
mechanisms, such as payload encryption and devcie 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 DoS
attacks, e.g., keep joining and leaving the network frequently, 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 Thus, the PANC must be a trusted entity. Moreover, the PLC
network must prevent malicious devices to join in from joining the network. Thus
Mutual
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 pre-installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security]
the Constrained Join Protocol (CoJP) [RFC9031] (which uses pre-shared
keys), and
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] (a Zero-Touch Secure Join [ZEROTOUCH] (an IoT version of BRSKI, the
Bootstrapping Remote Secure Key Infrastructure (BRSKI), which uses IDevID an
Initial Device Identifier (IDevID) and MASA a Manufacturer Authorized
Signing Authority (MASA) service to facilitate authentication). It
is also possible to use EAP Extensible Authentication Protocol (EAP)
methods such as [I-D.ietf-emu-eap-noob] the one defined in [RFC9140] via transports like PANA
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. Since the 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 Thus, in scenarios where the physical
attacks is are considered to be relatively highly possible, per device per-device
credentials SHOULD be used. Moreover, additional end-to-end security services" is a
services are complementary to the
network side network-side security mechanisms,
e.g., if a devices device is compromised and it has joined in the network, and
then it claims itself as the PANC and try 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 behavior-
analysis mechanisms can be deployed to recoginize 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 interface identifiers (IID) are 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 compairing compared to the link lifetime. Consider a PLC
network with 1024 devices and its a link lifetime is 8 years, according
to the formula in RFC8065, [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 Thus, as suggest suggested in the
section Section 4.1, a hash
function can be used to generate a 64 bits 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.

10.

9. References

10.1.

9.1. Normative References

[IEEE_1901.1]
IEEE-SA Standards Board, "Standard
IEEE, "IEEE Standard for Medium Frequency (less than 15 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-SA Standards Board,
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, October December 2013,
<https://standards.ieee.org/findstds/
standard/1901.2-2013.html>.
<https://ieeexplore.ieee.org/document/6679210>.

[ITU-T_G.9903]
International Telecommunication Union,
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., S. and RFC Publisher, "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., M. and RFC Publisher, "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. R., Deering, S., and RFC Publisher, "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, H., and
RFC Publisher, "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, D., and
RFC Publisher, "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. Ed., Thubert, P., and RFC Publisher, "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, R., and RFC Publisher, "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,
C., and RFC Publisher, "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. B., Jiang, S., and RFC Publisher, "Significance
of IPv6 Interface Identifiers", RFC 7136,
DOI 10.17487/RFC7136, February 2014,
<https://www.rfc-editor.org/info/rfc7136>.

[RFC8174] Leiba, B., B. and RFC Publisher, "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,
C., and RFC Publisher, "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.

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

[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]

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

[IEEE_1901.2a]
IEEE-SA 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 Board, Association, "Guidelines for Use of
Extended Unique Idenfier (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,
September
October 2015, <https://standards.ieee.org/findstds/
standard/1901.2a-2015.html>.
<https://ieeexplore.ieee.org/document/7286946>.

[RFC3972] Aura, T., T. and RFC Publisher, "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, B., and RFC Publisher,
"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, A., and RFC Publisher, "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., M. and RFC Publisher, "Hash-Based Addresses
(HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009,
<https://www.rfc-editor.org/info/rfc5535>.

[RFC7217] Gont, F., F. and RFC Publisher, "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. Ed., Fossati, T., and RFC Publisher,
"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. R., Duffy, P., and RFC Publisher, "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, D., and RFC Publisher,
"Applicability Statement for the Routing Protocol for Low-Power 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., D. and RFC Publisher, "Privacy Considerations for
IPv6 Adaptation-
Layer 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, T., and RFC
Publisher, "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, R., and RFC
Publisher, "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. Ed., Richardson, M., and RFC Publisher,
"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., Richardson, M.,
and RFC Publisher, "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., Peltonen, A., and RFC Publisher,
"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., and L. 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. 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. Haidian District,
Beijing
100095
China
Email: remy.liubing@huawei.com

Yong-Geun Hong
Daejeon University
62 Daehak-ro,
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