< draft-ietf-6lo-plc-04.txt   draft-ietf-6lo-plc-05.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: December 5, 2020 Y-G. Hong Expires: May 1, 2021 Y-G. Hong
ETRI ETRI
X. Tang X. Tang
SGEPRI SGEPRI
C. Perkins C. Perkins
June 3, 2020 October 28, 2020
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-04 draft-ietf-6lo-plc-05
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 December 5, 2020. This Internet-Draft will expire on May 1, 2021.
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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 10
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11
4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 12
5. Internet Connectivity Scenarios and Topologies . . . . . . . 12 5. Internet Connectivity Scenarios and Topologies . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Consideration . . . . . . . . . . . . . . . . . . . 15 7. Security Consideration . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 23 skipping to change at page 3, line 23
large address space and efficent address auto-configuration. A large address space and efficent address auto-configuration. A
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], [RFC6775] and [RFC8505]
constrained PLC networks. There was work previously proposed as to constrained PLC networks. There was work previously proposed as
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], which did not [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], which did not
reach consensus. This document provides a more structured reach consensus. This document provides a more structured
specification than the previous work, expanding to a larger variety specification than the previous work, expanding to a larger variety
of PLC networks. 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 often 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
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.
skipping to change at page 4, line 25 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 PLC device: An entity that follows the PLC standards and implements
protocol stack described in this draft. 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
skipping to change at page 5, line 23 skipping to change at page 5, line 23
(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], Moreover, recently a new PLC standard IEEE 1901.1 [IEEE_1901.1],
which aims at the medium frequency band less than 12 MHz, has been which aims at the medium frequency band of less than 12 MHz, has been
published by the IEEE standard for Smart Grid Powerline Communication published by the IEEE standard for Smart Grid Powerline Communication
Working Group (SGPLC WG). IEEE 1901.1 balances the needs for Working Group (SGPLC WG). IEEE 1901.1 balances the needs for
bandwidth versus communication range, and is thus a promising option bandwidth versus communication range, and is thus a promising option
for 6lo applications. for 6lo 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
skipping to change at page 6, line 33 skipping to change at page 6, line 33
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. Short addresses can be assigned during the joining the network. Short addresses can be assigned during the
onboarding process, by the PANC or the JRC in CoJP onboarding process, by the PANC or the JRC (join registrar/
coordinator) in CoJP (Constrained Join Protocol)
[I-D.ietf-6tisch-minimal-security]. [I-D.ietf-6tisch-minimal-security].
3.3. Maximum Transmission Unit 3.3. Maximum Transmission Unit
The Maximum Transmission Unit (MTU) of the MAC layer determines The Maximum Transmission Unit (MTU) of the MAC layer determines
whether fragmentation and reassembly are needed at the adaptation whether fragmentation and reassembly are needed at the adaptation
layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or
greater; thus for a MAC layer with MTU lower than this limit, greater; thus for a MAC layer with MTU lower than this limit,
fragmentation and reassembly at the adaptation layer are required. fragmentation and reassembly at the adaptation layer are required.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
3.4. Routing Protocol 3.4. Routing Protocol
Routing protocols suitable for use in PLC networks include: Routing protocols suitable for use in PLC networks include:
o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl]
updates RPL to include reactive, point-to-point, and asymmetric updates RPL to include reactive, point-to-point, and asymmetric
routing. IEEE 1901.2 specifies Information Elements (IEs) with routing. IEEE 1901.2 specifies Information Elements (IEs) with
MAC layer metrics, which can be provided to L3 routing protocol MAC layer metrics, which can be provided to L3 routing protocol
for parent selection. For IPv6-addressable PLC networks, a for parent selection.
layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be
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 (PANC in this document). 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 and 6lo standards [RFC4944], [RFC6282], [RFC6775], and
functionality including link-local IPv6 addresses, stateless address [RFC8505] provides useful functionality including link-local IPv6
auto-configuration, neighbor discovery and header compression. addresses, stateless address auto-configuration, neighbor discovery,
However, due to the different characteristics of the PLC media, the header compression, fragmentation and reassembly. However, due to
6LoWPAN adaptation layer cannot perfectly fulfill the requirements. the different characteristics of the PLC media, the 6LoWPAN
These considerations suggest the need for a dedicated adaptation adaptation layer, as it is, cannot perfectly fulfill the requirements
layer for PLC, which is detailed in the following subsections. of PLC environments. These considerations suggest the need for a
dedicated adaptation layer for PLC, which is detailed in the
following subsections.
4.1. Stateless Address Autoconfiguration 4.1. Stateless Address Autoconfiguration
To obtain an IPv6 Interface Identifier (IID), a PLC device performs To obtain an IPv6 Interface Identifier (IID), a PLC device performs
stateless address autoconfiguration [RFC4944]. The autoconfiguration stateless address autoconfiguration [RFC4944]. The autoconfiguration
can be based on either a long or short link-layer address. can be based on either a long or short link-layer address.
The IID can be based on the device's 48-bit MAC address or its EUI-64 The IID can be based on the device's 48-bit MAC address or its EUI-64
identifier [EUI-64]. A 48-bit MAC address MUST first be extended to identifier [EUI-64]. A 48-bit MAC address MUST first be extended to
a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth
skipping to change at page 8, line 34 skipping to change at page 8, line 34
YYYY:YYFF:FE00:0XXX YYYY:YYFF:FE00:0XXX
Since the derived Interface ID is not global, the "Universal/Local" Since the derived Interface ID is not global, the "Universal/Local"
(U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both
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 by 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 by the link-layer short address to configure the IPv6 the IID derived from the link-layer short address to configure the
address used for communication with the public network; otherwise, IPv6 address used for communication with the public network;
the host's MAC address is exposed. Implementations should look at otherwise, the host's MAC address is exposed. Implementers should
[RFC8064] as well, in order to generate a stable IPv6 address using look at [RFC8064] as well, in order to generate a stable IPv6 address
an opaque IID. using an opaque IID.
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 11, line 7 skipping to change at page 11, line 7
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 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, the IPv6 prefix MAY be disseminated by the
the layer 3 routing protocol, such as RPL which includes the prefix layer 3 routing protocol, such as RPL, which may includes the prefix
in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is in the DIO message. As per [I-D.ietf-roll-unaware-leaves], it is
possible to have PLC devices configured as RPL-unaware-leaves, which possible to have PLC devices configured as RPL-unaware-leaves, which
don't not participate to RPL at all, along with RPL-aware PLC do not participate to 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
compression. and/or address compression.
For address registration in route-over mode, a PLC device MUST For address registration in route-over mode, a PLC device MUST
register its addresses by sending unicast link-local Neighbor register its addresses by sending unicast link-local Neighbor
Solicitation to the 6LR. If the registered address is link-local, Solicitation to the 6LR. If the registered address is link-local,
the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR). the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR).
Otherwise, the address MUST be registered via an ARO or EARO included Otherwise, the address MUST be registered via an ARO or EARO included
in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505
compliant PLC devices, the 'R' flag in the EARO MUST be set when compliant PLC devices, the 'R' flag in the EARO MUST be set when
sending Neighbor Solicitaitons in order to extract the status sending Neighbor Solicitaitons in order to extract the status
information in the replied Neighbor Advertisements from the 6LR. If information in the replied Neighbor Advertisements from the 6LR. If
DHCPv6 is used to assign addresses or the IPv6 address is derived by DHCPv6 is used to assign addresses or the IPv6 address is derived
unique long or short link layer address, Duplicate Address Detection from unique long or short link layer address, Duplicate Address
(DAD) MUST NOT be utilized. Otherwise, the DAD MUST be performed at Detection (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be
the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as performed at the 6LBR (as per [RFC6775]) or proxied by the routing
per [RFC8505]). The registration status is feedbacked via the DAC or registrar (as per [RFC8505]). The registration status is feedbacked
EDAC message from the 6LBR and the Neighbor Advertisement (NA) from via the DAC or EDAC message from the 6LBR and the Neighbor
the 6LR. Advertisement (NA) from the 6LR.
For address registration in mesh-under mode, since all the PLC For address registration in mesh-under mode, since all the PLC
devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/ devices are link-local neighbors to the 6LBR, DAR/DAC or EDAR/EDAC
EDAC messages are not required. A PLC device MUST register its messages are not required. A PLC device MUST register its addresses
addresses by sending the unicast NS message with an ARO or EARO. The by sending a unicast NS message with an ARO or EARO. The
registration status is feedbacked via the NA message from the 6LBR. registration status is feedbacked via the NA message from the 6LBR.
4.5. Header Compression 4.5. Header Compression
The compression of IPv6 datagrams within PLC MAC frames refers to The compression of IPv6 datagrams within PLC MAC frames refers to
[RFC6282], which updates [RFC4944]. Header compression as defined in [RFC6282], which updates [RFC4944]. Header compression as defined in
[RFC6282] which specifies the compression format for IPv6 datagrams [RFC6282] which specifies the compression format for IPv6 datagrams
on top of IEEE 802.15.4, is included in this document as the basis on top of IEEE 802.15.4, is the basis for IPv6 header compression in
for IPv6 header compression in PLC. For situations when PLC MAC MTU PLC. For situations when PLC MAC MTU cannot support the 1280-octet
cannot support the 1280-octet IPv6 packet, headers MUST be compressed IPv6 packet, headers MUST be compressed according to [RFC6282]
according to [RFC6282] encoding formats. encoding formats.
For IEEE 1901.2 and G.9903, the IP header compression follows the
instruction in [RFC6282]. However, additional adaptation MUST be
considered for IEEE 1901.1 since it has a short address of 12 bits
instead of 16 bits. The only modification is the semantics of the
"Source Address Mode" when set as "10" in the section 3.1 of
[RFC6282], which is illustrated as following.
SAM: Source Address Mode:
If SAC=0: Stateless compression
10: 12 bits. The first 116 bits of the address are elided.The
value of the first 64 bits is the link-local prefix padded with
zeros. The following 64 bits are 0000:00ff:fe00:0XXX, where
XXX are the 12 bits carried in-line.
If SAC=1: stateful context-based compression
10: 12 bits. The address is derived using context information and
the 12 bits carried in-line. Bits covered by context
information are always used. Any IID bits not covered by
context information are taken directly from their corresponding
bits in the 12-bit to IID mapping given by 0000:00ff:fe00:0XXX,
where XXX are the 12 bits carried inline. Any remaining bits
are zero.
4.6. Fragmentation and Reassembly 4.6. Fragmentation and Reassembly
PLC differs from other wired technologies in that the communication PLC differs from other wired technologies in that the communication
medium is not shielded; thus, to successfully transmit data through medium is not shielded; thus, to successfully transmit data through
power lines, PLC Data Link layer provides the function of power lines, PLC Data Link layer provides the function of
segmentation and reassembly. A Segment Control Field is defined in segmentation and reassembly. A Segment Control Field is defined in
the MAC frame header regardless of whether segmentation is required. the MAC frame header regardless of whether segmentation is required.
The number of data octets of the PHY payload can change dynamically The number of data octets of the PHY payload can change dynamically
based on channel conditions, thus the MAC payload segmentation in the based on channel conditions, thus the MAC payload segmentation in the
skipping to change at page 12, line 33 skipping to change at page 13, line 12
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]. referring to [RFC4944].
5. Internet Connectivity Scenarios and Topologies 5. Internet Connectivity Scenarios and Topologies
The network model can be simplified to two kinds of network devices: The PLC network model can be simplified to two kinds of network
PAN Coordinator (PANC) and PAN Device. The PANC is the primary devices: PAN Coordinator (PANC) and PAN Device. The PANC is the
coordinator of the PLC subnet and can be seen as a master node; PAN primary coordinator of the PLC subnet and can be seen as a master
Devices are typically PLC meters and sensors. The PANC also serves node; PAN Devices are typically PLC meters and sensors. The PANC
as the Routing Registrar for proxy registration and DAD procedures, also serves as the Routing Registrar for proxy registration and DAD
making use of the updated registration procedures in [RFC8505]. IPv6 procedures, making use of the updated registration procedures in
over PLC networks are built as tree, mesh or star according to the [RFC8505]. IPv6 over PLC networks are built as tree, mesh or star
use cases. Every network requires at least one PANC to communicate according to the use cases. Generally, each PLC network has one
with each PAN Device. Note that the PLC topologies in this section PANC. In some cases, the PLC network can have alternate coordinators
are based on logical connectivity, not physical links. 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
connectivity, not physical links. The term "PLC subnet" refers to a
multilink subnet, in which the PLC devices share the same address
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 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,
skipping to change at page 17, line 35 skipping to change at page 18, line 35
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 9.2. Informative References
[EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global
Identifier (EUI-64) Registration Authority", IEEE EUI-64,
March 1997, <https://standards.ieee.org/content/dam/ieee-
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. and M. Sethi, "Nimble out-of-band authentication
for EAP (EAP-NOOB)", draft-ietf-emu-eap-noob-01 (work in for EAP (EAP-NOOB)", draft-ietf-emu-eap-noob-02 (work in
progress), June 2020. progress), July 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-15 (work in progress), draft-ietf-roll-unaware-leaves-22 (work in progress),
April 2020. October 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
 End of changes. 25 change blocks. 
70 lines changed or deleted 105 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/