RFC 9354

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

πŸ“… published January 2023, from ietf

Transmission of IPv6 Packets over Power Line Communication (PLC) Networks ⚑🌸

okay bestie, the title block is giving organized πŸ’… This is RFC 9354, published in January 2023 as a Standards Track doc from the IETF. Its ISSN is 2070-1721. The authors are J. Hou and B. Liu (both from Huawei Technologies), Y-G. Hong (Daejeon University), X. Tang (SGEPRI), and C. Perkins (Lupin Lodge). The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own πŸ¦‹

Abstract ✨

Power Line Communication (PLC) means using electric power lines for indoor and outdoor communication πŸ”Œ It's already widely used for Advanced Metering Infrastructure (AMI), especially smart electricity meters. The existing electricity infrastructure makes PLC easier to expand because it's cheap and convenient, and since so many different devices can connect, there's a growing need for IPv6 in future applications 🌈 This document describes how IPv6 packets get carried over constrained PLC networks, like the ones described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2 πŸ’œ

Status of This Memo ✨

This is an Internet Standards Track document πŸŽ€

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 πŸ“š

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9354 πŸ”—

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. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Revised BSD License 🫢

Table of Contents 🧚

1.  Introduction
2.  Requirements Notation and Terminology
3.  Overview of PLC
  3.1.  Protocol Stack
  3.2.  Addressing Modes
  3.3.  Maximum Transmission Unit
  3.4.  Routing Protocol
4.  IPv6 over PLC
  4.1.  Stateless Address Autoconfiguration
  4.2.  IPv6 Link-Local Address
  4.3.  Unicast Address Mapping
    4.3.1.  Unicast Address Mapping for IEEE 1901.1
    4.3.2.  Unicast Address Mapping for IEEE 1901.2 and ITU-T
            G.9903
  4.4.  Neighbor Discovery
  4.5.  Header Compression
  4.6.  Fragmentation and Reassembly
5.  Internet Connectivity Scenarios and Topologies
6.  Operations and Manageability Considerations
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌷

Using power lines for both electricity supply and communication is an idea that goes all the way back to the start of the last century πŸ•°οΈ Power Line Communication (PLC) uses the existing power grid to send messages, which makes it a great fit for all kinds of scenarios: houses and offices, trains and vehicles, smart grids, and Advanced Metering Infrastructure (AMI) [SCENA] πŸ’‘ The data-acquisition devices in these settings tend to share the same vibe: fixed positions, tons of nodes, low data rates, and low power consumption πŸ”‹

PLC tech has been around for decades, but it still hasn't been fully adapted for IPv6-based constrained networks πŸ₯Ί The resource-constrained Internet of Things (IoT) scenarios live in low voltage PLC networks, mostly for AMI, vehicle-to-grid communication, in-home energy management, and smart street lighting πŸ’‘ IPv6 matters a lot here because of its huge address space and efficient address autoconfiguration 🌈

This document gives a quick overview of PLC technologies. Some of them are Low-Power and Lossy Network (LLN) types, meaning they have limited power, memory, and processing resources πŸ“ This document specifies how IPv6 packets get transmitted over those constrained PLC networks. The general approach is to adapt pieces of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes) specs, like those in [RFC4944], [RFC6282], [RFC6775], and [RFC8505], so they work on constrained PLC networks ✨

2. Requirements Notation and Terminology πŸ’…

Okay so 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 read as described in BCP 14 [RFC2119] [RFC8174]. They only count when, and only when, they show up in all capitals, just like here πŸ™ˆ

This document uses these acronyms and terms:

  • 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

Here's a mapping table of the terminology across [IEEE_1901.2], [IEEE_1901.1], [ITU-T_G.9903], and this document πŸ—ΊοΈ

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

          Table 1: Terminology Mapping between PLC Standards

3. Overview of PLC πŸ¦‹

PLC gives home users and utility companies a convenient two-way link to monitor and control electrically connected stuff, like electricity meters and street lights πŸ’‘ It can also run smart home setups, like controlling indoor lights and switches 🏠 Because the range of communication frequencies is so wide, PLC is usually split into two categories: Narrowband PLC (NBPLC), used for automating sensors with a low frequency band and low power cost, and Broadband PLC (BBPLC), used for home and industry networking 🌸

Various standards cover the Media Access Control (MAC) and Physical (PHY) layers. For example, BBPLC standards (1.8-250 MHz) include IEEE 1901 and ITU-T G.hn, while NBPLC standards (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 combo 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] is a PLC standard aimed at the medium frequency band below 12 MHz. It was published by the IEEE standard for Smart Grid Powerline Communication Working Group (SGPLC WG) 🧚 It balances bandwidth against communication range, which makes it a promising option for 6lo applications πŸ’–

This specification focuses on IEEE 1901.1, IEEE 1901.2, and ITU-T G.9903 ✨

3.1. Protocol Stack πŸ₯ž

The protocol stack for IPv6 over PLC is shown in Figure 1. The PLC MAC and PLC PHY layers match the layers described in IEEE 1901.1, IEEE 1901.2, or ITU-T G.9903. The 6lo adaptation layer for PLC is covered in Section 4. For multihop tree and mesh topologies, a routing protocol is likely to be necessary. Routes can be built in mesh-under mode at Layer 2 or in route-over mode at Layer 3, as explained in Sections 3.4 and 4.4 🌈

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

                      Figure 1: PLC Protocol Stack

3.2. Addressing Modes πŸŽ€

Each PLC device has a globally unique long address: 48 bits [IEEE_1901.1], or 64 bits [IEEE_1901.2] [ITU-T_G.9903]. It also has a short address: 12 bits [IEEE_1901.1], or 16 bits [IEEE_1901.2] [ITU-T_G.9903]. The long address is set by the manufacturer, based on the IEEE EUI-48 MAC address or the IEEE EUI-64 address. Each PLC device joins the network using its long address, then talks to other devices using the short address once it's in 🫢

Short addresses can be assigned during the onboarding process, either by the PANC or by the JRC (join registrar/coordinator) in CoJP (Constrained Join Protocol) [RFC9031] πŸ’œ

3.3. Maximum Transmission Unit πŸ“

okay so the MAC layer's MTU is literally the thing that decides whether the adaptation layer has to fragment and reassemble packets for IPv6 over PLC 🫢. IPv6 requires an MTU of 1280 octets or greater, so if the MAC layer's MTU is lower than that limit, fragmentation and reassembly at the adaptation layer are required. no cap, it's that simple ✨

The IEEE 1901.1 MAC can carry 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 got updated in 2015 [IEEE_1901.2a], so the number you see in older stuff might not be the current one πŸ’….) These two technologies can run IPv6 without fragmentation and reassembly, but it's still possible to configure a smaller MTU if the environment is super noisy πŸ™ˆ. So the 6lo functions, including header compression, fragmentation, and reassembly, are still applicable and useful. not me saying they're useless 😭

The MTU for ITU-T G.9903 is 400 octets πŸ’€, which is not enough for IPv6's MTU. That means fragmentation and reassembly are required for G.9903-based networks that want to carry IPv6.

3.4. Routing Protocol 🧭

Here are the routing protocols that work for PLC networks, bestie πŸ‘‘

  • RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a Layer 3 routing protocol πŸ¦‹. AODV-RPL [AODV-RPL] updates RPL so it can do reactive, point-to-point, and asymmetric routing. IEEE 1901.2 specifies Information Elements (IEs) with MAC layer metrics, and those can be handed to a Layer 3 routing protocol to help with parent selection. main character energy πŸ’–
  • IEEE 1901.1 supports the mesh-under routing scheme πŸ•ΈοΈ. Each PLC node keeps a routing table, where every route entry has the short addresses of the destination and the related next hop. The route entries get built during network establishment through a pair of association request/confirmation messages, and they can be changed through 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) πŸ”₯. Yes, MUST, capitals and everything πŸ’…
  • LOADng (Lightweight On-demand Ad hoc Distance vector routing protocol, Next Generation) is a reactive protocol that operates at Layer 2 or Layer 3 🌈. Right now LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and the IEEE 1901.2 standard points to ITU-T G.9903 for LOAD-based networks 🧚.

4. IPv6 over PLC ⚑

A PLC node tells an IPv6 PDU apart from a non-IPv6 PDU by looking at the equivalent of an Ethertype in a Layer 2 PLC PDU πŸ‘€. [RFC7973] defines an Ethertype of "A0ED" for LoWPAN encapsulation, and this info can be carried in the IE field in the MAC header of [IEEE_1901.2] or [ITU-T_G.9903]. For [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 is what helps tell an IPv4 PDU apart from an IPv6 PDU. easy peasy 🫢

6LoWPAN and 6lo standards, as described in [RFC4944], [RFC6282], [RFC6775], and [RFC8505], give us some really useful stuff: link-local IPv6 addresses, stateless address autoconfiguration, neighbor discovery, header compression, fragmentation, and reassembly ✨. However, PLC media behave differently, so the 6LoWPAN adaptation layer as it is can't perfectly meet the requirements of PLC environments 😭. These considerations mean there's a need for a dedicated adaptation layer for PLC, and that's what the following subsections go into πŸ’œ.

4.1. Stateless Address Autoconfiguration πŸŽ€

To get an IPv6 Interface Identifier (IID), a PLC device does stateless address autoconfiguration [RFC4944]. The autoconfiguration can be based on either a long or a short link-layer address πŸ’….

The IID can be based on the device's 48-bit MAC address or its EUI-64 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to a 64-bit IID by inserting 0xFFFE at the fourth and fifth octets, as specified in [RFC2464] πŸ”₯. The IPv6 IID then comes from the 64-bit IID by inverting the U/L (Universal/Local) bit [RFC4291] 🌸.

For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is built from the 16-bit PAN ID, 16 zero bits, and the 16-bit short address, like this 🧩:

   16_bit_PAN:0000:16_bit_short_address

After that, the 64-bit IID MUST be derived by inserting the 16-bit 0xFFFE, like so:

   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 made from a 24-bit NID (Network Identifier, YYYYYY), 12 zero bits, and a 12-bit TEI (Terminal Equipment Identifier, XXX) πŸ¦‹:

   YYYY:YY00:0XXX

The 64-bit IID MUST be derived by inserting the 16-bit 0xFFFE into this 48-bit pseudo-address, like this:

   YYYY:YYFF:FE00:0XXX

Here's the tea β˜•. As investigated in [RFC7136], apart from the method discussed in [RFC4291], other IID-generation methods defined by the IETF don't imply any extra semantics for the Universal/Local (U/L) bit (bit 6) or the Individual/Group bit (bit 7). So those two bits aren't reliable indicators πŸ™ˆ. That means when an IID is derived from a short address, the operators of the PLC network get to choose whether or not to follow the original meaning of these two bits πŸ€·β€β™€οΈ.

If they choose to follow the original meaning, both bits MUST be set to zero, since an IID derived from a short address isn't global. 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 the NID (for IEEE 1901.1). For example, the PAN ID or NID always has to be picked so the two bits are zeros, or the high six bits of the PAN ID or NID are left shifted by two bits 🧠. If they choose not to follow the original meaning, the operator must be aware that these two bits aren't reliable indicators, and the IID can't be transformed back into a short link-layer address by reversing the mechanism above. Still, the short address can be obtained through the Unicast Address Mapping mechanism described in Section 4.3 🫢.

For privacy reasons, the IID derived from the MAC address (with padding and bit clamping) SHOULD only be used for link-local address configuration πŸ”’. A PLC host SHOULD use the IID derived from the short link-layer address to configure the IPv6 addresses it uses to talk to the public network, otherwise the host's MAC address gets exposed 😱. As per [RFC8065], when short addresses are used on PLC links, a shared secret key or a version number from the Authoritative Border Router Option [RFC6775] can be used to boost the entropy of the hash input πŸ“ˆ. That way the generated IID can be spread out across 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. The 256-bit hash output then gets truncated into the IID by taking the high 64 bits 🌈.

The IPv6 link-local address [RFC4291] for a PLC interface is formed by appending the IID (as defined above) to the prefix FE80::/64 (see Figure 2) πŸ’œ.

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

Figure 2: IPv6 Link-Local Address for a PLC Interface

4.3. Unicast Address Mapping πŸ—ΊοΈ

The address-resolution procedure for mapping IPv6 unicast addresses into PLC link-layer addresses follows the general description in Section 7.2 of [RFC4861]. [RFC6775] improves on this procedure by getting rid of multicast NS (Neighbor Solicitation) πŸ™Œ. The resolution happens through the NCEs (neighbor cache entries) created during address registration at the routers. [RFC8505] goes even further by letting multiple LLNs form an IPv6 subnet, and by adding a link-local address registration that better supports proxy registration of new devices πŸ¦‹.

4.3.1. Unicast Address Mapping for IEEE 1901.1

The Source Link-Layer Address and Target Link-Layer Address options for IEEE_1901.1, used in the NS and Neighbor Advertisement (NA), look like this πŸ‘€:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length=1   |              NID              :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :NID (continued)|  Padding (all zeros)  |          TEI          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Unicast Address Mapping for IEEE 1901.1

Option fields:

  • Type: 1 for Source Link-Layer Address and 2 for Target Link-Layer Address.
  • Length: The length of this option (including the Type and Length fields) in units of 8 octets. The value of this field is 1 for the 12-bit IEEE 1901.1 PLC short addresses.
  • NID: 24-bit Network Identifier
  • Padding: 12 zero bits
  • TEI: 12-bit Terminal Equipment Identifier

4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903

The Source Link-Layer Address and Target Link-Layer Address options for IEEE_1901.2 and ITU-T G.9903, used in the NS and NA, look like this πŸŽ€:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length=1   |             PAN ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Padding (all zeros)     |         Short Address         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Unicast Address Mapping for IEEE 1901.2

Option fields:

  • Type: 1 for Source Link-Layer Address and 2 for Target Link-Layer Address.
  • Length: The length of this option (including the Type and Length fields) in units of 8 octets. The value of this field is 1 for the 16-bit IEEE 1901.2 PLC short addresses.
  • PAN ID: 16-bit PAN IDentifier
  • Padding: 16 zero bits
  • Short Address: 16-bit short address

4.4. Neighbor Discovery 🧚

okay so neighbor discovery for 6LoWPAN networks is spelled out in [RFC6775] and [RFC8505] πŸ’–. These optimizations are what support registering sleeping hosts 😴. Even though PLC devices are electrically powered, sleeping mode SHOULD still be used for power saving πŸŒ™, because saving energy is always iconic.

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

For dissemination of context information, RAs MUST be used as per [RFC6775] πŸ’…. The 6LoWPAN context option (6CO) MUST be included in the RA to disseminate the Context IDs used for prefix and/or address compression. So the RA is the one carrying the 6CO, period ✨.

For address registration in route-over mode, a PLC device MUST register its addresses by sending a unicast link-local NS to the 6LR πŸ¦‹. If the registered address is link local, the 6LR SHOULD NOT further register it to the registrar (6LBR or 6BBR). Otherwise, the address MUST be registered via an ARO (Address Registration Option) or EARO (Extended Address Registration Option) included in the DAR (Duplicate Address Request) [RFC6775] or EDAR (Extended Duplicate Address Request) [RFC8505] messages. For PLC devices compliant with [RFC8505], the 'R' flag in the EARO MUST be set when sending NSs, so the status info comes back in the replied NAs from the 6LR πŸ‘‘. If DHCPv6 is used to assign addresses, or the IPv6 address is derived from the unique long or short link-layer address, Duplicate Address Detection (DAD) SHOULD NOT be utilized πŸ™ˆ. Otherwise, DAD MUST be performed at the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as per [RFC8505]). The registration status is fed back via the DAC (Duplicate Address Confirmation) or EDAC (Extended Duplicate Address Confirmation) message from the 6LBR and the NA from the 6LR. Section 6 of [RFC8505] shows how devices that only behave as specified in [RFC6775] can work with devices that have been updated per [RFC8505] 🫢.

For address registration in mesh-under mode, since all the PLC devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC messages are not required 🌸. A PLC device MUST register its addresses by sending a unicast NS message with an ARO or EARO. The registration status is fed back via the NA message from the 6LBR.

4.5. Header Compression 🌈

IPv6 header compression in PLC is based on [RFC6282] (which updates [RFC4944]) πŸ’œ. [RFC6282] specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, so this format gets reused for compressing IPv6 datagrams inside PLC MAC frames. For situations when the PLC MAC MTU cannot support the 1280-octet IPv6 packet, the headers MUST be compressed according to the encoding formats specified in [RFC6282], including the Dispatch Header, the LOWPAN_IPHC, and the compression residue carried inline πŸ”₯.

For IEEE 1901.2 and ITU-T G.9903, the IP header compression follows the instructions in [RFC6282]. However, additional adaptation MUST be considered for IEEE 1901.1, since it has a short address of 12 bits instead of 16 bits πŸ™ƒ. The only modification is the semantics of the "Source Address Mode" and the "Destination Address Mode" when set as "10" in Section 3.1 of [RFC6282], which is illustrated as follows πŸ¦„.

SAM: Source Address Mode:

If SAC=0: Stateless compression

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

If SAC=1: Stateful context-based compression

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

DAM: Destination Address Mode:

If M=0 and DAC=0: Stateless compression

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

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

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

4.6. Fragmentation and Reassembly 🧩

The constrained PLC MAC layer already handles 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. But when the channel is noisy, smaller packets have a higher transmission success rate, so the operator can choose to configure a 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 frequently incorrectly assembled IP fragments 😭. For constrained PLC, the data rate is much lower than the situation mentioned in [RFC4963], so the 16-bit tag is sufficient to assemble the fragments correctly 🌟.

5. Internet Connectivity Scenarios and Topologies ✨

okay so let's talk about how these networks actually hook up to the internet 🌐 the PLC network model can be boiled down to two kinds of network devices: the PAN Coordinator (PANC) and PLC devices. the PANC is the primary coordinator of the PLC subnet, so it's basically the primary node πŸ‘‘, and PLC devices are typically PLC meters and sensors πŸ’‘. the address registration and DAD features can also be deployed on the PANC, like the 6LBR [RFC6775] or the routing registrar [RFC8505] 🧚. IPv6 over PLC networks are built as tree, mesh, or star topologies depending on the use case 🌸. generally, each PLC network has one PANC. in some cases the network can have alternate coordinators that replace the PANC when it leaves the network for some reason 🫢. quick note: the PLC topologies in this section are based on logical connectivity, not physical links πŸ™ˆ. and "PLC subnet" refers to a multilink subnet, where the PLC devices all share the same address prefix πŸ’œ.

the star topology is super common in current PLC scenarios ⭐. in single-hop star topologies, communication at the link layer only happens between a PLC device and a PANC. the PANC usually collects data (like a meter reading) from the PLC devices, then concentrates and uploads it through Ethernet or cellular networks (see Figure 5) πŸ”₯. the smart meters send their data over PLC, a concentrator aggregates it, and it gets sent to the utility and then to a Meter Data Management System for storage, analysis, and billing πŸ’…. this topology has been widely applied in smart meter deployments, especially in apartment buildings 🏒.

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

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

          Figure 5: PLC Star Network Connected to the Internet

a tree topology is useful when the distance between a device A and the PANC is beyond the PLC-allowed limit, and there's another device B in between that can talk to both sides 🌳. device B here is doing double duty as both a PLC device and a Coordinator, which is very main character energy πŸ‘‘. for this scenario, the link-layer communications happen between device A and device B, and between device B and the PANC. here's a PLC tree network (see Figure 6) 🧚. this topology can be applied in smart street lighting, where the lights adjust their brightness to save energy while sensors on the street lights report things like light intensity, temperature, and humidity πŸ’‘. the data-transmission distance in street lighting is normally above several kilometers, so a PLC tree network is required πŸ™Œ. a more sophisticated AMI network may also be built into the tree topology depicted in [RFC8036] πŸ¦‹. a tree topology suits AMI scenarios that need large coverage but low density, like smart meters in rural areas 🌾. and RPL is suitable for maintaining a tree topology where there's no need for devices to communicate directly with each other 🫢.

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

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

         Figure 6: PLC Tree Network Connected to the Internet

mesh networking in PLC has so many potential applications and has been studied for years πŸ•ΈοΈ. by connecting all nodes with their neighbors in communication range (see Figure 7), a mesh topology seriously boosts communication efficiency and expands how big PLC networks can get πŸ“ˆ. a simple use case is the smart home, where the ON/OFF state of the air conditioning is controlled by the state of the home lights (ON/OFF) and doors (OPEN/CLOSE) 🏠. AODV-RPL [AODV-RPL] lets PLC devices talk directly to each other without having to send frames through the PANC, which is a requirement often cited for AMI infrastructure πŸ’œ.

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

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

         Figure 7: PLC Mesh Network Connected to the Internet

6. Operations and Manageability Considerations πŸ› οΈ

okay real talk, constrained PLC networks are NOT managed the same way as enterprise networks or carrier networks πŸ™…β€β™€οΈ. like the other IoT networks, they're designed to be self-organized and self-managed πŸ€–. the software or firmware gets flashed into the devices before deployment by the vendor or operator πŸ“¦. then during deployment the devices get bootstrapped, and no extra configuration is needed to get them connected to each other ✨. once a device goes 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 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 one's short and sweet: this document has no IANA actions 🌸.

8. Security Considerations πŸ”

ok this section is serious, bestie, so buckle up 😭. due to the high accessibility of power grids, PLC might be susceptible to eavesdropping within its communication coverage. like, one apartment tenant may have the chance to monitor the other smart meters in the same building πŸ‘€. link-layer security mechanisms, such as payload encryption and device authentication, are designed into the PLC technologies mentioned in this document πŸ›‘οΈ. but also, an on-path malicious PLC device could eavesdrop on or modify packets sent through it if appropriate confidentiality and integrity mechanisms are not implemented πŸ’€.

malicious PLC devices could paralyze the whole network with DoS attacks, like by constantly joining and leaving the network or by sending multicast routing messages with fake metrics 😱. a device may also accidentally join a wrong or even malicious network, which exposes its data to bad actors πŸ™ˆ. when a device talks to something outside the PLC network, the traffic has to go through the PANC, so the PANC must be a trusted entity πŸ‘‘. the PLC network also has to stop malicious devices from joining in the first place 🚫. so mutual authentication between the PLC network and a new device is important, and it can happen during the new device's onboarding process 🫢. methods include protocols like the TLS/DTLS Profile [RFC7925] (which exchanges 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 help with authentication) πŸ”‘. it's also possible to use Extensible Authentication Protocol (EAP) methods, like the one defined in [RFC9140], via transports such as Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] 🧩. no specific mechanism is specified by this document, since the right one depends on the deployment circumstances πŸ€·β€β™€οΈ.

in some cases PLC devices get deployed in uncontrolled places, where someone could physically access them and compromise them via key extraction 😬. a compromised device may still be able to join the network, since its credentials are still valid πŸ’”. when group-shared symmetric keys are used in the network, it gets even worse, since the whole network or a large part of it is at risk 🚨. so in scenarios where physical attacks are considered relatively highly possible, per-device credentials SHOULD be used πŸ”’. additional end-to-end security services are also complementary to the network-side security mechanisms πŸ’œ. for example, say a device is compromised and has joined the network, then claims to be the PANC and tries to make the rest of the devices join its network 😈. in that situation, the real PANC can send an alarm to the operator so they can acknowledge the risk πŸ“£. other behavior-analysis mechanisms can also be deployed to recognize malicious PLC devices by inspecting the packets and the data πŸ•΅οΈβ€β™€οΈ.

IP addresses can be used to track devices on the Internet, and those devices can often be linked back to individuals and their activities πŸ‘€. depending on the application and the actual use pattern, that may be undesirable πŸ˜’. to make tracking harder, globally unique and non-changing characteristics of IP addresses should be avoided, for example 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 😱. the effective way to deal with these threats is to have enough entropy in the IID compared to the link lifetime 🧠. here's a quick example: consider a PLC network with 1024 devices and a link lifetime of 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 address scans πŸ™ˆ. so, 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 changes, the IPv6 addresses can be changed as well πŸ”„. other schemes can enhance IID privacy too: a 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 πŸ’–.

9. References πŸ“š

9.1. Normative References

Okay bestie, this is the must-read pile πŸ“šβœ¨ These are the refs the spec actually leans on, no cap.

9.2. Informative References

Now the extra reading list 🧚 These are the "ooh, go deeper" ones, and they're not strictly required to get the spec.

Acknowledgements 🫢

Huge shoutout to everyone who helped out. 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. Iconic squad, all of you πŸ’œ

Authors' Addresses πŸ’–

Meet the authors, the brains behind it all πŸ§ πŸŽ€

Jianqiang Hou
Huawei Technologies
101 Software Avenue,
Nanjing
210012
China
Email: houjianqiang@huawei.com


Bing Liu
Huawei Technologies
Haidian District
No. 156 Beiqing Rd.
Beijing
100095
China
Email: remy.liubing@huawei.com


Yong-Geun Hong
Daejeon University
Dong-gu
62 Daehak-ro
Daejeon
34520
Republic of Korea
Email: yonggeun.hong@gmail.com


Xiaojun Tang
State Grid Electric Power Research Institute
19 Chengxin Avenue
Nanjing
211106
China
Email: itc@sgepri.sgcc.com.cn


Charles E. Perkins
Lupin Lodge
Email: charliep@computer.org
πŸ“¦ where this page comes from