< draft-ietf-6lo-plc-08.txt   draft-ietf-6lo-plc-09.txt >
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: July 14, 2022 Y-G. Hong Expires: July 14, 2022 Y-G. Hong
Daejeon University Daejeon University
X. Tang X. Tang
SGEPRI SGEPRI
C. Perkins C. Perkins
Lupin Lodge Lupin Lodge
January 10, 2022 January 10, 2022
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-08 draft-ietf-6lo-plc-09
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 existing electricity infrastructure meters for electricity. The existing electricity infrastructure
facilitates the expansion of PLC deployments due to its potential facilitates the expansion of PLC deployments due to its potential
advantages in terms of cost and convenience. Moreover, a wide advantages in terms of cost and convenience. Moreover, a wide
variety of accessible devices raises the potential demand of IPv6 for variety of accessible devices raises the potential demand of IPv6 for
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . 8
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 . . . . . . . 10
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 . . . . . . . . . . . . . . 13 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 13
5. Internet Connectivity Scenarios and Topologies . . . . . . . 14 5. Internet Connectivity Scenarios and Topologies . . . . . . . 14
6. Operations and Manageability Considerations . . . . . . . . . 16 6. Operations and Manageability Considerations . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. Using the existing power grid to transmit messages, Power century. Using the existing power grid to transmit messages, Power
Line 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
skipping to change at page 7, line 20 skipping to change at page 7, line 20
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 an 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
A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based
on the equivalent of a EtherType in a layer-2 PLC PDU. [RFC7973] on the equivalent of a EtherType in a layer-2 PLC PDU. [RFC7973]
defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this
information can be carried in the IE field in the MAC header of information can be carried in the IE field in the MAC header of
[IEEE_1901.2] or [ITU-T_G.9903]. And regarding [IEEE_1901.1], the IP [IEEE_1901.2] or [ITU-T_G.9903]. And regarding [IEEE_1901.1], the IP
packet type has been defined with the corresponding MAC Service Data packet type has been defined with the corresponding MAC Service Data
Unit (MSDU) type value 49. And the 4-bit Internet Protocol version Unit (MSDU) type value 49. And the 4-bit Internet Protocol version
skipping to change at page 8, line 20 skipping to change at page 8, line 22
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
As investigated in [RFC7136], besides [RFC4291], some other IID As investigated in [RFC7136], besides [RFC4291], some other IID
generation methods defined in IETF do not imply any semantics for the generation methods defined in IETF do not imply any semantics for the
"Universal/Local" (U/L) bit (7th bit) and the Individual/Group bit "Universal/Local" (U/L) bit (bit 6) and the Individual/Group bit (bit
(8th bit), so that these two bits are not reliable indicators for 7), so that these two bits are not reliable indicators for their
their original meanings. Thus when using an IID derived by a short original meanings. Thus when using an IID derived by a short
address, the operators of the PLC network can choose to comply with 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 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 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 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. If not, the operator must be aware that these two bits are zeros. If not, the operator must be aware that these two
bits are not reliable indicators, and the IID cannot be transformed bits are not reliable indicators, and the IID cannot be transformed
back into a short link layer address via a reverse operation of the back into a short link layer address via a reverse operation of the
mechanism prsented above. mechanism presented above.
For privacy reasons, the IID derived from the MAC address (with For privacy reasons, the IID derived from the MAC address (with
padding and bits flipping) SHOULD only be used for link-local address padding and bits flipping) SHOULD only be used for link-local address
configuration. A PLC host SHOULD use the IID derived from the link- configuration. A PLC host SHOULD use the IID derived from the link-
layer short address to configure IPv6 addresses used for layer short address to configure IPv6 addresses used for
communication with the public network; otherwise, the host's MAC communication with the public network; otherwise, the host's MAC
address is exposed. As per [RFC8065], when short addresses are used address is exposed. As per [RFC8065], when short addresses are used
on PLC links, a shared secret key or version number from the on PLC links, a shared secret key or version number from the
Authoritative Border Router Option [RFC6775] can be used to improve Authoritative Border Router Option [RFC6775] can be used to improve
the entropy of the hash input, thus the generated IID can be spread the entropy of the hash input, thus the generated IID can be spread
skipping to change at page 11, line 23 skipping to change at page 11, line 38
Short Address: 16-bit short address Short Address: 16-bit short address
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 include the prefix routing protocol, such as RPL, which may include the prefix in the
in the DIO (DODAG Information Object) message. As per [RFC9010], it DIO (DODAG Information Object) message. As per [RFC9010], it is
is possible to have PLC devices configured as RPL-unaware-leaves, possible to have PLC devices configured as RPL-unaware-leaves, which
which do not participate in RPL at all, along with RPL-aware PLC do not participate in RPL at all, along with RPL-aware PLC devices.
devices. In this case, the prefix dissemination SHOULD use the RS/RA In this case, the prefix dissemination SHOULD use the RS/RA messages.
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 a 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).
skipping to change at page 14, line 10 skipping to change at page 14, line 23
frequent incorrectly assembled IP fragments. For constrained 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 fragments 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
device: PAN Coordinator (PANC) and PLC 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 primary primary coordinator of the PLC subnet and can be seen as a primary
node; PAN Devices are typically PLC meters and sensors. The address node; PLC Devices are typically PLC meters and sensors. The address
registration and DAD features can also be deployed on the PANC, for registration and DAD features can also be deployed on the PANC, for
example the 6LBR [RFC6775] or the routing registrar in [RFC8505]. example the 6LBR [RFC6775] or the routing registrar in [RFC8505].
IPv6 over PLC networks are built as trees, meshes or stars topology 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 Cellular networks (see and uploads the data through Ethernet or Cellular networks (see
Figure 5). The collected data is transmitted by the smart meters Figure 5). The collected data is transmitted by the smart meters
through PLC, aggregated by a concentrator, sent to the utility and through PLC, aggregated by a concentrator, sent to the utility and
then to a Meter Data Management System for data storage, analysis and then to a Meter Data Management System for data storage, analysis and
billing. This topology has been widely applied in the deployment of billing. This topology has been widely applied in the deployment of
smart meters, especially in apartment buildings. smart meters, especially in apartment buildings.
PLC Device PLC Device PLC Device PLC Device
\ / +--------- \ / +---------
\ / / \ / /
skipping to change at page 15, line 23 skipping to change at page 16, line 7
network is required. A more sophisticated AMI network may also be network is required. A more sophisticated AMI network may also be
constructed into the tree topology which is depicted in [RFC8036]. A constructed into the tree topology which is depicted in [RFC8036]. A
tree topology is suitable for AMI scenarios that require large tree topology is suitable for AMI scenarios that require large
coverage but low density, e.g., the deployment of smart meters in coverage but low density, e.g., the deployment of smart meters in
rural areas. RPL is suitable for maintenance of a tree topology in rural areas. RPL is suitable for maintenance of a tree topology in
which there is no need for communication directly between PAN which there is no need for communication directly between PAN
devices. devices.
PLC Device PLC Device
\ +--------- \ +---------
PLC Device \ / PLC Device A \ /
\ \ + \ \ +
\ \ | \ \ |
Coordinator -- 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
 End of changes. 15 change blocks. 
39 lines changed or deleted 48 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/