< draft-ietf-6lo-plc-02.txt   draft-ietf-6lo-plc-03.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: September 10, 2020 Y-G. Hong Expires: October 31, 2020 Y-G. Hong
ETRI ETRI
X. Tang X. Tang
SGEPRI SGEPRI
C. Perkins C. Perkins
March 9, 2020 April 29, 2020
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-02 draft-ietf-6lo-plc-03
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 43
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 September 10, 2020. This Internet-Draft will expire on October 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation and Terminology . . . . . . . . . . . . 3 2. Requirements Notation and Terminology . . . . . . . . . . . . 3
3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . 7
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9
4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 9 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11
4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12
5. Internet Connectivity Scenarios and Topologies . . . . . . . 12 5. Internet Connectivity Scenarios and Topologies . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Consideration . . . . . . . . . . . . . . . . . . . 14 7. Security Consideration . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 The data acquisition devices in these scenarios share common features
skipping to change at page 3, line 24 skipping to change at page 3, line 24
comparison among various existing PLC standards is provided to comparison among various existing PLC standards is provided to
facilitate the selection of the most applicable standard in facilitate the selection of the most applicable standard in
particular scenarios. particular scenarios.
This specification provides a brief overview of PLC technologies. This specification provides a brief overview of PLC technologies.
Some of them have LLN characteristics, i.e. limited power Some of them have LLN characteristics, i.e. limited power
consumption, memory and processing resources. This specification is consumption, memory and processing resources. This specification is
focused on the transmission of IPv6 packets over those "constrained" focused on the transmission of IPv6 packets over those "constrained"
PLC networks. The general approach is to adapt elements of the PLC networks. The general approach is to adapt elements of the
6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to 6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to
constrained PLC networks. Compared to constrained PLC networks. There was work previously proposed as
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], which did not
provides a structured and greatly expanded specification of an reach consensus. This document provides a more structured
adaptation layer for IPv6 over PLC (6LoPLC) 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
[RFC2119]. BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document often uses the following acronyms and terminologies: This document often uses the following acronyms and terminologies:
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
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
PAN device: An entity follows the PLC standards and implements the
protocol stack described in this draft.
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
MSDU: MAC Service Data Unit MSDU: MAC Service Data Unit
skipping to change at page 4, line 26 skipping to change at page 4, line 25
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.
PLC: Power Line Communication PLC: Power Line Communication
PLC device: An entity follows the PLC standards and implements the
protocol stack described in this draft.
PSDU: PHY Service Data Unit 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 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 | | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document |
+-----------------+---------------------+----------------------+ +---------------+----------------+------------------+---------------+
| PAN Coordinator | Central Coordinator | PAN Coordinator | | PAN | Central | PAN Coordinator | PAN |
| | | | | Coordinator | Coordinator | | Coordinator |
| Coordinator | Proxy Coordinator | Full-function device | | | | | |
| | | | | Coordinator | Proxy | Full-function | Coordinator |
| Device | Station | PAN Device | | | Coordinator | 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. Due to the
large range of communication frequencies, PLC is generally classified large range of communication frequencies, PLC is generally classified
into two categories: Narrowband PLC (NBPLC) for automation of sensors into two categories: Narrowband PLC (NBPLC) for automation of sensors
(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. Various (BBPLC) for home and industry networking applications.
standards have been addressed on the MAC and PHY layers for this
communication technology, e.g. BBPLC (1.8-250 MHz) including IEEE Various standards have been addressed on the MAC and PHY layers for
1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T G.9902 this communication technology, e.g., BBPLC (1.8-250 MHz) including
(G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T
IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME PLC) and G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904
IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). Moreover, (PRIME), IEEE 1901.2 [IEEE_1901.2] (combination of G3-PLC and PRIME
recently a new PLC standard IEEE 1901.1 [IEEE_1901.1], which aims at PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2).
the medium frequency band less than 12 MHz, has been published by the
IEEE standard for Smart Grid Powerline Communication Working Group Moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1],
(SGPLC WG). IEEE 1901.1 balances the needs for bandwidth versus which aims at the medium frequency band less than 12 MHz, has been
communication range, and is thus a promising option for 6lo published by the IEEE standard for Smart Grid Powerline Communication
applications. Currently, this specification is focused on IEEE Working Group (SGPLC WG). IEEE 1901.1 balances the needs for
1901.1, IEEE 1901.2 and ITU-T G.9903. bandwidth versus communication range, and is thus a promising option
for 6lo applications.
This specification is focused on IEEE 1901.1, IEEE 1901.2 and ITU-T
G.9903.
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. mode at layer 2 or in route-over mode at layer 3, as explained in
Section 3.4.
+----------------------------------------+ +----------------------------------------+
| Application Layer | | Application Layer |
+----------------------------------------+ +----------------------------------------+
| TCP/UDP | | TCP/UDP |
+----------------------------------------+ +----------------------------------------+
| | | |
| IPv6 | | IPv6 |
| | | |
+----------------------------------------+ +----------------------------------------+
skipping to change at page 6, line 14 skipping to change at page 6, line 32
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-bit
([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short ([IEEE_1901.1]) or 64-bit ([IEEE_1901.2], [ITU-T_G.9903]) and a short
address of 12-bit ([IEEE_1901.1]) or 16-bit ([IEEE_1901.2], address of 12-bit ([IEEE_1901.1]) or 16-bit ([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. joining the network. Short addresses can be assigned during the
onboarding process, by the PANC or the JRC in CoJP
[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.
skipping to change at page 7, line 7 skipping to change at page 7, line 29
layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be
supported in the standard. supported in the standard.
o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2 o IEEE 1901.1 supports L2 routing. Each PLC node maintains a L2
routing table, in which each route entry comprises the short routing table, in which each route entry comprises the short
addresses of the destination and the related next hop. The route addresses of the destination and the related next hop. The route
entries are built during the network establishment via a pair of entries are built during the network establishment via a pair of
association request/confirmation messages. The route entries can association request/confirmation messages. The route entries can
be changed via a pair of proxy change request/confirmation be changed via a pair of proxy change request/confirmation
messages. These association and proxy change messages MUST be messages. These association and proxy change messages MUST be
approved by the central coordinator. approved by the central coordinator (PANC in this document).
o LOADng is a reactive protocol operating at layer 2 or layer 3. o LOADng is a reactive protocol operating at layer 2 or layer 3.
Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and
the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based
networks. networks.
4. IPv6 over PLC 4. IPv6 over PLC
6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful
functionality including link-local IPv6 addresses, stateless address functionality including link-local IPv6 addresses, stateless address
skipping to change at page 8, line 23 skipping to change at page 8, line 44
For privacy reasons, the IID derived by the MAC address SHOULD only For privacy reasons, the IID derived by 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 by the link-layer short address to configure the IPv6 the IID derived by the link-layer short address to configure the IPv6
address used for communication with the public network; otherwise, address used for communication with the public network; otherwise,
the host's MAC address is exposed. the host's MAC address is exposed.
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). Implementations should look at [RFC8064] as well, in
order to generate a stable IPv6 link-local address using an opaque
IID.
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier | |1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
Figure 2: IPv6 Link Local Address for a PLC interface Figure 2: IPv6 Link Local Address for a PLC interface
4.3. Unicast Address Mapping 4.3. Unicast Address Mapping
skipping to change at page 10, line 34 skipping to change at page 11, line 9
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 address prefix dissemination, Router Solicitations (RS) and
Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC
network uses route-over mesh, the IPv6 prefix MAY be disseminated by network uses route-over mesh, the IPv6 prefix MAY be disseminated by
the layer 3 routing protocol, such as RPL which includes the prefix the layer 3 routing protocol, such as RPL which includes the prefix
in the DIO message. In this case, the prefix information option in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is
(PIO) MUST NOT be included in the Router Advertisement. possible to have PLC devices configured as RPL-unaware-leaves, which
don't not participate to RPL at all, along with RPL-aware PLC
devices. 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
compression. 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 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).
skipping to change at page 12, line 21 skipping to change at page 12, line 46
as the Routing Registrar for proxy registration and DAD procedures, as the Routing Registrar for proxy registration and DAD procedures,
making use of the updated registration procedures in [RFC8505]. IPv6 making use of the updated registration procedures in [RFC8505]. IPv6
over PLC networks are built as tree, mesh or star according to the over PLC networks are built as tree, mesh or star according to the
use cases. Every network requires at least one PANC to communicate use cases. Every network requires at least one PANC to communicate
with each PAN Device. Note that the PLC topologies in this section with each PAN Device. Note that the PLC topologies in this section
are based on logical connectivity, not physical links. are based on logical connectivity, not physical links.
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 PAN 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 PAN devices, and then concentrates
and uploads the data through Ethernet or LPWAN (see Figure 5). The and uploads the data through Ethernet or LPWAN (see Figure 5). The
collected data is transmitted by the smart meters through PLC, collected data is transmitted by the smart meters through PLC,
aggregated by a concentrator, sent to the utility and then to a Meter aggregated by a concentrator, sent to the utility and then to a Meter
Data Management System for data storage, analysis and billing. This Data Management System for data storage, analysis and billing. This
topology has been widely applied in the deployment of smart meters, topology has been widely applied in the deployment of smart meters,
especially in apartment buildings. especially in apartment buildings.
PAN Device PAN Device PLC Device PLC Device
\ / +--------- \ / +---------
\ / / \ / /
\ / + \ / +
\ / | \ / |
PAN Device ------ PANC ===========+ Internet PLC Device ------ PANC ===========+ Internet
/ \ | / \ |
/ \ + / \ +
/ \ \ / \ \
/ \ +--------- / \ +---------
PAN Device PAN 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 PANC is beyond the PLC allowed limit and there is another device B in
between able to communicate with both sides. Device B in this case between able to communicate with both sides. Device B in this case
acts both as a PAN Device and a Coordinator. For this scenario, the acts both as a PAN Device and a Coordinator. For this scenario, the
skipping to change at page 13, line 12 skipping to change at page 13, line 37
and between device B and PANC. An example of PLC tree network is and between device B and PANC. An example of PLC tree network is
depicted in Figure 6. This topology can be applied in the smart depicted in Figure 6. This topology can be applied in the 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, humidity.
Data transmission distance in the street lighting scenario is Data transmission distance in the street lighting scenario is
normally above several kilometers thus the PLC tree network is normally above several kilometers thus the PLC tree network is
required. A more sophisticated AMI network may also be constructed required. A more sophisticated AMI network may also be constructed
into the tree topology which is depicted in [RFC8036]. A tree into the tree topology which is depicted in [RFC8036]. A tree
topology is suitable for AMI scenarios that require large coverage topology is suitable for AMI scenarios that require large coverage
but low density, e.g. the deployment of smart meters in rural areas. but low density, e.g., the deployment of smart meters in rural areas.
RPL is suitable for maintenance of a tree topology in which there is RPL is suitable for maintenance of a tree topology in which there is
no need for communication directly between PAN devices. no need for communication directly between PAN devices.
PAN Device PLC Device
\ +--------- \ +---------
PAN Device \ / PLC Device \ /
\ \ + \ \ +
\ \ | \ \ |
PAN Device -- PANC ===========+ Internet PLC Device -- PANC ===========+ Internet
/ / | / / |
/ / + / / +
PAN Device---PAN Device / \ PLC Device---PLC Device / \
/ +--------- / +---------
PAN Device---PAN Device PAN Device---PAN 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), 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 enables direct PAN device to PAN device communication, without being
obliged to transmit frames through the PANC, which is a requirement obliged to transmit frames through the PANC, which is a requirement
often cited for AMI infrastructure. often cited for AMI infrastructure.
PAN Device---PAN Device PLC Device---PLC Device
/ \ / \ +--------- / \ / \ +---------
/ \ / \ / / \ / \ /
/ \ / \ + / \ / \ +
/ \ / \ | / \ / \ |
PAN Device--PAN Device---PANC ===========+ Internet PLC Device--PLC Device---PANC ===========+ Internet
\ / \ / | \ / \ / |
\ / \ / + \ / \ / +
\ / \ / \ \ / \ / \
\ / \ / +--------- \ / \ / +---------
PAN Device---PAN 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. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
7. Security Consideration 7. 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. For security consideration,
link layer security is guaranteed in every PLC technology. link layer security is guaranteed in every PLC technology.
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. The security can multicast routing messages containing fake metrics. A device may
be enhanced by using DTLS to authenticate a PLC device when it also join a wrong or even malicious network, exposing its data to
enrolles itself. If the PLC device is not direct neighbor to the illegal users. Thus it is highly recommended to conduct a mutual
PANC, where the authenticate is conducted, another PLC device which authentication between the network and the device tending to join in
has joined the network can act as a proxy to help exchange the it. Pre-installed certificates can be transported over DTLS to
authenticate messages. The key used for encryption can also be facilitate the authentication. Alternatively, as per
negociated via DTLS. [I-D.ietf-6tisch-minimal-security], provisioning a unique pre-shared
keys (PSKs) to each PLC device is also feasible. In both cases, if
the PLC device is not direct neighbor to the PANC/JRC, where the
authenticate is conducted, another PLC device which has joined the
network can act as a proxy to help exchange the authentication
messages.
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. [RFC3315], [RFC3972], [RFC4941],
[RFC5535], [RFC7217], and [RFC8065] provide valuable information for [RFC5535], [RFC7217], and [RFC8065] provide valuable information for
IID formation with improved privacy, and are RECOMMENDED for IPv6 IID formation with improved privacy, and are RECOMMENDED for IPv6
skipping to change at page 15, line 25 skipping to change at page 16, line 13
valuable comments and contributions. valuable comments and contributions.
9. References 9. References
9.1. Normative References 9.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,
<http://sites.ieee.org/sagroups-1901-1>. <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
for Smart Grid Applications", IEEE 1901.2, October 2013, for Smart Grid Applications", IEEE 1901.2, October 2013,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/1901.2-2013.html>. standard/1901.2-2013.html>.
[ITU-T_G.9903] [ITU-T_G.9903]
International Telecommunication Union, "Narrowband International Telecommunication Union, "Narrowband
skipping to change at page 16, line 33 skipping to change at page 17, line 18
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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 9.2. Informative References
[I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-
6tisch-minimal-security-15 (work in progress), December
2019.
[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, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in
progress), April 2019. progress), April 2019.
[I-D.ietf-roll-unaware-leaves]
Thubert, P. and M. Richardson, "Routing for RPL Leaves",
draft-ietf-roll-unaware-leaves-15 (work in progress),
April 2020.
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over- Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014. 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,
skipping to change at page 17, line 46 skipping to change at page 18, line 46
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>.
[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>.
Authors' Addresses Authors' Addresses
Jianqiang Hou Jianqiang Hou
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012 Nanjing 210012
 End of changes. 41 change blocks. 
75 lines changed or deleted 115 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/