RFC 9354: Transmission of IPv6 Packets over Power Line Communication (PLC) Networks

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9354.¶

Copyright Notice

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

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

1. Introduction

The idea of using power lines for both electricity supply and communication can be traced back to the beginning of the last century. Using the existing power grid to transmit messages, Power Line Communication (PLC) is a good candidate for supporting various service scenarios such as in houses and offices, in trains and vehicles, in smart grids, and in Advanced Metering Infrastructure (AMI) [SCENA]. The data-acquisition devices in these scenarios share common features such as fixed position, large quantity of nodes, low data rate, and low power consumption.¶

Although PLC technology has evolved over several decades, it has not been fully adapted for IPv6-based constrained networks. The resource-constrained scenarios related to the Internet of Things (IoT) lie in the low voltage PLC networks with most applications in the area of AMI, vehicle-to-grid communications, in-home energy management, and smart street lighting. IPv6 is important for PLC networks, due to its large address space and efficient address autoconfiguration.¶

This document provides a brief overview of PLC technologies. Some of them have LLN (Low-Power and Lossy Network) characteristics, i.e., limited power consumption, memory, and processing resources. This document specifies the transmission of IPv6 packets over those constrained PLC networks. The general approach is to adapt elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes) specifications, such as those described in [RFC4944], [RFC6282], [RFC6775], and [RFC8505], to constrained PLC networks.¶

2. Requirements Notation and Terminology

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

This document uses the following acronyms and terminologies:¶

6BBR:

6LoWPAN Backbone Router¶

6LBR:

6LoWPAN Border Router¶

6lo:

IPv6 over Networks of Resource-constrained Nodes¶

6LoWPAN:

IPv6 over Low-Power Wireless Personal Area Network¶

6LR:

6LoWPAN Router¶

AMI:

Advanced Metering Infrastructure¶

BBPLC:

Broadband Power Line Communication¶

Coordinator:

A device capable of relaying messages¶

DAD:

Duplicate Address Detection¶

EUI:

Extended Unique Identifier¶

IID:

Interface Identifier¶

LLN:

Low-Power and Lossy Network¶

MTU:

Maximum Transmission Unit¶

NBPLC:

Narrowband Power Line Communication¶

PAN:

Personal Area Network¶

PANC:

PAN Coordinator, a coordinator that also acts as the primary controller of a PAN¶

PLC:

Power Line Communication¶

PLC device:

An entity that follows the PLC standards and implements the protocol stack described in this document¶

RA:

Router Advertisement¶

RPL:

Routing Protocol for Low-Power and Lossy Networks¶

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

3. Overview of PLC

PLC technology enables convenient two-way communications for home users and utility companies to monitor and control electrically connected devices such as electricity meters and street lights. PLC can also be used in smart home scenarios, such as the control of indoor lights and switches. Due to the large range of communication frequencies, PLC is generally classified into two categories: Narrowband PLC (NBPLC) for automation of sensors (which have a low frequency band and low power cost) and Broadband PLC (BBPLC) for home and industry networking applications.¶

Various standards have been addressed on the Media Access Control (MAC) and Physical (PHY) layers. For example, standards for BBPLC (1.8-250 MHz) include IEEE 1901 and ITU-T G.hn, and standards for NBPLC (3-500 kHz) include ITU-T G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901.2 (a combination of G3-PLC and PRIME PLC) [IEEE_1901.2], and IEEE 1901.2a (an amendment to IEEE 1901.2) [IEEE_1901.2a].¶

IEEE 1901.1 [IEEE_1901.1], a PLC standard that is aimed at the medium frequency band of less than 12 MHz, was published by the IEEE standard for Smart Grid Powerline Communication Working Group (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus communication range and is thus a promising option for 6lo applications.¶

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

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

4. IPv6 over PLC

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

6LoWPAN and 6lo standards, as described in [RFC4944], [RFC6282], [RFC6775], and [RFC8505], provide useful functionality, including link-local IPv6 addresses, stateless address autoconfiguration, neighbor discovery, header compression, fragmentation, and reassembly. However, due to the different characteristics of the PLC media, the 6LoWPAN adaptation layer, as it is, cannot perfectly fulfill the requirements of PLC environments. These considerations suggest the need for a dedicated adaptation layer for PLC, which is detailed in the following subsections.¶

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

  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          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Internet Connectivity Scenarios and Topologies

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

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

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

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

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

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

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

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

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

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

6. Operations and Manageability Considerations

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

7. IANA Considerations

This document has no IANA actions.¶

8. Security Considerations

Due to the high accessibility of power grids, PLC might be susceptible to eavesdropping within its communication coverage, e.g., one apartment tenant may have the chance to monitor the other smart meters in the same apartment building. Link-layer security mechanisms, such as payload encryption and device authentication, are designed in the PLC technologies mentioned in this document. Additionally, an on-path malicious PLC device could eavesdrop or modify packets sent through it if appropriate confidentiality and integrity mechanisms are not implemented.¶

Malicious PLC devices could paralyze the whole network via DoS attacks, e.g., keep joining and leaving the network frequently or sending multicast routing messages containing fake metrics. A device may also inadvertently join a wrong or even malicious network, exposing its data to malicious users. When communicating with a device outside the PLC network, the traffic has to go through the PANC. Thus, the PANC must be a trusted entity. Moreover, the PLC network must prevent malicious devices from joining the network. Thus, mutual authentication of a PLC network and a new device is important, and it can be conducted during the onboarding process of the new device. Methods include protocols such as the TLS/DTLS Profile [RFC7925] (exchanging pre-installed certificates over DTLS), the Constrained Join Protocol (CoJP) [RFC9031] (which uses pre-shared keys), and Zero-Touch Secure Join [ZEROTOUCH] (an IoT version of the Bootstrapping Remote Secure Key Infrastructure (BRSKI), which uses an Initial Device Identifier (IDevID) and a Manufacturer Authorized Signing Authority (MASA) service to facilitate authentication). It is also possible to use Extensible Authentication Protocol (EAP) methods such as the one defined in [RFC9140] via transports like Protocol for Carrying Authentication for Network Access (PANA) [RFC5191]. No specific mechanism is specified by this document, as an appropriate mechanism will depend upon deployment circumstances. In some cases, the PLC devices can be deployed in uncontrolled places, where the devices may be accessed physically and be compromised via key extraction. The compromised device may be still able to join in the network since its credentials are still valid. When group-shared symmetric keys are used in the network, the consequence is even more severe, i.e., the whole network or a large part of the network is at risk. Thus, in scenarios where physical attacks are considered to be relatively highly possible, per-device credentials SHOULD be used. Moreover, additional end-to-end security services are complementary to the network-side security mechanisms, e.g., if a device is compromised and has joined in the network, and then it claims itself as the PANC and tries to make the rest of the devices join its network. In this situation, the real PANC can send an alarm to the operator to acknowledge the risk. Other behavior-analysis mechanisms can be deployed to recognize the malicious PLC devices by inspecting the packets and the data.¶

IP addresses may be used to track devices on the Internet; such devices can often in turn be linked to individuals and their activities. Depending on the application and the actual use pattern, this may be undesirable. To impede tracking, globally unique and non-changing characteristics of IP addresses should be avoided, e.g., by frequently changing the global prefix and avoiding unique link-layer derived IIDs in addresses. [RFC8065] discusses the privacy threats when an IID is generated without sufficient entropy, including correlation of activities over time, location tracking, device-specific vulnerability exploitation, and address scanning. And an effective way to deal with these threats is to have enough entropy in the IID compared to the link lifetime. Consider a PLC network with 1024 devices and a link lifetime is 8 years, according to the formula in [RFC8065], an entropy of 40 bits is sufficient. Padding the short address (12 or 16 bits) to generate the IID of a routable IPv6 address in the public network may be vulnerable to deal with address scans. Thus, as suggested in Section 4.1, a hash function can be used to generate a 64-bit IID. When the version number of the PLC network is changed, the IPv6 addresses can be changed as well. Other schemes such as limited lease period in DHCPv6 [RFC8415], Cryptographically Generated Addresses (CGAs) [RFC3972], Temporary Address Extensions [RFC8981], Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque addresses [RFC7217] SHOULD be used to enhance the IID privacy.¶

Acknowledgements

We gratefully acknowledge suggestions from the members of the IETF 6lo Working Group. Great thanks to Samita Chakrabarti and Gabriel Montenegro for their feedback and support in connecting the IEEE and ITU-T sides. The authors thank Scott Mansfield, Ralph Droms, and Pat Kinney for their guidance in the liaison process. The authors wish to thank Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu, and Michael Richardson for their valuable comments and contributions. The authors wish to thank Carles Gomez for shepherding this document. The authors also thank Paolo Volpato for delivering the presentation at IETF 113. Sincere acknowledgements to the valuable comments from the following reviewers: Dave Thaler, Dan Romascanu, Murray Kucherawy, Benjamin Kaduk, Alvaro Retana, Éric Vyncke, Meral Shirazipour, Roman Danyliw, and Lars Eggert.¶

Authors' Addresses