< draft-ietf-6lo-plc-05.txt   draft-ietf-6lo-plc-06.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: May 1, 2021 Y-G. Hong Expires: October 22, 2021 Y-G. Hong
ETRI ETRI
X. Tang X. Tang
SGEPRI SGEPRI
C. Perkins C. Perkins
October 28, 2020 Lupin Lodge
April 20, 2021
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-05 draft-ietf-6lo-plc-06
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 inherent advantage of existing
electricity infrastructure facilitates the expansion of PLC electricity infrastructure facilitates the expansion of PLC
deployments, and moreover, a wide variety of accessible devices deployments, and moreover, a wide variety of accessible devices
raises the potential demand of IPv6 for future applications. This raises the potential demand of IPv6 for future applications. This
skipping to change at page 1, line 43 skipping to change at page 1, line 44
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 May 1, 2021. This Internet-Draft will expire on October 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . 7 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 8
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 10 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12
4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12
5. Internet Connectivity Scenarios and Topologies . . . . . . . 13 5. Internet Connectivity Scenarios and Topologies . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Operations and Manageability Considerations . . . . . . . . . 16
7. Security Consideration . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Consideration . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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. With the advantage of existing power grid, Power Line
Communication (PLC) is a good candidate for supporting various 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)
The data acquisition devices in these scenarios share common features [SCENA]. The data acquisition devices in these scenarios share
such as fixed position, large quantity, low data rate and low power common features such as fixed position, large quantity, low data rate
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 6lo been fully adapted for IPv6 based constrained networks. The
related scenarios lie in the low voltage PLC networks with most resource-constrained IoT related scenarios lie in the low voltage PLC
applications in the area of Advanced Metering Infrastructure (AMI), networks with most applications in the area of Advanced Metering
Vehicle-to-Grid communications, in-home energy management and smart Infrastructure (AMI), Vehicle-to-Grid communications, in-home energy
street lighting. IPv6 is important for PLC networks, due to its management and smart street lighting. IPv6 is important for PLC
large address space and efficent address auto-configuration. A networks, due to its large address space and efficent address auto-
comparison among various existing PLC standards is provided to configuration.
facilitate the selection of the most applicable standard in
particular scenarios.
This specification provides a brief overview of PLC technologies. This document provides a brief overview of PLC technologies. Some of
Some of them have LLN characteristics, i.e. limited power them have LLN (low power and lossy network) characteristics, i.e.
consumption, memory and processing resources. This specification is limited power consumption, memory and processing resources. This
focused on the transmission of IPv6 packets over those "constrained" document specifies the transmission of IPv6 packets over those
PLC networks. The general approach is to adapt elements of the "constrained" PLC networks. The general approach is to adapt
6LoWPAN specifications [RFC4944], [RFC6282], [RFC6775] and [RFC8505] elements of the 6LoWPAN (IPv6 over Low-Power Wireless Personal Area
to constrained PLC networks. There was work previously proposed as Network) and 6lo (IPv6 over Networks of Resource-constrained Nodes)
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], which did not specifications, such as [RFC4944], [RFC6282], [RFC6775] and [RFC8505]
reach consensus. This document provides a more structured to constrained PLC networks.
specification than the previous work, expanding to a larger variety
of 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:
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
AMI: Advanced Metering Infrastructure AMI: Advanced Metering Infrastructure
BBPLC: Broadband Power Line Communication BBPLC: Broadband Power Line Communication
CID: Context ID 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 EV: Electric Vehicle
IID: IPv6 Interface Identifier IID: IPv6 Interface Identifier
IPHC: IP Header Compression IPHC: IP Header Compression
LAN: Local Area Network LAN: Local Area Network
LLN: Low power and Lossy Network
MSDU: MAC Service Data Unit 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 OFDM: Orthogonal Frequency Division Multiplexing
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.
skipping to change at page 5, line 22 skipping to change at page 5, line 37
(which have low frequency band and low power cost), and Broadband PLC (which have low frequency band and low power cost), and Broadband PLC
(BBPLC) for home and industry networking applications. (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] (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).
Moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], A new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at the
which aims at the medium frequency band of less than 12 MHz, has been medium frequency band of less than 12 MHz, has been published by the
published by the IEEE standard for Smart Grid Powerline Communication IEEE standard for Smart Grid Powerline Communication Working Group
Working Group (SGPLC WG). IEEE 1901.1 balances the needs for (SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus
bandwidth versus communication range, and is thus a promising option communication range, and is thus a promising option for 6lo
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
skipping to change at page 6, line 48 skipping to change at page 7, line 4
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 the 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 natively 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 as per IPv6's MTU. For this reason, fragmentation and reassembly is
[RFC4944] MUST be enabled for G.9903-based networks. required for G.9903-based networks to adapt 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
skipping to change at page 8, line 38 skipping to change at page 8, line 44
be set to zero. In order to avoid any ambiguity in the derived 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.
For privacy reasons, the IID derived from the MAC address SHOULD only For privacy reasons, the IID derived from the MAC address SHOULD only
be used for link-local address configuration. A PLC host SHOULD use be used for link-local address configuration. A PLC host SHOULD use
the IID derived from the link-layer short address to configure the the IID derived from the link-layer short address to configure the
IPv6 address used for communication with the public network; IPv6 address used for communication with the public network;
otherwise, the host's MAC address is exposed. Implementers should otherwise, the host's MAC address is exposed. As per [RFC8065], when
look at [RFC8064] as well, in order to generate a stable IPv6 address short addresses are used on PLC links, a shared secret key or version
using an opaque IID. number from the Authoritative Border Router Option [RFC6775] can be
used to improve the entropy of the hash input, thus the generated IID
can be spread out to the full range of the IID address space while
stateless address compression is still allowed.
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 12, line 33 skipping to change at page 12, line 43
10: 12 bits. The address is derived using context information and 10: 12 bits. The address is derived using context information and
the 12 bits carried in-line. Bits covered by context the 12 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 12-bit to IID mapping given by 0000:00ff:fe00:0XXX,
where XXX are the 12 bits carried inline. Any remaining bits where XXX are the 12 bits carried inline. Any remaining bits
are zero. are zero.
4.6. Fragmentation and Reassembly 4.6. Fragmentation and Reassembly
PLC differs from other wired technologies in that the communication Constrained PLC MAC layer provides the function of fragmentation and
medium is not shielded; thus, to successfully transmit data through reassembly, however, fragmentation and reassembly is still required
power lines, PLC Data Link layer provides the function of at the adaptation layer, if the MAC layer cannot support the minimum
segmentation and reassembly. A Segment Control Field is defined in MTU demanded by IPv6, which is 1280 octets.
the MAC frame header regardless of whether segmentation is required.
The number of data octets of the PHY payload can change dynamically
based on channel conditions, thus the MAC payload segmentation in the
MAC sublayer is enabled and guarantees a reliable one-hop data
transmission. Fragmentation and reassembly is 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 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, it is possible to configure smaller MTU
at the MAC layer. If the configured MTU is smaller than 1280 at the MAC layer. If the configured MTU is smaller than 1280
octects, the fragmentation and reassembly defined in [RFC4944] MUST octects, the fragmentation and reassembly defined in [RFC4944] MUST
be used. 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 6lo adaptation layer MUST be provided
referring to [RFC4944]. as specified in [RFC4944].
[RFC4944] uses a 16-bit datagram tag to identify the fragments of the
same IP packet. [RFC4963] specifies that at high data rates, the
16-bit IP identification field is not large enough to prevent
frequent incorrectly assembled IP fragments. For constranied PLC,
the data rate is much lower than the situation mentioned in RFC4963,
thus the 16-bit tag is sufficient to assemble the fragements
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 devices: PAN Coordinator (PANC) and PAN 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 master
node; PAN Devices are typically PLC meters and sensors. The PANC node; PAN Devices are typically PLC meters and sensors. The PANC
also serves as the Routing Registrar for proxy registration and DAD also serves as the Routing Registrar for proxy registration and DAD
procedures, making use of the updated registration procedures in procedures, making use of the updated registration procedures in
[RFC8505]. IPv6 over PLC networks are built as tree, mesh or star [RFC8505]. IPv6 over PLC networks are built as tree, mesh or star
skipping to change at page 16, line 5 skipping to change at page 16, line 5
\ / \ / + \ / \ / +
\ / \ / \ \ / \ / \
\ / \ / +--------- \ / \ / +---------
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. IANA Considerations 6. Operations and Manageability Considerations
The constrained PLC networks are not managed in the same way as the
enterprise network or carrier network. The constrained PLC networks
as the other IoT networks, are designed to be self-organized and
self-managed. The software or firmware is flushed into the devices
before deployment by the vendor or operator. And during the
deployment process, the devices are bootstrapped, and no extra
configuration is needed to get the device connected to each other.
Once a device becomes offline, it goes back to the bootstrapping
stage and tries to rejoin the network. The onboard status of 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
more features for the management of IOT networks.
7. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
7. Security Consideration 8. Security Consideration
Due to the high accessibility of power grid, PLC might be susceptible Due to the high accessibility of power grid, PLC might be susceptible
to eavesdropping within its communication coverage, e.g., one to eavesdropping within its communication coverage, e.g., one
apartment tenant may have the chance to monitor the other smart apartment tenant may have the chance to monitor the other smart
meters in the same apartment building. For security consideration, meters in the same apartment building. Thus link layer security
link layer security is guaranteed in every PLC technology. mechanisms are 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 multicast routing messages containing fake metrics. A device may
also join a wrong or even malicious network, exposing its data to also join a wrong or even malicious network, exposing its data to
illegal users. Mutual authentication of network and new device can illegal users. Mutual authentication of network and new device can
be conducted during the onboarding process of the new device. be conducted during the onboarding process of the new device.
Methods include protocols such as [RFC7925] (exchanging pre-installed Methods include protocols such as [RFC7925] (exchanging pre-installed
certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which
uses pre-shared keys), and uses pre-shared keys), and
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and
MASA service). It is also possible to use EAP methods such as MASA service). It is also possible to use EAP methods such as
[I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No
specific mechanism is specified by this document as an appropriate specific mechanism is specified by this document as an appropriate
mechanism will depend upon deployment circumstances. The network mechanism will depend upon deployment circumstances.
encryption key appropriate for the layer-2 can also be acquired
during the onboarding process.
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 in turn be linked to individuals and their activities.
Depending on the application and the actual use pattern, this may be Depending on the application and the actual use pattern, this may be
undesirable. To impede tracking, globally unique and non-changing undesirable. To impede tracking, globally unique and non-changing
characteristics of IP addresses should be avoided, e.g., by characteristics of IP addresses should be avoided, e.g., by
frequently changing the global prefix and avoiding unique link-layer frequently changing the global prefix and avoiding unique link-layer
derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941], derived IIDs in addresses. [RFC8065] discusses the privacy threats
[RFC5535], [RFC7217], and [RFC8065] provide valuable information for when interface identifiers (IID) are generated without sufficient
IID formation with improved privacy, and are RECOMMENDED for IPv6 entropy, including correlation of activities over time, location
networks. tracking, device-specific vulnerability exploitation, and address
scanning. Schemes such as limited lease period in DHCPv6 [RFC3315],
Cryptographically Generated Addresses (CGAs) [RFC3972], privacy
extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or
semantically opaque addresses [RFC7217] SHOULD be considered to
enhance the IID privacy.
8. 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. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney
for their guidance in the liaison process. Authors wish to thank for their guidance in the liaison process. Authors wish to thank
Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael
Richardson for their valuable comments and contributions. Richardson for their valuable comments and contributions.
9. References 10. References
9.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>.
[IEEE_1901.2] [IEEE_1901.2]
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
skipping to change at page 18, line 33 skipping to change at page 19, line 5
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
9.2. Informative References 10.2. Informative References
[EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global [EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global
Identifier (EUI-64) Registration Authority", IEEE EUI-64, Identifier (EUI-64) Registration Authority", IEEE EUI-64,
March 1997, <https://standards.ieee.org/content/dam/ieee- March 1997, <https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>. standards/standards/web/documents/tutorials/eui.pdf>.
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] [I-D.ietf-6tisch-dtsecurity-zerotouch-join]
Richardson, M., "6tisch Zero-Touch Secure Join protocol", Richardson, M., "6tisch Zero-Touch Secure Join protocol",
draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
progress), July 2019. progress), July 2019.
[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. and M. Sethi, "Nimble out-of-band authentication Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band
for EAP (EAP-NOOB)", draft-ietf-emu-eap-noob-02 (work in authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap-
progress), July 2020. noob-03 (work in progress), December 2020.
[I-D.ietf-roll-aodv-rpl] [I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B.
Liu, "AODV based RPL Extensions for Supporting Asymmetric Liu, "AODV based RPL Extensions for Supporting Asymmetric
P2P Links in Low-Power and Lossy Networks", draft-ietf- P2P Links in Low-Power and Lossy Networks", draft-ietf-
roll-aodv-rpl-08 (work in progress), May 2020. roll-aodv-rpl-08 (work in progress), May 2020.
[I-D.ietf-roll-unaware-leaves] [I-D.ietf-roll-unaware-leaves]
Thubert, P. and M. Richardson, "Routing for RPL Leaves", Thubert, P. and M. Richardson, "Routing for RPL Leaves",
draft-ietf-roll-unaware-leaves-22 (work in progress), draft-ietf-roll-unaware-leaves-30 (work in progress),
October 2020. January 2021.
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014.
[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, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
skipping to change at page 20, line 5 skipping to change at page 20, line 18
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [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>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
skipping to change at page 20, line 32 skipping to change at page 20, line 50
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,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[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>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[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>.
[SCENA] Cano, C., Pittolo, A., Malone, D., and L. Lampe, "State of
the Art in Power Line Communications: From the
Applications to the Medium", July 2016,
<https://ieeexplore.ieee.org/document/7467440>.
Authors' Addresses Authors' Addresses
Jianqiang Hou Jianqiang Hou
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012 Nanjing 210012
China China
Email: houjianqiang@huawei.com Email: houjianqiang@huawei.com
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 Electronics and Telecommunications Research Institute
skipping to change at page 21, line 29 skipping to change at page 21, line 45
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
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 38 change blocks. 
96 lines changed or deleted 123 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/