draft-ietf-roll-useofrplinfo-40.txt   draft-ietf-roll-useofrplinfo-41.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft UTN-FRM/Aalto Internet-Draft UTN-FRM/Aalto
Updates: 6553, 6550, 8138 (if approved) M. Richardson Updates: 6553, 6550, 8138 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: December 27, 2020 P. Thubert Expires: March 25, 2021 P. Thubert
Cisco Cisco
June 25, 2020 September 21, 2020
Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6
encapsulation in the RPL Data Plane encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-40 draft-ietf-roll-useofrplinfo-41
Abstract Abstract
This document looks at different data flows through LLN (Low-Power This document looks at different data flows through LLN (Low-Power
and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document and Lossy Networks) is used to establish routing. The document
enumerates the cases where RFC6553 (RPI Option Type), RFC6554 enumerates the cases where RFC6553 (RPI Option Type), RFC6554
(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
required in data plane. This analysis provides the basis on which to required in data plane. This analysis provides the basis on which to
design efficient compression of these headers. This document updates design efficient compression of these headers. This document updates
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2020. This Internet-Draft will expire on March 25, 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Requirements Language . . . . . . . . . . . . 5 2. Terminology and Requirements Language . . . . . . . . . . . . 5
3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7
4.1. Updates to RFC6550: Advertising External Routes with Non- 4.1. Updates to RFC6550: Advertising External Routes with Non-
Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7
4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8
4.3. Updates to RFC6550: Indicating the new RPI in the 4.3. Updates to RFC6550:
DODAG Configuration option Flag. . . . . . . . . . . . . 11 Configuration Options and Mode
4.4. Updates to RFC8138: Indicating the way to decompress with of Operation . . . . . . . . . . . . . . . . . . . . . . 11
the new RPI Option Type. . . . . . . . . . . . . . . . . 12 4.4. Updates to RFC6550: Indicating the new RPI in the
DODAG Configuration option Flag. . . . . . . . . . . . . 12
4.5. Updates to RFC8138: Indicating the way to decompress with
the new RPI Option Type. . . . . . . . . . . . . . . . . 13
5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14
6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20
7.1.1. SM: Example of Flow from RAL to Root . . . . . . . . 21 7.1.1. SM: Example of Flow from RAL to Root . . . . . . . . 21
7.1.2. SM: Example of Flow from Root to RAL . . . . . . . . 22 7.1.2. SM: Example of Flow from Root to RAL . . . . . . . . 22
7.1.3. SM: Example of Flow from Root to RUL . . . . . . . . 22 7.1.3. SM: Example of Flow from Root to RUL . . . . . . . . 22
7.1.4. SM: Example of Flow from RUL to Root . . . . . . . . 24 7.1.4. SM: Example of Flow from RUL to Root . . . . . . . . 24
7.2. SM: Interaction between Leaf and Internet. . . . . . . . 25 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 25
7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 25 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 25
skipping to change at page 3, line 23 skipping to change at page 3, line 26
8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45
8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46 8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46
8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46
8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49
8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51
8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52
9. Operational Considerations of supporting 9. Operational Considerations of supporting
RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53
10. Operational considerations of introducing 0x23 . . . . . . . 54 10. Operational considerations of introducing 0x23 . . . . . . . 54
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
11.1. Option Type in RPL Option . . . . . . . . . . . . . . . 54
11.2. Changes to DODAG Configuration Options Flags . . . . . . 55
11.3. Change MOP value 7 to Reserved . . . . . . . . . . . . . 55
12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . 59 14.1. Normative References . . . . . . . . . . . . . . . . . . 59
14.2. Informative References . . . . . . . . . . . . . . . . . 60 14.2. Informative References . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
[RFC6550] is a routing protocol for constrained networks. [RFC6553] [RFC6550] is a routing protocol for constrained networks. [RFC6553]
defines the RPL Option carried within the IPv6 Hop-by-Hop Header to defines the RPL Option carried within the IPv6 Hop-by-Hop Header to
carry the RPLInstanceID and quickly identify inconsistencies (loops) carry the RPLInstanceID and quickly identify inconsistencies (loops)
in the routing topology. The RPL Option is commonly referred to as in the routing topology. The RPL Option is commonly referred to as
the RPL Packet Information (RPI) though the RPI is really the the RPL Packet Information (RPI) though the RPI is really the
abstract information that is defined in [RFC6550] and transported in abstract information that is defined in [RFC6550] and transported in
skipping to change at page 4, line 7 skipping to change at page 4, line 12
seen on all of the data-plane traffic that occurs in RPL routed seen on all of the data-plane traffic that occurs in RPL routed
networks; they do not in general appear on the RPL control plane networks; they do not in general appear on the RPL control plane
traffic at all which is mostly Hop-by-Hop traffic (one exception traffic at all which is mostly Hop-by-Hop traffic (one exception
being DAO messages in non-storing mode). being DAO messages in non-storing mode).
It has become clear from attempts to do multi-vendor It has become clear from attempts to do multi-vendor
interoperability, and from a desire to compress as many of the above interoperability, and from a desire to compress as many of the above
artifacts as possible that not all implementers agree when artifacts artifacts as possible that not all implementers agree when artifacts
are necessary, or when they can be safely omitted, or removed. are necessary, or when they can be safely omitted, or removed.
The ROLL WG analysized how [RFC2460] rules apply to storing and non- The ROLL WG analyzed how [RFC2460] rules apply to storing and non-
storing use of RPL. The result was 24 data plane use cases. They storing use of RPL. The result was 24 data plane use cases. They
are exhaustively outlined here in order to be completely unambiguous. are exhaustively outlined here in order to be completely unambiguous.
During the processing of this document, new rules were published as During the processing of this document, new rules were published as
[RFC8200], and this document was updated to reflect the normative [RFC8200], and this document was updated to reflect the normative
changes in that document. changes in that document.
This document updates [RFC6553], changing the value of the Option This document updates [RFC6553], changing the value of the Option
Type of the RPL Option to make [RFC8200] routers ignore this option Type of the RPL Option to make [RFC8200] routers ignore this option
when not recognized. when not recognized.
A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a
mechanism for compressing RPL Option information and Routing Header mechanism for compressing RPL Option information and Routing Header
type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6
technique. technique.
Since some of the uses cases here described, use IPv6-in-IPv6 Most of the use cases described therein require the use of IPv6-in-
encapsulation. It MUST take in consideration, when encapsulation is IPv6 packet encapsulation. When encapsulating and decapsulating
applied, the RFC6040 [RFC6040], which defines how the explicit packets, RFC 6040 [RFC6040] MUST be applied to map the setting of the
congestion notification (ECN) field of the IP header should be explicit congestion notification (ECN) field between inner and outer
constructed on entry to and exit from any IPV6-in-IPV6 tunnel. headers. Additionally, it is recommended the reading of
Additionally, it is recommended the reading of
[I-D.ietf-intarea-tunnels] that explains the relationship of IP [I-D.ietf-intarea-tunnels] that explains the relationship of IP
tunnels to existing protocol layers and the challenges in supporting tunnels to existing protocol layers and the challenges in supporting
IP tunneling. IP tunneling.
Non-constrained uses of RPL are not in scope of this document, and Non-constrained uses of RPL are not in scope of this document, and
applicability statements for those uses may provide different advice, applicability statements for those uses may provide different advice,
E.g. [I-D.ietf-anima-autonomic-control-plane]. E.g. [I-D.ietf-anima-autonomic-control-plane].
1.1. Overview 1.1. Overview
skipping to change at page 5, line 29 skipping to change at page 5, line 31
consumed Routing Header and as an IPv6 host, it is expected to ignore consumed Routing Header and as an IPv6 host, it is expected to ignore
a Hop-by-Hop header. It results that a RPL Leaf can correctly a Hop-by-Hop header. It results that a RPL Leaf can correctly
receive a packet with RPL artifacts. On the other hand, a RPL Leaf receive a packet with RPL artifacts. On the other hand, a RPL Leaf
is not expected to generate RPL artifacts or to support IP-in-IP is not expected to generate RPL artifacts or to support IP-in-IP
encapsulation. For simplification, this document uses the standalone encapsulation. For simplification, this document uses the standalone
term leaf to mean a RPL leaf. term leaf to mean a RPL leaf.
RPL Packet Information (RPI): The abstract information that [RFC6550] RPL Packet Information (RPI): The abstract information that [RFC6550]
places in IP packets. The term is commonly used, including in this places in IP packets. The term is commonly used, including in this
document, to refer to the RPL Option [RFC6553] that transports that document, to refer to the RPL Option [RFC6553] that transports that
abstract information in an IPv6 Hob-by-Hop Header. abstract information in an IPv6 Hop-by-Hop Header.
RPL-aware-node (RAN): A device which implements RPL. Please note RPL-aware-node (RAN): A device which implements RPL. Please note
that the device can be found inside the LLN or outside LLN. that the device can be found inside the LLN or outside LLN.
RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf.
RPL-unaware-node: A device which does not implement RPL, thus the RPL-unaware-node: A device which does not implement RPL, thus the
device is not-RPL-aware. Please note that the device can be found device is not-RPL-aware. Please note that the device can be found
inside the LLN. inside the LLN.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
outside the RPL domain free of RPL artifacts. In the other outside the RPL domain free of RPL artifacts. In the other
direction, for traffic coming from an external target into the LLN, direction, for traffic coming from an external target into the LLN,
the parent (6LR) that injects the traffic always encapsulates to the the parent (6LR) that injects the traffic always encapsulates to the
root. This whole operation is transparent to intermediate routers root. This whole operation is transparent to intermediate routers
that only see traffic between the 6LR and the Root, and only the Root that only see traffic between the 6LR and the Root, and only the Root
and the 6LRs that inject external routes in the network need to be and the 6LRs that inject external routes in the network need to be
upgraded to add this function to the network. upgraded to add this function to the network.
A RUL is a special case of external target when the target is A RUL is a special case of external target when the target is
actually a host and it is known to support a consumed Routing Header actually a host and it is known to support a consumed Routing Header
and to ignore a HbH header as prescribed by [RFC8200]. The target and to ignore a Hop-by-Hop header as prescribed by [RFC8200]. The
may have been learned through an external routing protocol or may target may have been learned through an external routing protocol or
have been registered to the 6LR using [RFC8505]. may have been registered to the 6LR using [RFC8505].
In order to enable IP-in-IP all the way to a 6LN, it is beneficial In order to enable IP-in-IP all the way to a 6LN, it is beneficial
that the 6LN supports decapsulating IP-in-IP, but that is not assumed that the 6LN supports decapsulating IP-in-IP, but that is not assumed
by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a
packet SHOULD terminate the tunnel at a parent 6LR unless it is aware packet SHOULD terminate the tunnel at a parent 6LR unless it is aware
that the RUL supports IP-in-IP decapsulation. that the RUL supports IP-in-IP decapsulation.
A node that is reachable over an external route is not expected to A node that is reachable over an external route is not expected to
support [RFC8138]. Whether a decapsulation took place or not and support [RFC8138]. Whether a decapsulation took place or not and
even when the 6LR is delivering the packet to a RUL, the 6LR that even when the 6LR is delivering the packet to a RUL, the 6LR that
skipping to change at page 11, line 32 skipping to change at page 11, line 32
much easier as the 6LBR (DODAG root) has complete knowledge about the much easier as the 6LBR (DODAG root) has complete knowledge about the
connectivity of all DODAG nodes, and all traffic flows through the connectivity of all DODAG nodes, and all traffic flows through the
root node. root node.
The 6LBR can recognize not-RPL aware leaf nodes because it will The 6LBR can recognize not-RPL aware leaf nodes because it will
receive a DAO about that node from the 6LR immediately above that receive a DAO about that node from the 6LR immediately above that
not-RPL aware node. not-RPL aware node.
The non-storing mode case does not require the type change from 0x63 The non-storing mode case does not require the type change from 0x63
to 0x23, as the root can always create the right packet. The type to 0x23, as the root can always create the right packet. The type
change does not adversely affect the non-storing case. change does not adversely affect the non-storing case.(see
Section 4.4)
4.3. Updates to RFC6550: Indicating the new RPI in the DODAG 4.3. Updates to RFC6550: Configuration Options and Mode of Operation
RFC6550 section 6.7.6 describes the DODAG Configuration Option. In
this option are a series of Flags in the first octet of the payload.
These flags are described by the DODAG Configuration Option Flags
registry [dodagcfg], in section 20.14 of RFC6550.
Anticipating future work to revise RPL relating to how the LLN and
DODAG is configured, this document changes the interpretation of the
[dodagcfg] Registry to be limited to Mode-of-Operation (MOP)
specific. The MOP is described in [RFC6550] section 6.3.1. The
Options Flags Registry is renamed, and applies to MOP values zero (0)
to six (6) only, leaving the flags reserved for MOP value seven (7).
In addition, this document reserves MOP value 7 for future expansion.
4.4. Updates to RFC6550: Indicating the new RPI in the DODAG
Configuration option Flag. Configuration option Flag.
In order to avoid a Flag Day caused by lack of interoperation between In order to avoid a Flag Day caused by lack of interoperation between
new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this
section defines a flag in the DIO Configuration option, to indicate section defines a flag in the DIO Configuration option, to indicate
when the new RPI Option Type can be safely used. This means, the when the new RPI Option Type can be safely used. This means, the
flag is going to indicate the value of Option Type that the network flag is going to indicate the value of Option Type that the network
will be using for the RPL Option. Thus, when a node joins to a will be using for the RPL Option. Thus, when a node joins to a
network will know which value to use. With this, RPL-capable nodes network will know which value to use. With this, RPL-capable nodes
know if it is safe to use 0x23 when creating a new RPL Option. A know if it is safe to use 0x23 when creating a new RPL Option. A
node that forwards a packet with an RPI MUST NOT modify the Option node that forwards a packet with an RPI MUST NOT modify the Option
Type of the RPL Option. Type of the RPL Option.
This is done using a DODAG Configuration option flag which will This is done using a DODAG Configuration option flag which will
signal "RPI 0x23 enable" and propagate through the network. signal "RPI 0x23 enable" and propagate through the network.
Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP)
in the DIO Base Object. The flag is defined only for MOP value in the DIO Base Object. The flag is defined only for MOP value
between 0 to 6. For a MOP value of 7 or above, the flag MAY indicate between 0 to 6.
something different and MUST NOT be interpreted as "RPI 0x23 enable"
unless the specification of the MOP indicates to do so. For a MOP value of 7 or above, the flag MAY indicate something
different and MUST NOT be interpreted as "RPI 0x23 enable" unless the
specification of the MOP indicates to do so. For a MOP value of 7, a
node SHOULD assume that the RPI 0x23 option is enabled.
As stated in [RFC6550] the DODAG Configuration option is present in As stated in [RFC6550] the DODAG Configuration option is present in
DIO messages. The DODAG Configuration option distributes DIO messages. The DODAG Configuration option distributes
configuration information. It is generally static, and does not configuration information. It is generally static, and does not
change within the DODAG. This information is configured at the DODAG change within the DODAG. This information is configured at the DODAG
root and distributed throughout the DODAG with the DODAG root and distributed throughout the DODAG with the DODAG
Configuration option. Nodes other than the DODAG root do not modify Configuration option. Nodes other than the DODAG root do not modify
this information when propagating the DODAG Configuration option. this information when propagating the DODAG Configuration option.
Currently, the DODAG Configuration option in [RFC6550] states: "the Currently, the DODAG Configuration option in [RFC6550] states: "the
skipping to change at page 12, line 40 skipping to change at page 13, line 18
| 3 | RPI 0x23 enable | This document | | 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
Figure 4: DODAG Configuration option Flag to indicate the RPI-flag- Figure 4: DODAG Configuration option Flag to indicate the RPI-flag-
day. day.
In the case of reboot, the node (6LN or 6LR) does not remember the In the case of reboot, the node (6LN or 6LR) does not remember the
RPI Option Type (i.e., whether or not the flag is set), so the node RPI Option Type (i.e., whether or not the flag is set), so the node
will not trigger DIO messages until a DIO message is received will not trigger DIO messages until a DIO message is received
indicating the RPI value to be used. The node will use the value indicating the RPI value to be used. The node will use the value
0x23 if the network supports this feature 0x23 if the network supports this feature.
4.4. Updates to RFC8138: Indicating the way to decompress with the new 4.5. Updates to RFC8138: Indicating the way to decompress with the new
RPI Option Type. RPI Option Type.
This modification is required in order to be able to decompress the This modification is required in order to be able to decompress the
RPL Option with the new Option Type of 0x23. RPL Option with the new Option Type of 0x23.
RPI-6LoRH header provides a compressed form for the RPL RPI; see RPI-6LoRH header provides a compressed form for the RPL RPI; see
[RFC8138], Section 6. A node that is decompressing this header MUST [RFC8138], Section 6. A node that is decompressing this header MUST
decompress using the RPI Option Type that is currently active: that decompress using the RPI Option Type that is currently active: that
is, a choice between 0x23 (new) and 0x63 (old). The node will know is, a choice between 0x23 (new) and 0x63 (old). The node will know
which to use based upon the presence of the flag in the DODAG which to use based upon the presence of the flag in the DODAG
Configuration option defined in Section 4.3. E.g. If the network is Configuration option defined in Section 4.4. E.g. If the network is
in 0x23 mode (by DIO option), then it should be decompressed to 0x23. in 0x23 mode (by DIO option), then it should be decompressed to 0x23.
[RFC8138] section 7 documents how to compress the IPv6-in-IPv6 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6
header. header.
There are potential significant advantages to having a single code There are potential significant advantages to having a single code
path that always processes IPv6-in-IPv6 headers with no conditional path that always processes IPv6-in-IPv6 headers with no conditional
branches. branches.
In Storing Mode, the scenarios where the flow goes from RAL to RUL In Storing Mode, the scenarios where the flow goes from RAL to RUL
skipping to change at page 16, line 11 skipping to change at page 16, line 11
+-------+ +-------+ +------+ +-------+ +-------+ +-------+ +-------+ +------+ +-------+ +-------+
Figure 6: A reference RPL Topology. Figure 6: A reference RPL Topology.
6. Use cases 6. Use cases
In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6
encapsulation are going to be analyzed for a number of representative encapsulation are going to be analyzed for a number of representative
traffic flows. traffic flows.
This document assumes that the LLN is using the no-drop RPI Option
Type of 0x23.
The use cases describe the communication in the following cases: - The use cases describe the communication in the following cases: -
Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware-
nodes with the Internet - Between RUL nodes within the LLN (e.g. see nodes with the Internet - Between RUL nodes within the LLN (e.g. see
Section 7.1.4) - Inside of the LLN when the final destination address Section 7.1.4) - Inside of the LLN when the final destination address
resides outside of the LLN (e.g. see Section 7.2.3). resides outside of the LLN (e.g. see Section 7.2.3).
The uses cases are as follows: The uses cases are as follows:
Interaction between Leaf and Root: Interaction between Leaf and Root:
skipping to change at page 32, line 22 skipping to change at page 32, line 22
common parent (the Root), 1 <= ia <= n, where n is the total number common parent (the Root), 1 <= ia <= n, where n is the total number
of routers (6LR) that the packet goes through from RAL to the Root. of routers (6LR) that the packet goes through from RAL to the Root.
6LR_id (Node E) represents the intermediate routers from the Root 6LR_id (Node E) represents the intermediate routers from the Root
(Node B) to destination RUL (Node G). In this case, 1 <= id <= m, (Node B) to destination RUL (Node G). In this case, 1 <= id <= m,
where m is the total number of routers (6LR) that the packet goes where m is the total number of routers (6LR) that the packet goes
through from the Root down to the destination RUL. through from the Root down to the destination RUL.
In this case, the packet from the RAL goes to 6LBR because the route In this case, the packet from the RAL goes to 6LBR because the route
to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an
RPI (RPI1) addressed to the root(6LBR). The root does not removes RPI (RPI1) addressed to the root(6LBR). The root does not remove the
the RPI1 (the root cannot remove an RPI if there is no RPI1 (the root cannot remove an RPI if there is no encapsulation).
encapsulation). The root inserts an IPv6-IPv6 encapsulation with an The root inserts an IPv6-IPv6 encapsulation with an RPI2 and sends it
RPI2 and sends it to the 6LR parent of the RUL, which removes the to the 6LR parent of the RUL, which removes the encapsulation and
encapsulation and RPI2 before passing the packet to the RUL. RPI2 before passing the packet to the RUL.
The Figure 19 summarizes what headers are needed for this use case. The Figure 19 summarizes what headers are needed for this use case.
+----------+-------+-------+---------+---------+---------+---------+ +----------+-------+-------+---------+---------+---------+---------+
| Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | | Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+----------+-------+-------+---------+---------+---------+---------+ +----------+-------+-------+---------+---------+---------+---------+
| Added | | | IP6-IP6 | -- | -- | -- | | Added | | | IP6-IP6 | -- | -- | -- |
| headers | RPI1 | -- | (RPI2) | | | | | headers | RPI1 | -- | (RPI2) | | | |
skipping to change at page 33, line 24 skipping to change at page 33, line 24
6LR_ia (Node E) represents the intermediate routers from source (RUL) 6LR_ia (Node E) represents the intermediate routers from source (RUL)
(Node G) to the root (Node A). In this case, 1 <= ia <= n, where n (Node G) to the root (Node A). In this case, 1 <= ia <= n, where n
is the total number of routers (6LR) that the packet goes through is the total number of routers (6LR) that the packet goes through
from source to the root. from source to the root.
6LR_id represents the intermediate routers from the root (Node A) to 6LR_id represents the intermediate routers from the root (Node A) to
destination RAL (Node F). In this case, 1 <= id <= m, where m is the destination RAL (Node F). In this case, 1 <= id <= m, where m is the
total number of routers (6LR) that the packet goes through from the total number of routers (6LR) that the packet goes through from the
root to the destination RAL. root to the destination RAL.
The 6LR_ia (ia=1) (Node E) receives the packet from the RUL (Node G) The 6LR_1 (Node E) receives the packet from the RUL (Node G) and
and inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to the
the root. The root removes the outer header including the RPI (RPI1) root. The root removes the outer header including the RPI (RPI1) and
and inserts a new RPI (RPI2) addressed to the destination RAL (Node inserts a new RPI (RPI2) addressed to the destination RAL (Node F).
F).
The Figure 20 shows the table that summarizes what headers are needed The Figure 20 shows the table that summarizes what headers are needed
for this use case. for this use case.
+-----------+------+---------+---------+---------+---------+---------+ +-----------+------+---------+---------+---------+---------+---------+
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+-----------+------+---------+---------+---------+---------+---------+ +-----------+------+---------+---------+---------+---------+---------+
| Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- |
skipping to change at page 36, line 10 skipping to change at page 36, line 10
header may be necessary in the upwards direction. The term header may be necessary in the upwards direction. The term
"must(up)" means that the IPv6-in-IPv6 header must be present in the "must(up)" means that the IPv6-in-IPv6 header must be present in the
upwards direction. The term "must(down)" means that the IPv6-in-IPv6 upwards direction. The term "must(down)" means that the IPv6-in-IPv6
header must be present in the downward direction. header must be present in the downward direction.
The leaf can be a router 6LR or a host, both indicated as 6LN The leaf can be a router 6LR or a host, both indicated as 6LN
(Figure 6). In the table (Figure 22) the (1) indicates a 6tisch case (Figure 6). In the table (Figure 22) the (1) indicates a 6tisch case
[RFC8180], where the RPI may still be needed for the RPLInstanceID to [RFC8180], where the RPI may still be needed for the RPLInstanceID to
be available for priority/channel selection at each hop. be available for priority/channel selection at each hop.
The root always have to encapuslate on the way down
+--- ------------+-------------+-----+-----+--------------+----------+ +--- ------------+-------------+-----+-----+--------------+----------+
| Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP | | Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP |
| between | | | | | dst | | between | | | | | dst |
+----------------+-------------+-----+-----+--------------+----------+ +----------------+-------------+-----+-----+--------------+----------+
| | RAL to root | Yes | No | No | No | | | RAL to root | Yes | No | No | No |
| +-------------+-----+-----+--------------+----------+ | +-------------+-----+-----+--------------+----------+
| Leaf - Root | root to RAL | Yes | Yes | No | No | | Leaf - Root | root to RAL | Yes | Yes | No | No |
| +-------------+-----+-----+--------------+----------+ | +-------------+-----+-----+--------------+----------+
| | root to RUL | Yes | Yes | must | 6LR | | | root to RUL | Yes | Yes | No | 6LR |
| | | (1) | | | | | | | (1) | | | |
| +-------------+-----+-----+--------------+----------+ | +-------------+-----+-----+--------------+----------+
| | RUL to root | Yes | No | must | root | | | RUL to root | Yes | No | must | root |
+----------------+-------------+-----+-----+--------------+----------+ +----------------+-------------+-----+-----+--------------+----------+
| | RAL to Int | Yes | No | may(up) | root | | | RAL to Int | Yes | No | may(up) | root |
| +-------------+-----+-----+--------------+----------+ | +-------------+-----+-----+--------------+----------+
|Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | |Leaf - Internet | Int to RAL | Yes | Yes | must | RAL |
| +-------------+-----+-----+--------------+----------+ | +-------------+-----+-----+--------------+----------+
| | RUL to Int | Yes | No | must | root | | | RUL to Int | Yes | No | must | root |
| +-------------+-----+-----+--------------+----------+ | +-------------+-----+-----+--------------+----------+
skipping to change at page 41, line 45 skipping to change at page 41, line 45
Internet to RUL Internet to RUL
8.2.1. Non-SM: Example of Flow from RAL to Internet 8.2.1. Non-SM: Example of Flow from RAL to Internet
In this case the flow comprises: In this case the flow comprises:
RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst
For example, a communication flow could be: Node F (RAL) --> Node D For example, a communication flow could be: Node F (RAL) --> Node D
--> Node B --> Node A --> Internet --> Node B --> Node A --> Internet. Having the RAL information about
the RPL domain, it may encapsulate to the root when the destination
is not in the RPL domain of the RAL.
6LR_i represents the intermediate routers from source to destination, 6LR_i represents the intermediate routers from source to destination,
1 <= i <= n, where n is the total number of routers (6LR) that the 1 <= i <= n, where n is the total number of routers (6LR) that the
packet goes through from source (RAL) to 6LBR. packet goes through from source (RAL) to 6LBR.
In this case, the encapsulation from the RAL to the root is optional. In this case, the encapsulation from the RAL to the root is optional.
The simplest case is when the RPI gets to the Internet (as the The simplest case is when the RPI gets to the Internet (as the
Figure 27 shows it), knowing that the Internet is going to ignore it. Figure 27 shows it), knowing that the Internet is going to ignore it.
The IPv6 flow label should be set to zero to aid in compression The IPv6 flow label should be set to zero to aid in compression
skipping to change at page 44, line 40 skipping to change at page 44, line 40
For example, a communication flow could be: Node G --> Node E --> For example, a communication flow could be: Node G --> Node E -->
Node B --> Node A --> Internet Node B --> Node A --> Internet
6LR_i represents the intermediate routers from source to destination, 6LR_i represents the intermediate routers from source to destination,
1 <= i <= n, where n is the total number of routers (6LRs) that the 1 <= i <= n, where n is the total number of routers (6LRs) that the
packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1 packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1
(i=1). (i=1).
In this case the flow label is recommended to be zero in the RUL. As In this case the flow label is recommended to be zero in the RUL. As
RPL headers are added in the RUL packet, the first 6LR (6LR_1) will the RUL parent adds RPL headers in the RUL packet, the first 6LR
add an RPI inside a new IPv6-in-IPv6 header. The IPv6-in-IPv6 header (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6-
will be addressed to the root. This case is identical to the in-IPv6 header will be addressed to the root. This case is identical
storing-mode case (see Section 7.2.3). to the storing-mode case (see Section 7.2.3).
The Figure 30 shows the table that summarizes what headers are needed The Figure 30 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet|
| |src | | [i=2,..,n] | | dst | | |src | | [i=2,..,n] | | dst |
| |node| | | | | | |node| | | | |
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Added | -- |IP6-IP6(RPI) | -- | -- | -- | | Added | -- |IP6-IP6(RPI) | -- | -- | -- |
skipping to change at page 49, line 27 skipping to change at page 49, line 27
6LR_id represents the intermediate routers from the root to the 6LR_id represents the intermediate routers from the root to the
destination, 1 <= id <= m, where m is the total number of the destination, 1 <= id <= m, where m is the total number of the
intermediate routers (6LRs). intermediate routers (6LRs).
As in the previous case, the RAL (6LN) may insert an RPI (RPI1) As in the previous case, the RAL (6LN) may insert an RPI (RPI1)
header which must be in an IPv6-in-IPv6 header addressed to the root header which must be in an IPv6-in-IPv6 header addressed to the root
so that the 6LBR can remove this RPI. The 6LBR will then insert an so that the 6LBR can remove this RPI. The 6LBR will then insert an
RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id
(6LR_id = m) alongside the insertion of RPI2. (6LR_id = m) alongside the insertion of RPI2.
If the originating node does not not put the RPI (RPI1) into an IPv6- If the originating node does not put the RPI (RPI1) into an IPv6-in-
in-IPv6 header addressed to the root. Then, the RPI1 is forwarded IPv6 header addressed to the root. Then, the RPI1 is forwarded down
down from the root in the inner header to no avail. from the root in the inner header to no avail.
The Figure 34 shows the table that summarizes what headers are needed The Figure 34 shows the table that summarizes what headers are needed
for this use case when encapsulation to the root takes place. The for this use case when encapsulation to the root takes place. The
Figure 35 shows the table that summarizes what headers are needed for Figure 35 shows the table that summarizes what headers are needed for
this use case when no encapsulation to the root takes place. this use case when no encapsulation to the root takes place.
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
skipping to change at page 51, line 24 skipping to change at page 51, line 24
6LR_ia represents the intermediate routers from source to the root, 1 6LR_ia represents the intermediate routers from source to the root, 1
<= ia <= n, where n is the total number of intermediate routers (6LR) <= ia <= n, where n is the total number of intermediate routers (6LR)
6LR_id represents the intermediate routers from the root to the 6LR_id represents the intermediate routers from the root to the
destination, 1 <= id <= m, where m is the total number of the destination, 1 <= id <= m, where m is the total number of the
intermediate routers (6LR). intermediate routers (6LR).
In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1) In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1)
inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will
remove this RPI, and add it's own IPv6-in-IPv6 header containing an remove this RPI, and add its own IPv6-in-IPv6 header containing an
RH3 header and an RPI (RPI2). RH3 header and an RPI (RPI2).
The Figure 36 shows the table that summarizes what headers are needed The Figure 36 shows the table that summarizes what headers are needed
for this use case. for this use case.
+----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
skipping to change at page 54, line 26 skipping to change at page 54, line 26
Option Type. Thus, the DIO is sent with a flag indicating the new Option Type. Thus, the DIO is sent with a flag indicating the new
RPI Option Type. RPI Option Type.
The DODAG Configuration option is contained in a RPL DIO message, The DODAG Configuration option is contained in a RPL DIO message,
which contains a unique DTSN counter. The leaf nodes respond to this which contains a unique DTSN counter. The leaf nodes respond to this
message with DAO messages containing the same DTSN. This is a normal message with DAO messages containing the same DTSN. This is a normal
part of RPL routing; the RPL root therefore knows when the updated part of RPL routing; the RPL root therefore knows when the updated
DODAG Configuration option has been seen by all nodes. DODAG Configuration option has been seen by all nodes.
Before the migration happens, all the RPL-aware nodes should support Before the migration happens, all the RPL-aware nodes should support
both values . The migration procedure it is triggered when the DIO both values . The migration procedure is triggered when the DIO is
is sent with the flag indicating the new RPI Option Type. Namely, it sent with the flag indicating the new RPI Option Type. Namely, it
remains at 0x63 until it is sure that the network is capable of 0x23, remains at 0x63 until it is sure that the network is capable of 0x23,
then it abruptly change to 0x23. This options allows to send packets then it abruptly changes to 0x23. This options allows to send
to not-RPL nodes, which should ignore the option and continue packets to not-RPL nodes, which should ignore the option and continue
processing the packets. processing the packets.
As mentioned previously, indicating the new RPI in the DODAG As mentioned previously, indicating the new RPI in the DODAG
Configuration option flag is a way to avoid the flag day (lack of Configuration option flag is a way to avoid the flag day (lack of
interoperation) in a network using 0x63 as the RPI Option Type value. interoperation) in a network using 0x63 as the RPI Option Type value.
It is suggested that RPL implementations accept both 0x63 and 0x23 It is suggested that RPL implementations accept both 0x63 and 0x23
RPI Option type values when processing the header to enable RPI Option type values when processing the header to enable
interoperability. interoperability.
11. IANA Considerations 11. IANA Considerations
11.1. Option Type in RPL Option
This document updates the registration made in [RFC6553] Destination This document updates the registration made in [RFC6553] Destination
Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in
Figure 38. Figure 38.
+-------+-------------------+------------------------+---------- -+ +-------+-------------------+------------------------+---------- -+
| Hex | Binary Value | Description | Reference | | Hex | Binary Value | Description | Reference |
+ Value +-------------------+ + + + Value +-------------------+ + +
| | act | chg | rest | | | | | act | chg | rest | | |
+-------+-----+-----+-------+------------------------+------------+ +-------+-----+-----+-------+------------------------+------------+
| 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)|
skipping to change at page 55, line 29 skipping to change at page 55, line 29
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document | | 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
Figure 39: DODAG Configuration option Flag to indicate the RPI-flag- Figure 39: DODAG Configuration option Flag to indicate the RPI-flag-
day. day.
11.2. Changes to DODAG Configuration Options Flags
This document changes the name of the "DODAG Configuration Option
Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP 0..6".
11.3. Change MOP value 7 to Reserved
This document changes the allocation status of the Mode of Operation
(MOP) [ianamop] from Unassigned to Reserved. This change is in
support of future work related to capabilities.
12. Security Considerations 12. Security Considerations
The security considerations covered in [RFC6553] and [RFC6554] apply The security considerations covered in [RFC6553] and [RFC6554] apply
when the packets are in the RPL Domain. when the packets are in the RPL Domain.
The IPv6-in-IPv6 mechanism described in this document is much more The IPv6-in-IPv6 mechanism described in this document is much more
limited than the general mechanism described in [RFC2473]. The limited than the general mechanism described in [RFC2473]. The
willingness of each node in the LLN to decapsulate packets and willingness of each node in the LLN to decapsulate packets and
forward them could be exploited by nodes to disguise the origin of an forward them could be exploited by nodes to disguise the origin of an
attack. attack.
skipping to change at page 59, line 22 skipping to change at page 59, line 33
14. References 14. References
14.1. Normative References 14.1. Normative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/bcp38>. May 2000, <https://www.rfc-editor.org/info/bcp38>.
[dodagcfg]
IANA, "DODAG Configuration Option Flags", Sept 2020,
<https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-
config-option-flags>.
[ianamop] IANA, "Mode Of Operation", Sept 2020,
<https://www.iana.org/assignments/rpl/rpl.xhtml#mop>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
skipping to change at page 61, line 18 skipping to change at page 61, line 36
in progress), March 2020. in progress), March 2020.
[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-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-25 (work in progress), June 2020. plane-29 (work in progress), September 2020.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-41 (work in progress), April 2020. keyinfra-43 (work in progress), August 2020.
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-10 (work in Architecture", draft-ietf-intarea-tunnels-10 (work in
progress), September 2019. progress), September 2019.
[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-18 (work in progress), June draft-ietf-roll-unaware-leaves-18 (work in progress), June
2020. 2020.
 End of changes. 34 change blocks. 
61 lines changed or deleted 103 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/