< draft-ietf-6lo-plc-06.txt   draft-ietf-6lo-plc-07.txt >
6Lo Working Group J. Hou 6Lo Working Group J. Hou
Internet-Draft B. Liu Internet-Draft B. Liu
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: October 22, 2021 Y-G. Hong Expires: July 2, 2022 Y-G. Hong
ETRI Daejeon University
X. Tang X. Tang
SGEPRI SGEPRI
C. Perkins C. Perkins
Lupin Lodge Lupin Lodge
April 20, 2021 December 29, 2021
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-06 draft-ietf-6lo-plc-07
Abstract Abstract
Power Line Communication (PLC), namely using the electric-power lines Power Line Communication (PLC), namely using the electric-power lines
for indoor and outdoor communications, has been widely applied to for indoor and outdoor communications, has been widely applied to
support Advanced Metering Infrastructure (AMI), especially smart support Advanced Metering Infrastructure (AMI), especially smart
meters for electricity. The inherent advantage of existing meters for electricity. The existing electricity infrastructure
electricity infrastructure facilitates the expansion of PLC facilitates the expansion of PLC deployments due to its potential
deployments, and moreover, a wide variety of accessible devices advantages in terms of cost and convenience. Moreover, a wide
raises the potential demand of IPv6 for future applications. This variety of accessible devices raises the potential demand of IPv6 for
document describes how IPv6 packets are transported over constrained future applications. This document describes how IPv6 packets are
PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. transported over constrained PLC networks, such as ITU-T G.9903, IEEE
1901.1 and IEEE 1901.2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 22, 2021. This Internet-Draft will expire on July 2, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . . 3 2. Requirements Notation and Terminology . . . . . . . . . . . . 3
3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5
3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6
3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6
3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7
4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 8 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9
4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9
4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T
G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12
4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 13
5. Internet Connectivity Scenarios and Topologies . . . . . . . 13 5. Internet Connectivity Scenarios and Topologies . . . . . . . 14
6. Operations and Manageability Considerations . . . . . . . . . 16 6. Operations and Manageability Considerations . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Consideration . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The idea of using power lines for both electricity supply and The idea of using power lines for both electricity supply and
communication can be traced back to the beginning of the last communication can be traced back to the beginning of the last
century. With the advantage of existing power grid, Power Line century. Using the existing power grid to transmit messages, Power
Communication (PLC) is a good candidate for supporting various Line Communication (PLC) is a good candidate for supporting various
service scenarios such as in houses and offices, in trains and service scenarios such as in houses and offices, in trains and
vehicles, in smart grid and advanced metering infrastructure (AMI) vehicles, in smart grid and advanced metering infrastructure (AMI)
[SCENA]. The data acquisition devices in these scenarios share [SCENA]. The data acquisition devices in these scenarios share
common features such as fixed position, large quantity, low data rate common features such as fixed position, large quantity, low data rate
and low power consumption. and low power consumption.
Although PLC technology has evolved over several decades, it has not Although PLC technology has evolved over several decades, it has not
been fully adapted for IPv6 based constrained networks. The been fully adapted for IPv6-based constrained networks. The
resource-constrained IoT related scenarios lie in the low voltage PLC resource-constrained IoT-related scenarios lie in the low voltage PLC
networks with most applications in the area of Advanced Metering networks with most applications in the area of Advanced Metering
Infrastructure (AMI), Vehicle-to-Grid communications, in-home energy Infrastructure (AMI), Vehicle-to-Grid communications, in-home energy
management and smart street lighting. IPv6 is important for PLC management, and smart street lighting. IPv6 is important for PLC
networks, due to its large address space and efficent address auto- networks, due to its large address space and efficient address auto-
configuration. configuration.
This document provides a brief overview of PLC technologies. Some of This document provides a brief overview of PLC technologies. Some of
them have LLN (low power and lossy network) characteristics, i.e. them have LLN (low power and lossy network) characteristics, i.e.,
limited power consumption, memory and processing resources. This limited power consumption, memory and processing resources. This
document specifies the transmission of IPv6 packets over those document specifies the transmission of IPv6 packets over those
"constrained" PLC networks. The general approach is to adapt "constrained" PLC networks. The general approach is to adapt
elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area
Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes) Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes)
specifications, such as [RFC4944], [RFC6282], [RFC6775] and [RFC8505] specifications, such as [RFC4944], [RFC6282], [RFC6775] and [RFC8505]
to constrained PLC networks. to constrained PLC networks.
2. Requirements Notation and Terminology 2. Requirements Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the following acronyms and terminologies: This document uses the following acronyms and terminologies:
6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
6lo: IPv6 over Networks of Resource-constrained Nodes 6lo: IPv6 over Networks of Resource-constrained Nodes
6LR: 6LoWPAN Router
AMI: Advanced Metering Infrastructure AMI: Advanced Metering Infrastructure
BBPLC: Broadband Power Line Communication BBPLC: Broadband Power Line Communication
CID: Context ID
Coordinator: A device capable of relaying messages. Coordinator: A device capable of relaying messages
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
EV: Electric Vehicle
IID: IPv6 Interface Identifier IID: IPv6 Interface Identifier
IPHC: IP Header Compression
LAN: Local Area Network
LLN: Low power and Lossy Network LLN: Low power and Lossy Network
MSDU: MAC Service Data Unit
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
NBPLC: Narrowband Power Line Communication NBPLC: Narrowband Power Line Communication
OFDM: Orthogonal Frequency Division Multiplexing PAN: Personal Area Network
PANC: PAN Coordinator, a coordinator which also acts as the primary PANC: PAN Coordinator, a coordinator which also acts as the primary
controller of a PAN. controller of a PAN
PLC: Power Line Communication PLC: Power Line Communication
PLC device: An entity that follows the PLC standards and implements PLC device: An entity that follows the PLC standards and implements
the protocol stack described in this draft. the protocol stack described in this draft
PSDU: PHY Service Data Unit
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RA: Router Advertisement RA: Router Advertisement
WAN: Wide Area Network
The terminology used in this draft is aligned with IEEE 1901.2 The terminology used in this draft is aligned with IEEE 1901.2
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document | | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document |
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| PAN | Central | PAN Coordinator | PAN | | PAN | Central | PAN Coordinator | PAN |
| Coordinator | Coordinator | | Coordinator | | Coordinator | Coordinator | | Coordinator |
| | | | | | | | | |
| Coordinator | Proxy | Full-function | Coordinator | | Coordinator | Proxy | Full-function | Coordinator |
| | Coordinator | device | | | | Coordinator | device | |
| | | | | | | | | |
| Device | Station | PAN Device | PLC Device | | Device | Station | PAN Device | PLC Device |
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
Table 1: Terminology Mapping between PLC standards Table 1: Terminology Mapping between PLC standards
3. Overview of PLC 3. Overview of PLC
PLC technology enables convenient two-way communications for home PLC technology enables convenient two-way communications for home
users and utility companies to monitor and control electric plugged users and utility companies to monitor and control electric plugged
devices such as electricity meters and street lights. Due to the devices such as electricity meters and street lights. PLC can also
large range of communication frequencies, PLC is generally classified be used in smart home scenarios, such as the control of indoor lights
into two categories: Narrowband PLC (NBPLC) for automation of sensors and switches. Due to the large range of communication frequencies,
(which have low frequency band and low power cost), and Broadband PLC PLC is generally classified into two categories: Narrowband PLC
(BBPLC) for home and industry networking applications. (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 MAC and PHY layers for Various standards have been addressed on the MAC and PHY layers for
this communication technology, e.g., BBPLC (1.8-250 MHz) including this communication technology, e.g., BBPLC (1.8-250 MHz) including
IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T
G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904
(PRIME), IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME (PRIME), IEEE 1901.2 [IEEE_1901.2] (a combination of G3-PLC and PRIME
PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2).
A new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at the A new PLC standard IEEE 1901.1 [IEEE_1901.1], which is aimed at the
medium frequency band of less than 12 MHz, has been published by the medium frequency band of less than 12 MHz, has been published by the
IEEE standard for Smart Grid Powerline Communication Working Group IEEE standard for Smart Grid Powerline Communication Working Group
(SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus
communication range, and is thus a promising option for 6lo communication range, and is thus a promising option for 6lo
applications. applications.
This specification is focused on IEEE 1901.1, IEEE 1901.2 and ITU-T This specification is focused on IEEE 1901.1, IEEE 1901.2, and ITU-T
G.9903. G.9903.
3.1. Protocol Stack 3.1. Protocol Stack
The protocol stack for IPv6 over PLC is illustrated in Figure 1. The The protocol stack for IPv6 over PLC is illustrated in Figure 1. The
PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T
G.9903. The 6lo adaptation layer for PLC is illustrated in G.9903. The 6lo adaptation layer for PLC is illustrated in
Section 4. For multihop tree and mesh topologies, a routing protocol Section 4. For multihop tree and mesh topologies, a routing protocol
is likely to be necessary. The routes can be built in mesh-under 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 mode at layer 2 or in route-over mode at layer-3, as explained in
Section 3.4. Section 3.4.
+----------------------------------------+ +----------------------------------------+
| Application Layer | | Application Layer |
+----------------------------------------+ +----------------------------------------+
| TCP/UDP | | Transport Layer |
+----------------------------------------+ +----------------------------------------+
| | | |
| IPv6 | | IPv6 |
| | | |
+----------------------------------------+ +----------------------------------------+
| Adaptation layer for IPv6 over PLC | | Adaptation layer for IPv6 over PLC |
+----------------------------------------+ +----------------------------------------+
| PLC MAC Layer | | PLC MAC Layer |
+----------------------------------------+ +----------------------------------------+
| PLC PHY Layer | | PLC PHY Layer |
+----------------------------------------+ +----------------------------------------+
Figure 1: PLC Protocol Stack Figure 1: PLC Protocol Stack
3.2. Addressing Modes 3.2. Addressing Modes
Each PLC device has a globally unique long address of 48-bit Each PLC device has a globally unique long address of 48-bits
([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short ([IEEE_1901.1]) or 64-bits ([IEEE_1901.2], [ITU-T_G.9903]) and a
address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], short address of 12-bits ([IEEE_1901.1]) or 16-bits ([IEEE_1901.2],
[ITU-T_G.9903]). The long address is set by the manufacturer [ITU-T_G.9903]). The long address is set by the manufacturer
according to the IEEE EUI-48 MAC address or the IEEE EUI-64 address. 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 Each PLC device joins the network by using the long address and
communicates with other devices by using the short address after communicates with other devices by using the short address after
joining the network. Short addresses can be assigned during the joining the network. Short addresses can be assigned during the
onboarding process, by the PANC or the JRC (join registrar/ onboarding process, by the PANC or the JRC (join registrar/
coordinator) in CoJP (Constrained Join Protocol) coordinator) in CoJP (Constrained Join Protocol)
[I-D.ietf-6tisch-minimal-security]. [I-D.ietf-6tisch-minimal-security].
3.3. Maximum Transmission Unit 3.3. Maximum Transmission Unit
The Maximum Transmission Unit (MTU) of the MAC layer determines The Maximum Transmission Unit (MTU) of the MAC layer determines
whether fragmentation and reassembly are needed at the adaptation whether fragmentation and reassembly are needed at the adaptation
layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or
greater; thus for a MAC layer with MTU lower than this limit, greater; thus for a MAC layer with MTU lower than this limit,
fragmentation and reassembly at the adaptation layer are required. 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.1 MAC supports upper layer packets up to 2031 octets.
The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the The IEEE 1901.2 MAC layer supports an MTU of 1576 octets (the
original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]). original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]).
Though these two technologies can support IPv6 originally without
Though these two technologies can support IPv6 natively without
fragmentation and reassembly, it is possible to configure a smaller fragmentation and reassembly, it is possible to configure a smaller
MTU in high-noise communication environment. Thus the 6lo functions, MTU in high-noise communication environment. Thus the 6lo functions,
including header compression, fragmentation and reassembly, are still including header compression, fragmentation and reassembly, are still
applicable and useful. applicable and useful.
The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting
IPv6's MTU. For this reason, fragmentation and reassembly is IPv6's MTU. For this reason, fragmentation and reassembly is
required for G.9903-based networks to adapt IPv6. required for G.9903-based networks to carry IPv6.
3.4. Routing Protocol 3.4. Routing Protocol
Routing protocols suitable for use in PLC networks include: Routing protocols suitable for use in PLC networks include:
o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] is a layer-3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl]
updates RPL to include reactive, point-to-point, and asymmetric updates RPL to include reactive, point-to-point, and asymmetric
routing. IEEE 1901.2 specifies Information Elements (IEs) with routing. IEEE 1901.2 specifies Information Elements (IEs) with
MAC layer metrics, which can be provided to L3 routing protocol MAC layer metrics, which can be provided to L3 routing protocol
for parent selection. for parent selection.
o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 o IEEE 1901.1 supports the mesh-under routing scheme. Each PLC node
routing table, in which each route entry comprises the short maintains a routing table, in which each route entry comprises the
addresses of the destination and the related next hop. The route short addresses of the destination and the related next hop. The
entries are built during the network establishment via a pair of route entries are built during the network establishment via a
association request/confirmation messages. The route entries can pair of association request/confirmation messages. The route
be changed via a pair of proxy change request/confirmation entries can be changed via a pair of proxy change request/
messages. These association and proxy change messages must be confirmation messages. These association and proxy change
approved by the central coordinator (PANC in this document). messages must be approved by the central coordinator (PANC in this
document).
o LOADng is a reactive protocol operating at layer 2 or layer 3. o LOADng (The Lightweight On-demand Ad hoc Distance vector routing
Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and protocol, Next Generation) is a reactive protocol operating at
the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based layer-2 or layer-3. Currently, LOADng is supported in ITU-T
networks. G.9903 [ITU-T_G.9903], and the IEEE 1901.2 standard refers to
ITU-T G.9903 for LOAD-based networks.
4. IPv6 over PLC 4. IPv6 over PLC
6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and 6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and
[RFC8505] provides useful functionality including link-local IPv6 [RFC8505] provide useful functionality including link-local IPv6
addresses, stateless address auto-configuration, neighbor discovery, addresses, stateless address auto-configuration, neighbor discovery,
header compression, fragmentation and reassembly. However, due to header compression, fragmentation, and reassembly. However, due to
the different characteristics of the PLC media, the 6LoWPAN the different characteristics of the PLC media, the 6LoWPAN
adaptation layer, as it is, cannot perfectly fulfill the requirements adaptation layer, as it is, cannot perfectly fulfill the requirements
of PLC environments. These considerations suggest the need for a of PLC environments. These considerations suggest the need for a
dedicated adaptation layer for PLC, which is detailed in the dedicated adaptation layer for PLC, which is detailed in the
following subsections. following subsections.
4.1. Stateless Address Autoconfiguration 4.1. Stateless Address Autoconfiguration
To obtain an IPv6 Interface Identifier (IID), a PLC device performs To obtain an IPv6 Interface Identifier (IID), a PLC device performs
stateless address autoconfiguration [RFC4944]. The autoconfiguration stateless address autoconfiguration [RFC4944]. The autoconfiguration
can be based on either a long or short link-layer address. 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 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 identifier [EUI-64]. A 48-bit MAC address MUST first be extended to
a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth
octets as specified in [RFC2464]. The IPv6 IID is derived from the octets as specified in [RFC2464]. The IPv6 IID is derived from the
64-bit Interface ID by inverting the U/L bit [RFC4291]. 64-bit Interface ID by inverting the U/L bit [RFC4291].
For IEEE 1901.2 and ITU-T G.9903, a 48-bit "pseudo-address" is formed 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. 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 Interface ID MUST be derived by inserting 16-bit Then, the 64-bit Interface ID MUST be derived by inserting 16-bit
0xFFFE into as follows: 0xFFFE into as follows:
16_bit_PAN:00FF:FE00:16_bit_short_address 16_bit_PAN:00FF:FE00:16_bit_short_address
For the 12-bit short addresses used by IEEE 1901.1, the 48-bit For the 12-bit short addresses used by IEEE 1901.1, the 48-bit
pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY), pseudo-address is formed by 24-bit NID (Network IDentifier, YYYYYY),
12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX). 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX) as
follows:
YYYY:YY00:0XXX
The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE The 64-bit Interface ID MUST be derived by inserting 16-bit 0xFFFE
into this 48-bit pseudo-address as follows: into this 48-bit pseudo-address as follows:
YYYY:YYFF:FE00:0XXX YYYY:YYFF:FE00:0XXX
Since the derived Interface ID is not global, the "Universal/Local" As investigated in [RFC7136], besides [RFC4291], some other IID
(U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both generation methods defined in IETF do not imply any semantics for the
be set to zero. In order to avoid any ambiguity in the derived "Universal/Local" (U/L) bit (bit 6) and the Individual/Group bit (bit
7), so that these two bits are not reliable indicators for their
original meanings. Thus when using an IID derived by a short
address, the operators of the PLC network can choose to comply with
original meaning of these two bits or not. If so, since the IID
derived from the short address is not global, these two bits MUST
both be set to zero. In order to avoid any ambiguity in the derived
Interface ID, these two bits MUST NOT be used to generate the PANID Interface ID, these two bits MUST NOT be used to generate the PANID
(for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In
other words, the PANID or NID MUST always be chosen so that these other words, the PANID or NID MUST always be chosen so that these
bits are zeros. bits are zeros. If not, 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.
For privacy reasons, the IID derived from the MAC address SHOULD only For privacy reasons, the IID derived from the MAC address (with
be used for link-local address configuration. A PLC host SHOULD use padding and bits flipping) SHOULD only be used for link-local address
the IID derived from the link-layer short address to configure the configuration. A PLC host SHOULD use the IID derived from the link-
IPv6 address used for communication with the public network; layer short address to configure IPv6 addresses used for
otherwise, the host's MAC address is exposed. As per [RFC8065], when communication with the public network; otherwise, the host's MAC
short addresses are used on PLC links, a shared secret key or version address is exposed. As per [RFC8065], when short addresses are used
number from the Authoritative Border Router Option [RFC6775] can be on PLC links, a shared secret key or version number from the
used to improve the entropy of the hash input, thus the generated IID Authoritative Border Router Option [RFC6775] can be used to improve
can be spread out to the full range of the IID address space while the entropy of the hash input, thus the generated IID can be spread
stateless address compression is still allowed. out to the full range of the IID address space while stateless
address compression is still allowed. The hash algorithm by default
of the implementations SHOULD be SHA256, using the version number,
the PANID/NID and the short address as the input arguments, and the
256-bits hash output is truncated into the IID by taking the high 64
bits.
4.2. IPv6 Link Local Address 4.2. IPv6 Link Local Address
The IPv6 link-local address [RFC4291] for a PLC interface is formed 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 by appending the IID, as defined above, to the prefix FE80::/64 (see
Figure 2). Figure 2).
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier | |1111111010| (zeros) | Interface Identifier |
skipping to change at page 10, line 15 skipping to change at page 10, line 30
Length: The length of this option (including type and length fields) 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 in units of 8 octets. The value of this field is 1 for the
12-bit IEEE 1901.1 PLC short addresses. 12-bit IEEE 1901.1 PLC short addresses.
NID: 24-bit Network IDentifier NID: 24-bit Network IDentifier
Padding: 12 zero bits Padding: 12 zero bits
TEI: 12-bit Terminal Equipment Identifier TEI: 12-bit Terminal Equipment Identifier
In order to avoid the possibility of duplicated IPv6 addresses, the
value of the NID MUST be chosen so that the 7th and 8th bits of the
first byte of the NID are both zero.
4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T G.9903
The Source/Target Link-layer Address options for IEEE_1901.2 and The Source/Target Link-layer Address options for IEEE_1901.2 and
ITU-T G.9903 used in the Neighbor Solicitation and Neighbor ITU-T G.9903 used in the Neighbor Solicitation and Neighbor
Advertisement have the following form. Advertisement have the following form.
0 1 2 3 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 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 | | Type | Length=1 | PAN ID |
skipping to change at page 10, line 50 skipping to change at page 11, line 15
Length: The length of this option (including type and length fields) 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 in units of 8 octets. The value of this field is 1 for the
16-bit IEEE 1901.2 PLC short addresses. 16-bit IEEE 1901.2 PLC short addresses.
PAN ID: 16-bit PAN IDentifier PAN ID: 16-bit PAN IDentifier
Padding: 16 zero bits Padding: 16 zero bits
Short Address: 16-bit short address Short Address: 16-bit short address
In order to avoid the possibility of duplicated IPv6 addresses, the
value of the PAN ID MUST be chosen so that the 7th and 8th bits of
the first byte of the PAN ID are both zero.
4.4. Neighbor Discovery 4.4. Neighbor Discovery
Neighbor discovery procedures for 6LoWPAN networks are described in Neighbor discovery procedures for 6LoWPAN networks are described in
Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505]. Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505].
These optimizations support the registration of sleeping hosts. These optimizations support the registration of sleeping hosts.
Although PLC devices are electrically powered, sleeping mode SHOULD Although PLC devices are electrically powered, sleeping mode SHOULD
still be used for power saving. still be used for power saving.
For IPv6 address prefix dissemination, Router Solicitations (RS) and For IPv6 prefix dissemination, Router Solicitations (RS) and Router
Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC Advertisements (RA) MAY be used as per [RFC6775]. If the PLC network
network uses route-over, the IPv6 prefix MAY be disseminated by the uses route-over, the IPv6 prefix MAY be disseminated by the layer-3
layer 3 routing protocol, such as RPL, which may includes the prefix routing protocol, such as RPL, which may include the prefix in the
in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is DIO (DODAG Information Object) message. As per [RFC9010], it is
possible to have PLC devices configured as RPL-unaware-leaves, which possible to have PLC devices configured as RPL-unaware-leaves, which
do not participate to RPL at all, along with RPL-aware PLC devices. 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. In this case, the prefix dissemination SHOULD use the RS/RA messages.
For context information dissemination, Router Advertisements (RA) For context information dissemination, Router Advertisements (RA)
MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST 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 be included in the RA to disseminate the Context IDs used for prefix
and/or address compression. and/or address compression.
For address registration in route-over mode, a PLC device MUST For address registration in route-over mode, a PLC device MUST
register its addresses by sending unicast link-local Neighbor register its addresses by sending a unicast link-local Neighbor
Solicitation to the 6LR. If the registered address is link-local, Solicitation to the 6LR. If the registered address is link-local,
the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR).
Otherwise, the address MUST be registered via an ARO or EARO included Otherwise, the address MUST be registered via an ARO or EARO included
in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505
compliant PLC devices, the 'R' flag in the EARO MUST be set when compliant PLC devices, the 'R' flag in the EARO MUST be set when
sending Neighbor Solicitaitons in order to extract the status sending Neighbor Solicitations in order to extract the status
information in the replied Neighbor Advertisements from the 6LR. If information in the replied Neighbor Advertisements from the 6LR. If
DHCPv6 is used to assign addresses or the IPv6 address is derived DHCPv6 is used to assign addresses or the IPv6 address is derived
from unique long or short link layer address, Duplicate Address from unique long or short link layer address, Duplicate Address
Detection (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be Detection (DAD) SHOULD NOT be utilized. Otherwise, the DAD MUST be
performed at the 6LBR (as per [RFC6775]) or proxied by the routing performed at the 6LBR (as per [RFC6775]) or proxied by the routing
registrar (as per [RFC8505]). The registration status is feedbacked registrar (as per [RFC8505]). The registration status is fed back
via the DAC or EDAC message from the 6LBR and the Neighbor via the DAC or EDAC message from the 6LBR and the Neighbor
Advertisement (NA) from the 6LR. Advertisement (NA) from the 6LR. The section 6 of [RFC8505] how
RFC6775-only devices work with RFC8505-updated devices.
For address registration in mesh-under mode, since all the PLC For address registration in mesh-under mode, since all the PLC
devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC
messages are not required. A PLC device MUST register its addresses messages are not required. A PLC device MUST register its addresses
by sending a unicast NS message with an ARO or EARO. The by sending a unicast NS message with an ARO or EARO. The
registration status is feedbacked via the NA message from the 6LBR. registration status is fed back via the NA message from the 6LBR.
4.5. Header Compression 4.5. Header Compression
The compression of IPv6 datagrams within PLC MAC frames refers to The compression of IPv6 datagrams within PLC MAC frames refers to
[RFC6282], which updates [RFC4944]. Header compression as defined in [RFC6282], which updates [RFC4944]. Header compression as defined in
[RFC6282] which specifies the compression format for IPv6 datagrams [RFC6282] which specifies the compression format for IPv6 datagrams
on top of IEEE 802.15.4, is the basis for IPv6 header compression in on top of IEEE 802.15.4, is the basis for IPv6 header compression in
PLC. For situations when PLC MAC MTU cannot support the 1280-octet PLC. For situations when PLC MAC MTU cannot support the 1280-octet
IPv6 packet, headers MUST be compressed according to [RFC6282] IPv6 packet, headers MUST be compressed according to [RFC6282]
encoding formats. encoding formats, including the Dispatch Header, the LOWPAN_IPHC and
the compression residu carried in-line.
For IEEE 1901.2 and G.9903, the IP header compression follows the For IEEE 1901.2 and G.9903, the IP header compression follows the
instruction in [RFC6282]. However, additional adaptation MUST be instruction in [RFC6282]. However, additional adaptation MUST be
considered for IEEE 1901.1 since it has a short address of 12 bits 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 instead of 16 bits. The only modification is the semantics of the
"Source Address Mode" when set as "10" in the section 3.1 of "Source Address Mode" and the "Dstination Address Mode" when set as
[RFC6282], which is illustrated as following. "10" in the section 3.1 of [RFC6282], which is illustrated as
following.
SAM: Source Address Mode: SAM: Source Address Mode:
If SAC=0: Stateless compression If SAC=0: Stateless compression
10: 12 bits. The first 116 bits of the address are elided.The 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 value of the first 64 bits is the link-local prefix padded with
zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where
XXX are the 12 bits carried in-line. 0XXX are the 16 bits carried in-line.
If SAC=1: stateful context-based compression If SAC=1: stateful context-based compression
10: 12 bits. The address is derived using context information and 10: 16 bits. The address is derived using context information and
the 12 bits carried in-line. Bits covered by context the 16 bits carried in-line. Bits covered by context
information are always used. Any IID bits not covered by information are always used. Any IID bits not covered by
context information are taken directly from their corresponding context information are taken directly from their corresponding
bits in the 12-bit to IID mapping given by 0000:00ff:fe00:0XXX, bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX,
where XXX are the 12 bits carried inline. Any remaining bits where 0XXX are the 16 bits carried inline. Any remaining bits
are zero. 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 in-line.
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 in-line. 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 16-bit to IID mapping given by 0000:00ff:fe00:0XXX,
where XXXX are the 16 bits carried in- line. Any remaining
bits are zero.
4.6. Fragmentation and Reassembly 4.6. Fragmentation and Reassembly
Constrained PLC MAC layer provides the function of fragmentation and The constrained PLC MAC layer provides the function of fragmentation
reassembly, however, fragmentation and reassembly is still required and reassembly. However, fragmentation and reassembly is still
at the adaptation layer, if the MAC layer cannot support the minimum required at the adaptation layer, if the MAC layer cannot support the
MTU demanded by IPv6, which is 1280 octets. minimum MTU demanded by IPv6, which is 1280 octets.
In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as 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 big as 2031 octets and 1576 octets respectively. However, when the
channel condition is noisy, it is possible to configure smaller MTU channel condition is noisy, smaller packets have higher transmission
at the MAC layer. If the configured MTU is smaller than 1280 success rate, the operator can choose to configure smaller MTU at the
octects, the fragmentation and reassembly defined in [RFC4944] MUST MAC layer. If the configured MTU is smaller than 1280 octets, the
be used. fragmentation and reassembly defined in [RFC4944] MUST be used.
In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 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, so to cope with the required MTU of 1280 octets by IPv6,
fragmentation and reassembly at 6lo adaptation layer MUST be provided fragmentation and reassembly at the 6lo adaptation layer MUST be
as specified in [RFC4944]. provided as specified in [RFC4944].
[RFC4944] uses a 16-bit datagram tag to identify the fragments of the [RFC4944] uses a 16-bit datagram tag to identify the fragments of the
same IP packet. [RFC4963] specifies that at high data rates, the same IP packet. [RFC4963] specifies that at high data rates, the
16-bit IP identification field is not large enough to prevent 16-bit IP identification field is not large enough to prevent
frequent incorrectly assembled IP fragments. For constranied PLC, frequent incorrectly assembled IP fragments. For constrained PLC,
the data rate is much lower than the situation mentioned in RFC4963, the data rate is much lower than the situation mentioned in RFC4963,
thus the 16-bit tag is sufficient to assemble the fragements thus the 16-bit tag is sufficient to assemble the fragments
correctly. correctly.
5. Internet Connectivity Scenarios and Topologies 5. Internet Connectivity Scenarios and Topologies
The PLC network model can be simplified to two kinds of network The PLC network model can be simplified to two kinds of network
devices: PAN Coordinator (PANC) and PAN Device. The PANC is the device: PAN Coordinator (PANC) and PLC Device. The PANC is the
primary coordinator of the PLC subnet and can be seen as a master primary coordinator of the PLC subnet and can be seen as a primary
node; PAN Devices are typically PLC meters and sensors. The PANC node; PLC Devices are typically PLC meters and sensors. The address
also serves as the Routing Registrar for proxy registration and DAD registration and DAD features can also be deployed on the PANC, for
procedures, making use of the updated registration procedures in example the 6LBR [RFC6775] or the routing registrar in [RFC8505].
[RFC8505]. IPv6 over PLC networks are built as tree, mesh or star IPv6 over PLC networks are built as trees, meshes or stars topology
according to the use cases. Generally, each PLC network has one according to the use cases. Generally, each PLC network has one
PANC. In some cases, the PLC network can have alternate coordinators PANC. In some cases, the PLC network can have alternate coordinators
to replace the PANC when the PANC leaves the network for some reason. 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 Note that the PLC topologies in this section are based on logical
connectivity, not physical links. The term "PLC subnet" refers to a connectivity, not physical links. The term "PLC subnet" refers to a
multilink subnet, in which the PLC devices share the same address multilink subnet, in which the PLC devices share the same address
prefix. prefix.
The star topology is common in current PLC scenarios. In single-hop The star topology is common in current PLC scenarios. In single-hop
star topologies, communication at the link layer only takes place star topologies, communication at the link layer only takes place
between a PAN Device and a PANC. The PANC typically collects data between a PLC Device and a PANC. The PANC typically collects data
(e.g., a meter reading) from the PAN devices, and then concentrates (e.g., a meter reading) from the PLC devices, and then concentrates
and uploads the data through Ethernet or LPWAN (see Figure 5). The and uploads the data through Ethernet or Cellular networks (see
collected data is transmitted by the smart meters through PLC, Figure 5). The collected data is transmitted by the smart meters
aggregated by a concentrator, sent to the utility and then to a Meter through PLC, aggregated by a concentrator, sent to the utility and
Data Management System for data storage, analysis and billing. This then to a Meter Data Management System for data storage, analysis and
topology has been widely applied in the deployment of smart meters, billing. This topology has been widely applied in the deployment of
especially in apartment buildings. smart meters, especially in apartment buildings.
PLC Device PLC Device PLC Device PLC Device
\ / +--------- \ / +---------
\ / / \ / /
\ / + \ / +
\ / | \ / |
PLC Device ------ PANC ===========+ Internet PLC Device ------ PANC ===========+ Internet
/ \ | / \ |
/ \ + / \ +
/ \ \ / \ \
/ \ +--------- / \ +---------
PLC Device PLC Device PLC Device PLC Device
<----------------------> <---------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
Figure 5: PLC Star Network connected to the Internet Figure 5: PLC Star Network connected to the Internet
A tree topology is useful when the distance between a device A and A tree topology is useful when the distance between a device A and
PANC is beyond the PLC allowed limit and there is another device B in the PANC is beyond the PLC allowed limit and there is another device
between able to communicate with both sides. Device B in this case B in between able to communicate with both sides. Device B in this
acts both as a PAN Device and a Coordinator. For this scenario, the case acts both as a PLC Device and a Coordinator. For this scenario,
link layer communications take place between device A and device B, the link layer communications take place between device A and device
and between device B and PANC. An example of PLC tree network is B, and between device B and PANC. An example of a PLC tree network
depicted in Figure 6. This topology can be applied in the smart is depicted in Figure 6. This topology can be applied in smart
street lighting, where the lights adjust the brightness to reduce street lighting, where the lights adjust the brightness to reduce
energy consumption while sensors are deployed on the street lights to energy consumption while sensors are deployed on the street-lights to
provide information such as light intensity, temperature, humidity. provide information such as light intensity, temperature, and
Data transmission distance in the street lighting scenario is humidity. The data transmission distance in the street lighting
normally above several kilometers thus the PLC tree network is scenario is normally above several kilometers, thus a PLC tree
required. A more sophisticated AMI network may also be constructed network is required. A more sophisticated AMI network may also be
into the tree topology which is depicted in [RFC8036]. A tree constructed into the tree topology which is depicted in [RFC8036]. A
topology is suitable for AMI scenarios that require large coverage tree topology is suitable for AMI scenarios that require large
but low density, e.g., the deployment of smart meters in rural areas. coverage but low density, e.g., the deployment of smart meters in
RPL is suitable for maintenance of a tree topology in which there is rural areas. RPL is suitable for maintenance of a tree topology in
no need for communication directly between PAN devices. which there is no need for communication directly between PAN
devices.
PLC Device PLC Device
\ +--------- \ +---------
PLC Device \ / PLC Device A \ /
\ \ + \ \ +
\ \ | \ \ |
PLC Device -- PANC ===========+ Internet PLC Device B -- PANC ===========+ Internet
/ / | / / |
/ / + / / +
PLC Device---PLC Device / \ PLC Device---PLC Device / \
/ +--------- / +---------
PLC Device---PLC Device PLC Device---PLC Device
<-------------------------> <------------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
Figure 6: PLC Tree Network connected to the Internet Figure 6: PLC Tree Network connected to the Internet
Mesh networking in PLC is of great potential applications and has Mesh networking in PLC is of great potential applications and has
been studied for several years. By connecting all nodes with their been studied for several years. By connecting all nodes with their
neighbors in communication range (see Figure 7), mesh topology neighbors in communication range (see Figure 7), a mesh topology
dramatically enhances the communication efficiency and thus expands dramatically enhances the communication efficiency and thus expands
the size of PLC networks. A simple use case is the smart home 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 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 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL
enables direct PAN device to PAN device communication, without being ([I-D.ietf-roll-aodv-rpl]) enables direct PLC device to PLC device
obliged to transmit frames through the PANC, which is a requirement communication, without being obliged to transmit frames through the
often cited for AMI infrastructure. PANC, which is a requirement often cited for AMI infrastructure.
PLC Device---PLC Device PLC Device---PLC Device
/ \ / \ +--------- / \ / \ +---------
/ \ / \ / / \ / \ /
/ \ / \ + / \ / \ +
/ \ / \ | / \ / \ |
PLC Device--PLC Device---PANC ===========+ Internet PLC Device--PLC Device---PANC ===========+ Internet
\ / \ / | \ / \ / |
\ / \ / + \ / \ / +
\ / \ / \ \ / \ / \
\ / \ / +--------- \ / \ / +---------
PLC Device---PLC Device PLC Device---PLC Device
<-------------------------------> <------------------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
Figure 7: PLC Mesh Network connected to the Internet Figure 7: PLC Mesh Network connected to the Internet
6. Operations and Manageability Considerations 6. Operations and Manageability Considerations
The constrained PLC networks are not managed in the same way as the The constrained PLC networks are not managed in the same way as an
enterprise network or carrier network. The constrained PLC networks enterprise network or a carrier network. Constrained PLC networks,
as the other IoT networks, are designed to be self-organized and like the other IoT networks, are designed to be self-organized and
self-managed. The software or firmware is flushed into the devices self-managed. The software or firmware is flashed into the devices
before deployment by the vendor or operator. And during the before deployment by the vendor or operator. And during the
deployment process, the devices are bootstrapped, and no extra deployment process, the devices are bootstrapped, and no extra
configuration is needed to get the device connected to each other. configuration is needed to get the devices connected to each other.
Once a device becomes offline, it goes back to the bootstrapping Once a device becomes offline, it goes back to the bootstrapping
stage and tries to rejoin the network. The onboard status of the 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 devices and the topology of the PLC network can be visualized via the
gateway. The recently-formed iotops WG in IETF is aming to design PANC. The recently-formed iotops WG in IETF is aiming to identify
more features for the management of IOT networks. 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 7. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
8. Security Consideration 8. Security Considerations
Due to the high accessibility of power grid, PLC might be susceptible Due to the high accessibility of power grids, PLC might be
to eavesdropping within its communication coverage, e.g., one susceptible to eavesdropping within its communication coverage, e.g.,
apartment tenant may have the chance to monitor the other smart one apartment tenant may have the chance to monitor the other smart
meters in the same apartment building. Thus link layer security meters in the same apartment building. Link layer security
mechanisms are designed in the PLC technologies mentioned in this mechanisms, such as payload encryption and devcie authentication, are
document. designed in the PLC technologies mentioned in this document.
Malicious PLC devices could paralyze the whole network via DOS Malicious PLC devices could paralyze the whole network via DOS
attacks, e.g., keep joining and leaving the network frequently, or attacks, e.g., keep joining and leaving the network frequently, or
multicast routing messages containing fake metrics. A device may sending multicast routing messages containing fake metrics. A device
also join a wrong or even malicious network, exposing its data to may also inadvertently join a wrong or even malicious network,
illegal users. Mutual authentication of network and new device can exposing its data to malicious users. When communicating with a
be conducted during the onboarding process of the new device. device outside the PLC network, the traffic has to go through the
Methods include protocols such as [RFC7925] (exchanging pre-installed PANC. Thus the PANC must be a trusted entity. Moreover, the PLC
certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which network must prevent malicious devices to join in the network. Thus
uses pre-shared keys), and Mutual authentication of a PLC network and a new device is important,
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and and it can be conducted during the onboarding process of the new
MASA service). It is also possible to use EAP methods such as device. Methods include protocols such as [RFC7925] (exchanging pre-
[I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security]
specific mechanism is specified by this document as an appropriate (which uses pre-shared keys), and
mechanism will depend upon deployment circumstances. [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (a IoT version of BRSKI,
which uses IDevID and MASA service to facilitate authentication). It
is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob]
via transports like PANA [RFC5191]. No specific mechanism is
specified by this document, as an appropriate mechanism will depend
upon deployment circumstances. In some cases, the PLC devices can be
deployed in uncontrolled places, where the devices may be accessed
physically and be compromised via key extraction. Since the
compromised device may be still able to join in the network since its
credentials are still valide. When group-shared symmetric keys are
used in the network, the consequence is even more severer, i.e., the
whole network or a large part of the network is at risk. Thus in
scenarios where the physical attacks is considered to be relatively
highly possible, per device credentials SHOULD be used. Moreover,
additional end-to-end security services" is a complementary to the
network side security mechanisms, e.g., if a devices is compromised
and it has joined in the network, and then it claims itself as the
PANC and try to make the rest 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 recoginize the malicious PLC devices by inspecting the
packets and the data.
IP addresses may be used to track devices on the Internet; such IP addresses may be used to track devices on the Internet; such
devices can in turn be linked to individuals and their activities. devices can often in turn be linked to individuals and their
Depending on the application and the actual use pattern, this may be activities. Depending on the application and the actual use pattern,
undesirable. To impede tracking, globally unique and non-changing this may be undesirable. To impede tracking, globally unique and
characteristics of IP addresses should be avoided, e.g., by non-changing characteristics of IP addresses should be avoided, e.g.,
frequently changing the global prefix and avoiding unique link-layer by frequently changing the global prefix and avoiding unique link-
derived IIDs in addresses. [RFC8065] discusses the privacy threats layer derived IIDs in addresses. [RFC8065] discusses the privacy
when interface identifiers (IID) are generated without sufficient threats when interface identifiers (IID) are generated without
entropy, including correlation of activities over time, location sufficient entropy, including correlation of activities over time,
tracking, device-specific vulnerability exploitation, and address location tracking, device-specific vulnerability exploitation, and
scanning. Schemes such as limited lease period in DHCPv6 [RFC3315], address scanning. And an effective way to deal with these threats is
Cryptographically Generated Addresses (CGAs) [RFC3972], privacy to have enough entropy in the IID compairing to the link lifetime.
extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or
semantically opaque addresses [RFC7217] SHOULD be considered to Consider a PLC network with 1024 devices and its link lifetime is 8
enhance the IID privacy. 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 suggest in the
section 4.1, a hash function can be used to generate a 64 bits IID.
When the version number of the PLC network is changed, the IPv6
addresses can be changed as well. Other schemes such as limited
lease period in DHCPv6 [RFC8415], Cryptographically Generated
Addresses (CGAs) [RFC3972], Temporary Address Extensions [RFC8981],
Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque
addresses [RFC7217] SHOULD be used to enhance the IID privacy.
9. Acknowledgements 9. Acknowledgements
We gratefully acknowledge suggestions from the members of the IETF We gratefully acknowledge suggestions from the members of the IETF
6lo working group. Great thanks to Samita Chakrabarti and Gabriel 6lo working group. Great thanks to Samita Chakrabarti and Gabriel
Montenegro for their feedback and support in connecting the IEEE and Montenegro for their feedback and support in connecting the IEEE and
ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney ITU-T sides. The authors thank Scott Mansfield, Ralph Droms, and Pat
for their guidance in the liaison process. Authors wish to thank Kinney for their guidance in the liaison process. The authors wish
Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael to thank Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu, and
Richardson for their valuable comments and contributions. Michael Richardson for their valuable comments and contributions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE_1901.1] [IEEE_1901.1]
IEEE-SA Standards Board, "Standard for Medium Frequency IEEE-SA Standards Board, "Standard for Medium Frequency
(less than 15 MHz) Power Line Communications for Smart (less than 15 MHz) Power Line Communications for Smart
Grid Applications", IEEE 1901.1, May 2018, Grid Applications", IEEE 1901.1, May 2018,
<https://ieeexplore.ieee.org/document/8360785>. <https://ieeexplore.ieee.org/document/8360785>.
skipping to change at page 18, line 14 skipping to change at page 19, line 14
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>. <https://www.rfc-editor.org/info/rfc2464>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
skipping to change at page 19, line 26 skipping to change at page 20, line 32
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-
6tisch-minimal-security-15 (work in progress), December 6tisch-minimal-security-15 (work in progress), December
2019. 2019.
[I-D.ietf-emu-eap-noob] [I-D.ietf-emu-eap-noob]
Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band
authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap-
noob-03 (work in progress), December 2020. noob-06 (work in progress), September 2021.
[I-D.ietf-roll-aodv-rpl] [I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. Anamalamudi, S., Perkins, C. E., Anand, S., and B. Liu,
Liu, "AODV based RPL Extensions for Supporting Asymmetric "Supporting Asymmetric Links in Low Power Networks: AODV-
P2P Links in Low-Power and Lossy Networks", draft-ietf- RPL", draft-ietf-roll-aodv-rpl-11 (work in progress),
roll-aodv-rpl-08 (work in progress), May 2020. September 2021.
[I-D.ietf-roll-unaware-leaves]
Thubert, P. and M. Richardson, "Routing for RPL Leaves",
draft-ietf-roll-unaware-leaves-30 (work in progress),
January 2021.
[IEEE_1901.2a] [IEEE_1901.2a]
IEEE-SA Standards Board, "IEEE Standard for Low-Frequency IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
(less than 500 kHz) Narrowband Power Line Communications (less than 500 kHz) Narrowband Power Line Communications
for Smart Grid Applications - Amendment 1", IEEE 1901.2a, for Smart Grid Applications - Amendment 1", IEEE 1901.2a,
September 2015, <https://standards.ieee.org/findstds/ September 2015, <https://standards.ieee.org/findstds/
standard/1901.2a-2015.html>. standard/1901.2a-2015.html>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007, DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>. <https://www.rfc-editor.org/info/rfc4963>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>. May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
DOI 10.17487/RFC5535, June 2009, DOI 10.17487/RFC5535, June 2009,
<https://www.rfc-editor.org/info/rfc5535>. <https://www.rfc-editor.org/info/rfc5535>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
skipping to change at page 21, line 5 skipping to change at page 21, line 45
[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
Statement for the Routing Protocol for Low-Power and Lossy Statement for the Routing Protocol for Low-Power and Lossy
Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (RPL) in Advanced Metering Infrastructure (AMI)
Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
<https://www.rfc-editor.org/info/rfc8036>. <https://www.rfc-editor.org/info/rfc8036>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[SCENA] Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of [SCENA] Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of
the Art in Power Line Communications: From the the Art in Power Line Communications: From the
Applications to the Medium", July 2016, Applications to the Medium", July 2016,
<https://ieeexplore.ieee.org/document/7467440>. <https://ieeexplore.ieee.org/document/7467440>.
Authors' Addresses Authors' Addresses
Jianqiang Hou Jianqiang Hou
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
skipping to change at page 21, line 29 skipping to change at page 22, line 40
Bing Liu Bing Liu
Huawei Technologies Huawei Technologies
No. 156 Beiqing Rd. Haidian District, No. 156 Beiqing Rd. Haidian District,
Beijing 100095 Beijing 100095
China China
Email: remy.liubing@huawei.com Email: remy.liubing@huawei.com
Yong-Geun Hong Yong-Geun Hong
Electronics and Telecommunications Research Institute Daejeon University
161 Gajeong-Dong Yuseung-Gu 62 Daehak-ro, Dong-gu
Daejeon 305-700 Daejeon 34520
Korea Korea
Email: yghong@etri.re.kr Email: yonggeun.hong@gmail.com
Xiaojun Tang Xiaojun Tang
State Grid Electric Power Research Institute State Grid Electric Power Research Institute
19 Chengxin Avenue 19 Chengxin Avenue
Nanjing 211106 Nanjing 211106
China China
Email: itc@sgepri.sgcc.com.cn Email: itc@sgepri.sgcc.com.cn
Charles E. Perkins Charles E. Perkins
Lupin Lodge Lupin Lodge
 End of changes. 91 change blocks. 
243 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/