< draft-ietf-6lo-plc-07.txt   draft-ietf-6lo-plc-08.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: July 2, 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
December 29, 2021 January 10, 2022
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-07 draft-ietf-6lo-plc-08
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 1, line 45 skipping to change at page 1, line 45
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 July 2, 2022. This Internet-Draft will expire on July 14, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . . 3 2. Requirements Notation and Terminology . . . . . . . . . . . . 3
3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5
3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6
3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6
3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7
4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7 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 . . . . . . . 9
4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T
G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 12
4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 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 . . . . . . . . . 16
skipping to change at page 4, line 36 skipping to change at page 4, line 36
PLC: Power Line Communication PLC: Power Line Communication
PLC device: An entity that follows the PLC standards and implements PLC device: An entity that follows the PLC standards and implements
the protocol stack described in this draft the protocol stack described in this draft
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
The terminology used in this draft is aligned with IEEE 1901.2 Below is a mapping table of the terminology between [IEEE_1901.2],
[IEEE_1901.1], [ITU-T_G.9903] and this document.
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document | | IEEE 1901.2 | IEEE 1901.1 | ITU-T G.9903 | This document |
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| PAN | Central | PAN Coordinator | PAN | | PAN | Central | PAN Coordinator | PAN |
| Coordinator | Coordinator | | Coordinator | | Coordinator | Coordinator | | Coordinator |
| | | | | | | | | |
| Coordinator | Proxy | Full-function | Coordinator | | Coordinator | Proxy | Full-function | Coordinator |
| | Coordinator | device | | | | Coordinator | device | |
| | | | | | | | | |
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 the mesh-under routing scheme. Each PLC node o IEEE 1901.1 supports L2 routing. Each PLC node maintains an L2
maintains a routing table, in which each route entry comprises the routing table, in which each route entry comprises the short
short addresses of the destination and the related next hop. The addresses of the destination and the related next hop. The route
route entries are built during the network establishment via a entries are built during the network establishment via a pair of
pair of association request/confirmation messages. The route association request/confirmation messages. The route entries can
entries can be changed via a pair of proxy change request/ be changed via a pair of proxy change request/confirmation
confirmation messages. These association and proxy change messages. These association and proxy change messages must be
messages must be approved by the central coordinator (PANC in this approved by the central coordinator (PANC in this document).
document).
o LOADng (The Lightweight On-demand Ad hoc Distance vector routing o LOADng is a reactive protocol operating at layer-2 or layer-3.
protocol, Next Generation) is a reactive protocol operating at Currently, LOADng is supported in ITU-T G.9903 [ITU-T_G.9903], and
layer-2 or layer-3. Currently, LOADng is supported in ITU-T the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based
G.9903 [ITU-T_G.9903], and the IEEE 1901.2 standard refers to networks.
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
on the equivalent of a EtherType in a layer-2 PLC PDU. [RFC7973]
defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this
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
packet type has been defined with the corresponding MAC Service Data
Unit (MSDU) type value 49. And the 4-bit Internet Protocol version
number in the IP header helps to distinguish between an IPv4 PDU and
an IPv6 PDU.
6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and 6LoWPAN and 6lo standards [RFC4944], [RFC6282], [RFC6775], and
[RFC8505] provide useful functionality including link-local IPv6 [RFC8505] provide useful functionality including link-local IPv6
addresses, stateless address auto-configuration, neighbor discovery, addresses, stateless address auto-configuration, neighbor discovery,
header compression, fragmentation, and reassembly. However, due to header compression, fragmentation, and reassembly. However, due to
the different characteristics of the PLC media, the 6LoWPAN the different characteristics of the PLC media, the 6LoWPAN
adaptation layer, as it is, cannot perfectly fulfill the requirements adaptation layer, as it is, cannot perfectly fulfill the requirements
of PLC environments. These considerations suggest the need for a of PLC environments. These considerations suggest the need for a
dedicated adaptation layer for PLC, which is detailed in the dedicated adaptation layer for PLC, which is detailed in the
following subsections. following subsections.
skipping to change at page 8, line 12 skipping to change at page 8, line 20
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 as by the 16-bit PAN ID, 16 zero bits and the 16-bit short address.
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) as 12 zero bits and a 12-bit TEI (Terminal Equipment Identifier, XXX).
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 (bit 6) and the Individual/Group bit (bit "Universal/Local" (U/L) bit (7th bit) and the Individual/Group bit
7), so that these two bits are not reliable indicators for their (8th bit), so that these two bits are not reliable indicators for
original meanings. Thus when using an IID derived by a short their 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 presented above. mechanism prsented 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 23
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 prefix dissemination, Router Solicitations (RS) and Router For IPv6 address prefix dissemination, Router Solicitations (RS) and
Advertisements (RA) MAY be used as per [RFC6775]. If the PLC network Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC
uses route-over, the IPv6 prefix MAY be disseminated by the layer-3 network uses route-over, the IPv6 prefix MAY be disseminated by the
routing protocol, such as RPL, which may include the prefix in the layer-3 routing protocol, such as RPL, which may include the prefix
DIO (DODAG Information Object) message. As per [RFC9010], it is in the DIO (DODAG Information Object) message. As per [RFC9010], it
possible to have PLC devices configured as RPL-unaware-leaves, which is possible to have PLC devices configured as RPL-unaware-leaves,
do not participate in RPL at all, along with RPL-aware PLC devices. which do not participate in RPL at all, along with RPL-aware PLC
In this case, the prefix dissemination SHOULD use the RS/RA messages. 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
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 10
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; PLC Devices are typically PLC meters and sensors. The address node; PAN 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 PLC 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 PLC devices, and then concentrates (e.g., a meter reading) from the PAN 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 15, line 23
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 A \ / PLC Device \ /
\ \ + \ \ +
\ \ | \ \ |
PLC Device B -- PANC ===========+ Internet Coordinator -- 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
skipping to change at page 19, line 46 skipping to change at page 19, line 46
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>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
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., Sethi, M., and A. Peltonen, "Nimble out-of-band Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- Authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap-
noob-06 (work in progress), September 2021. noob-06 (work in progress), September 2021.
[I-D.ietf-roll-aodv-rpl] [I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Perkins, C. E., Anand, S., and B. Liu, Anamalamudi, S., Perkins, C. E., Anand, S., and B. Liu,
"Supporting Asymmetric Links in Low Power Networks: AODV- "Supporting Asymmetric Links in Low Power Networks: AODV-
RPL", draft-ietf-roll-aodv-rpl-11 (work in progress), RPL", draft-ietf-roll-aodv-rpl-11 (work in progress),
September 2021. September 2021.
[IEEE_1901.2a] [IEEE_1901.2a]
IEEE-SA Standards Board, "IEEE Standard for Low-Frequency IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
skipping to change at page 21, line 19 skipping to change at page 21, line 19
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>. May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
DOI 10.17487/RFC5535, June 2009, DOI 10.17487/RFC5535, June 2009,
<https://www.rfc-editor.org/info/rfc5535>. <https://www.rfc-editor.org/info/rfc5535>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[RFC7973] Droms, R. and P. Duffy, "Assignment of an Ethertype for
IPv6 with Low-Power Wireless Personal Area Network
(LoWPAN) Encapsulation", RFC 7973, DOI 10.17487/RFC7973,
November 2016, <https://www.rfc-editor.org/info/rfc7973>.
[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
Statement for the Routing Protocol for Low-Power and Lossy Statement for the Routing Protocol for Low-Power and Lossy
Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (RPL) in Advanced Metering Infrastructure (AMI)
Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
<https://www.rfc-editor.org/info/rfc8036>. <https://www.rfc-editor.org/info/rfc8036>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
 End of changes. 23 change blocks. 
54 lines changed or deleted 61 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/