Huawei Technologies

101 Software Avenue, Nanjing 210012 China houjianqiang@huawei.com

Huawei Technologies

Haidian District No. 156 Beiqing Rd. Beijing 100095 China remy.liubing@huawei.com

Daejeon University

Dong-gu 62 Daehak-ro Daejeon 34520 Republic of Korea yonggeun.hong@gmail.com

State Grid Electric Power Research Institute

19 Chengxin Avenue Nanjing 211106 China itc@sgepri.sgcc.com.cn

Lupin Lodge

charliep@computer.org

int 6lo 6lo 6lowpan 6lo-plc 6loplc plc 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 .

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

• .  Introduction
• .  Requirements Notation and Terminology
• .  Overview of PLC
  • .  Protocol Stack
  • .  Addressing Modes
  • .  Maximum Transmission Unit
  • .  Routing Protocol
• .  IPv6 over PLC
  • .  Stateless Address Autoconfiguration
  • .  IPv6 Link-Local Address
  • .  Unicast Address Mapping
    • .  Unicast Address Mapping for IEEE 1901.1
    • .  Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903
  • .  Neighbor Discovery
  • .  Header Compression
  • .  Fragmentation and Reassembly
• .  Internet Connectivity Scenarios and Topologies
• .  Operations and Manageability Considerations
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

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) . 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 , , , and , to constrained PLC networks.

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 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 , , , and this document. Terminology Mapping between PLC Standards

IEEE 1901.2	IEEE 1901.1	ITU-T G.9903	This document
PAN Coordinator	Central Coordinator	PAN Coordinator	PAN Coordinator
Coordinator	Proxy Coordinator	Full-Function Device	Coordinator
Device	Station	PAN Device	PLC Device

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.9904 (PRIME), IEEE 1901.2 (a combination of G3-PLC and PRIME PLC) , and IEEE 1901.2a (an amendment to IEEE 1901.2) . 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.

Protocol Stack The protocol stack for IPv6 over PLC is illustrated in . 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 . 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 and .

PLC Protocol Stack +----------------------------------------+ | Application Layer | +----------------------------------------+ | Transport Layer | +----------------------------------------+ | | | IPv6 Layer | | | +----------------------------------------+ | Adaptation Layer for IPv6 over PLC | +----------------------------------------+ | PLC MAC Layer | +----------------------------------------+ | PLC PHY Layer | +----------------------------------------+

Addressing Modes Each PLC device has a globally unique long address of 48 bits or 64 bits and a short address of 12 bits or 16 bits . 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) .

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

Routing Protocol Routing protocols suitable for use in PLC networks include:

• RPL (Routing Protocol for Low-Power and Lossy Networks) is a Layer 3 routing protocol. 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 , and the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based networks.

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. defines an Ethertype of "A0ED" for LoWPAN encapsulation, and this information can be carried in the IE field in the MAC header of or . And regarding , 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 , , , and , 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.

Stateless Address Autoconfiguration To obtain an IPv6 Interface Identifier (IID), a PLC device performs stateless address autoconfiguration . 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 . 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 . The IPv6 IID is derived from the 64-bit IID by inverting the U/L (Universal/Local) bit . 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 , aside from the method discussed in , 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 . 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 , when short addresses are used on PLC links, a shared secret key or version number from the Authoritative Border Router Option 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.

IPv6 Link-Local Address The IPv6 link-local address for a PLC interface is formed by appending the IID, as defined above, to the prefix FE80::/64 (see ).

IPv6 Link-Local Address for a PLC Interface 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+

Unicast Address Mapping The address-resolution procedure for mapping IPv6 unicast addresses into PLC link-layer addresses follows the general description in . 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. 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.

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.

Unicast Address Mapping for IEEE 1901.1 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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.

Unicast Address Mapping for IEEE 1901.2 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Neighbor Discovery Neighbor discovery procedures for 6LoWPAN networks are described in and . 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 . 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 , 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 . 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) or EDAR (Extended Duplicate Address Request) messages. For PLC devices compliant with , 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 ) or proxied by the routing registrar (as per ). 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. shows how devices that only behave as specified in can work with devices that have been updated per . 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.

Header Compression IPv6 header compression in PLC is based on (which updates ). 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 , 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 . 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 , 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.

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 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 . uses a 16-bit datagram tag to identify the fragments of the same IP packet. 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 ; thus, the 16-bit tag is sufficient to assemble the fragments correctly.

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 or the routing registrar . 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 ). 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 Star Network Connected to the Internet PLC Device PLC Device \ / +--------- \ / / \ / + \ / | PLC Device ------ PANC ===========+ Internet / \ | / \ + / \ \ / \ +--------- PLC Device PLC Device <----------------------> PLC subnet (IPv6 over PLC)

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 . 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 . 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 Tree Network Connected to the Internet PLC Device \ +--------- PLC Device A \ / \ \ + \ \ | PLC Device B -- PANC ===========+ Internet / / | / / + PLC Device---PLC Device / \ / +--------- PLC Device---PLC Device <-------------------------> PLC subnet (IPv6 over PLC)

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 ), 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 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 Mesh Network Connected to the Internet PLC Device---PLC Device / \ / \ +--------- / \ / \ / / \ / \ + / \ / \ | PLC Device--PLC Device---PANC ===========+ Internet \ / \ / | \ / \ / + \ / \ / \ \ / \ / +--------- PLC Device---PLC Device <-------------------------------> PLC subnet (IPv6 over PLC)

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.

IANA Considerations This document has no IANA actions.

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 (exchanging pre-installed certificates over DTLS), the Constrained Join Protocol (CoJP) (which uses pre-shared keys), and Zero-Touch Secure Join (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 via transports like Protocol for Carrying Authentication for Network Access (PANA) . 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. 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 , 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 , 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 , Cryptographically Generated Addresses (CGAs) , Temporary Address Extensions , Hash-Based Addresses (HBAs) , or semantically opaque addresses SHOULD be used to enhance the IID privacy.

References Normative References IEEE IEEE ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK] The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK] The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network. Informative References Lupin Lodge Indian Institute of Science SRM University-AP Huawei Technologies Work in Progress IEEE Standards Association IEEE This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK] IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community. This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK] This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK] This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses). A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment. This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks. This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505. This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length. IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS IEEE Journal on Selected Areas in Communications, Volume 34, Issue 7 Sandelman Software Works This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network- wide key from a coordinator. The mechanism describe here is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security], and is a profile of the constrained voucher mechanism [I-D.ietf-anima-constrained-voucher]. Work in Progress

Acknowledgements We gratefully acknowledge suggestions from the members of the IETF 6lo Working Group. Great thanks to and for their feedback and support in connecting the IEEE and ITU-T sides. The authors thank , , and for their guidance in the liaison process. The authors wish to thank , , , , and for their valuable comments and contributions. The authors wish to thank for shepherding this document. The authors also thank for delivering the presentation at IETF 113. Sincere acknowledgements to the valuable comments from the following reviewers: , , , , , , , , and .

Authors' Addresses Huawei Technologies

101 Software Avenue, Nanjing 210012 China houjianqiang@huawei.com

Huawei Technologies

Haidian District No. 156 Beiqing Rd. Beijing 100095 China remy.liubing@huawei.com

Daejeon University

Dong-gu 62 Daehak-ro Daejeon 34520 Republic of Korea yonggeun.hong@gmail.com

State Grid Electric Power Research Institute

19 Chengxin Avenue Nanjing 211106 China itc@sgepri.sgcc.com.cn

Lupin Lodge

charliep@computer.org