< draft-ietf-roll-useofrplinfo-42.txt   draft-ietf-roll-useofrplinfo-43.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: May 16, 2021 P. Thubert Expires: July 14, 2021 P. Thubert
Cisco Cisco
November 12, 2020 January 10, 2021
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-42 draft-ietf-roll-useofrplinfo-43
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 May 16, 2021. This Internet-Draft will expire on July 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 3, line 29 skipping to change at page 3, line 29
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.1. Option Type in RPL Option . . . . . . . . . . . . . . . 54
11.2. Change to the DODAG Configuration Options Flags registry 55 11.2. Change to the DODAG Configuration Options Flags registry 55
11.3. Change MOP value 7 to Reserved . . . . . . . . . . . . . 55 11.3. Change MOP value 7 to Reserved . . . . . . . . . . . . . 55
12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 12. Security Considerations . . . . . . . . . . . . . . . . . . . 56
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . 59 14.1. Normative References . . . . . . . . . . . . . . . . . . 59
14.2. Informative References . . . . . . . . . . . . . . . . . 61 14.2. Informative References . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 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 the routing
abstract information that is defined in [RFC6550] and transported in information that is defined in [RFC6550] and transported in the RPL
the RPL Option. RFC6554 [RFC6554] defines the "RPL Source Route Option. RFC6554 [RFC6554] defines the "RPL Source Route Header"
Header" (RH3), an IPv6 Extension Header to deliver datagrams within a (RH3), an IPv6 Extension Header to deliver datagrams within a RPL
RPL routing domain, particularly in non-storing mode. routing domain, particularly in non-storing mode.
These various items are referred to as RPL artifacts, and they are These various items are referred to as RPL artifacts, and they are
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
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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.
Most of the use cases described therein require the use of IPv6-in- Most of the use cases described herein require the use of IPv6-in-
IPv6 packet encapsulation. When encapsulating and decapsulating IPv6 packet encapsulation. When encapsulating and decapsulating
packets, RFC 6040 [RFC6040] MUST be applied to map the setting of the packets, [RFC6040] MUST be applied to map the setting of the explicit
explicit congestion notification (ECN) field between inner and outer congestion notification (ECN) field between inner and outer headers.
headers. Additionally, it is recommended the reading of Additionally, [I-D.ietf-intarea-tunnels] is recommended reading to
[I-D.ietf-intarea-tunnels] that explains the relationship of IP explain the relationship of IP tunnels to existing protocol layers
tunnels to existing protocol layers and the challenges in supporting 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
The rest of the document is organized as follows: Section 2 describes The rest of the document is organized as follows: Section 2 describes
the used terminology. Section 3 provides a RPL Overview. Section 4 the used terminology. Section 3 provides a RPL Overview. Section 4
describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5 describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5
provides the reference topology used for the uses cases. Section 6 provides the reference topology used for the uses cases. Section 6
describes the uses cases included. Section 7 describes the storing describes the use cases included. Section 7 describes the storing
mode cases and section 8 the non-storing mode cases. Section 9 mode cases and section 8 the non-storing mode cases. Section 9
describes the operational considerations of supporting RPL-unaware- describes the operational considerations of supporting RPL-unaware-
leaves. Section 10 depicts operational considerations for the leaves. Section 10 depicts operational considerations for the
proposed change on RPI Option Type, section 11 the IANA proposed change on RPI Option Type, section 11 the IANA
considerations and then section 12 describes the security aspects. considerations and then section 12 describes the security aspects.
2. Terminology and Requirements Language 2. Terminology and Requirements Language
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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Terminology defined in [RFC7102] applies to this document: LLN, RPL, Terminology defined in [RFC7102] applies to this document: LLN, RPL,
RPL domain and ROLL. RPL domain and ROLL.
Consumed: A Routing Header is consumed when the Segments Left field
is zero, which indicates that the destination in the IPv6 header is
the final destination of the packet and that the hops in the Routing
Header have been traversed.
RPL Leaf: An IPv6 host that is attached to a RPL router and obtains RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
connectivity through a RPL Destination Oriented Directed Acyclic connectivity through a RPL Destination Oriented Directed Acyclic
Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a
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 information defined abstractly in
places in IP packets. The term is commonly used, including in this [RFC6550] to be placed in IP packets. The term is commonly used,
document, to refer to the RPL Option [RFC6553] that transports that including in this document, to refer to the RPL Option [RFC6553] that
abstract information in an IPv6 Hop-by-Hop Header. transports that abstract information in an IPv6 Hop-by-Hop Header.
[RFC8138] provides an alternate (more compressed) formating for the
same abstract information.
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 6, line 15 skipping to change at page 6, line 19
route-over topologies." route-over topologies."
6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border
router located at the junction of separate 6LoWPAN networks or router located at the junction of separate 6LoWPAN networks or
between a 6LoWPAN network and another IP network. There may be one between a 6LoWPAN network and another IP network. There may be one
or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the
responsible authority for IPv6 prefix propagation for the 6LoWPAN responsible authority for IPv6 prefix propagation for the 6LoWPAN
network it is serving. An isolated LoWPAN also contains a 6LBR in network it is serving. An isolated LoWPAN also contains a 6LBR in
the network, which provides the prefix(es) for the isolated network." the network, which provides the prefix(es) for the isolated network."
Flag Day: In this document, refers to a transition that involves Flag Day: It is a mechanism for resolving an interoperability
having a network with different values of RPI Option Type. situation (e.g. lack of interoperation between new RPI Option Type
(0x23) and old RPI Option Type (0x63) nodes) by making an abrupt,
disruptive changeover from one to the other.
Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL-
aware-nodes send information to the root about their parents. Thus, aware-nodes send information to the root about their parents. Thus,
the root knows the topology. Because the root knows the topology, the root knows the topology. Because the root knows the topology,
the intermediate 6LRs do not maintain routing state and source the intermediate 6LRs do not maintain routing state and source
routing is needed. routing is needed.
Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes
(6LRs) maintain routing state (of the children) so that source (6LRs) maintain routing state (of the children) so that source
routing is not needed. routing is not needed.
skipping to change at page 7, line 27 skipping to change at page 7, line 27
+--------------+ +--------------+
| 6LoWPAN | | 6LoWPAN |
| | | |
+--------------+ +--------------+
| PHY-MAC | | PHY-MAC |
| | | |
+--------------+ +--------------+
Figure 1: RPL Stack. Figure 1: RPL Stack.
RPL supports two modes of Downward traffic: in storing mode (SM), it RPL supports two modes of Downward internal traffic: in storing mode
is fully stateful; in non-storing mode (Non-SM), it is fully source (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully
routed. A RPL Instance is either fully storing or fully non-storing, source routed. A RPL Instance is either fully storing or fully non-
i.e. a RPL Instance with a combination of storing and non-storing storing, i.e. a RPL Instance with a combination of a fully storing
nodes is not supported with the current specifications at the time of and non-storing nodes is not supported with the current
writing this document. specifications at the time of writing this document. External routes
are advertised with non-storing-mode messaging even in a storing mode
network, see Section 4.1.1
4. Updates to RFC6550, RFC6553 and RFC8138 4. Updates to RFC6550, RFC6553 and RFC8138
4.1. Updates to RFC6550 4.1. Updates to RFC6550
4.1.1. Advertising External Routes with Non-Storing Mode Signaling. 4.1.1. Advertising External Routes with Non-Storing Mode Signaling.
Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to
indicate that the 6LR that generates the DAO redistributes external indicate that the 6LR that generates the DAO redistributes external
targets into the RPL network. An external Target is a Target that targets into the RPL network. An external Target is a Target that
skipping to change at page 8, line 13 skipping to change at page 8, line 15
outside the RPL domain. outside the RPL domain.
This specification updates [RFC6550] to RECOMMEND that external This specification updates [RFC6550] to RECOMMEND that external
targets are advertised using Non-Storing Mode DAO messaging even in a targets are advertised using Non-Storing Mode DAO messaging even in a
Storing-Mode network. This way, external routes are not advertised Storing-Mode network. This way, external routes are not advertised
within the DODAG and all packets to an external target reach the Root within the DODAG and all packets to an external target reach the Root
like normal Non-Storing Mode traffic. The Non-Storing Mode DAO like normal Non-Storing Mode traffic. The Non-Storing Mode DAO
informs the Root of the address of the 6LR that injects the external informs the Root of the address of the 6LR that injects the external
route, and the root uses IP-in-IP encapsulation to that 6LR, which route, and the root uses IP-in-IP encapsulation to that 6LR, which
terminates the IP-in-IP tunnel and forwards the original packet terminates the IP-in-IP tunnel and forwards the original packet
outside the RPL domain free of RPL artifacts. In the other outside the RPL domain free of RPL artifacts.
direction, for traffic coming from an external target into the LLN,
the parent (6LR) that injects the traffic always encapsulates to the In the other direction, for traffic coming from an external target
root. This whole operation is transparent to intermediate routers into the LLN, the parent (6LR) that injects the traffic always
that only see traffic between the 6LR and the Root, and only the Root encapsulates to the root. This whole operation is transparent to
and the 6LRs that inject external routes in the network need to be intermediate routers that only see traffic between the 6LR and the
upgraded to add this function to the network. Root, and only the Root and the 6LRs that inject external routes in
the network need to be 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 Hop-by-Hop header as prescribed by [RFC8200]. The and to ignore a Hop-by-Hop header as prescribed by [RFC8200]. The
target may have been learned through an external routing protocol or target may have been learned through an external routing protocol or
may 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
skipping to change at page 9, line 13 skipping to change at page 9, line 17
See Sections 11.2 and 11.3. See Sections 11.2 and 11.3.
4.1.3. Indicating the new RPI in the DODAG Configuration option Flag. 4.1.3. Indicating the new RPI in the DODAG 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 it will know which value to use. With this, RPL-capable
know if it is safe to use 0x23 when creating a new RPL Option. A nodes know if it is safe to use 0x23 when creating a new RPL Option.
node that forwards a packet with an RPI MUST NOT modify the Option A 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. between 0 to 6.
For a MOP value of 7, a node MUST use the RPI 0x23 option. For a MOP value of 7, a node MUST use the RPI 0x23 option.
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
unused bits MUST be initialize to zero by the sender and MUST be unused bits MUST be initialized to zero by the sender and MUST be
ignored by the receiver". If the flag is received with a value zero ignored by the receiver". If the flag is received with a value zero
(which is the default), then new nodes will remain in RFC6553 (which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI Option Type Compatible Mode; originating traffic with the old-RPI Option Type
(0x63) value. If the flag is received with a value of 1, then the (0x63) value. If the flag is received with a value of 1, then the
value for the RPL Option MUST be set to 0x23. value for the RPL Option MUST be set to 0x23.
Bit number three of the flag field in the DODAG Configuration option Bit number three of the flag field in the DODAG Configuration option
is to be used as shown in Figure 2 (which is the same as Figure 39 in is to be used as shown in Figure 2 (which is the same as Figure 39 in
Section 11 and is shown here for convenience): Section 11 and is shown here for convenience):
skipping to change at page 11, line 39 skipping to change at page 11, line 39
leave the RPL domain on its way to its destination. In that event, leave the RPL domain on its way to its destination. In that event,
the packet should reach its destination and should not be discarded the packet should reach its destination and should not be discarded
by the first node that does not recognize the RPL Option. But with by the first node that does not recognize the RPL Option. But with
the current value of the Option Type, if a node in the Internet is the current value of the Option Type, if a node in the Internet is
configured to process the Hop-by-Hop header, and if such node configured to process the Hop-by-Hop header, and if such node
encounters an option with the first two bits set to 01 and conforms encounters an option with the first two bits set to 01 and conforms
to [RFC8200], it will drop the packet. Host systems should do the to [RFC8200], it will drop the packet. Host systems should do the
same, irrespective of the configuration. same, irrespective of the configuration.
Thus, this document updates the Option Type of the RPL Option Thus, this document updates the Option Type of the RPL Option
[RFC6553], abusively naming it RPI Option Type for simplicity, to [RFC6553], naming it RPI Option Type for simplicity, to (Figure 4):
(Figure 4): the two high order bits MUST be set to '00' and the third the two high order bits MUST be set to '00' and the third bit is
bit is equal to '1'. The first two bits indicate that the IPv6 node equal to '1'. The first two bits indicate that the IPv6 node MUST
MUST skip over this option and continue processing the header skip over this option and continue processing the header ([RFC8200]
([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and Section 4.2) if it doesn't recognize the Option Type, and the third
the third bit continues to be set to indicate that the Option Data bit continues to be set to indicate that the Option Data may change
may change en route. The rightmost five bits remain at 0x3(00011). en route. The rightmost five bits remain at 0x3(00011). This
This ensures that a packet that leaves the RPL domain of an LLN (or ensures that a packet that leaves the RPL domain of an LLN (or that
that leaves the LLN entirely) will not be discarded when it contains leaves the LLN entirely) will not be discarded when it contains the
the RPL Option. RPL Option.
With the new Option Type, if an IPv6 (intermediate) node (RPL-not- With the new Option Type, if an IPv6 (intermediate) node (RPL-not-
capable) receives a packet with a RPL Option, it should ignore the capable) receives a packet with a RPL Option, it should ignore the
Hop-by-Hop RPL Option (skip over this option and continue processing Hop-by-Hop RPL Option (skip over this option and continue processing
the header). This is relevant, as it was mentioned previously, in the header). This is relevant, as it was mentioned previously, in
the case that there is a flow from RAL to Internet (see the case that there is a flow from RAL to Internet (see
Section 7.2.1). Section 7.2.1).
This is a significant update to [RFC6553]. This is a significant update to [RFC6553].
skipping to change at page 12, line 35 skipping to change at page 12, line 35
to 0x23 will not be understood by those networks. It is suggested to 0x23 will not be understood by those networks. It is suggested
that RPL implementations accept both 0x63 and 0x23 when processing that RPL implementations accept both 0x63 and 0x23 when processing
the header. the header.
When forwarding packets, implementations SHOULD use the same value of When forwarding packets, implementations SHOULD use the same value of
RPI Type as was received. This is required because the RPI Option RPI Type as was received. This is required because the RPI Option
Type does not change en route ([RFC8200] - Section 4.2). It allows Type does not change en route ([RFC8200] - Section 4.2). It allows
the network to be incrementally upgraded and allows the DODAG root to the network to be incrementally upgraded and allows the DODAG root to
know which parts of the network have been upgraded. know which parts of the network have been upgraded.
When originating new packets, implementations SHOULD have an option When originating new packets, implementations should have an option
to determine which value to originate with, this option is controlled to determine which value to originate with, this option is controlled
by the DIO option described below. by the DIO Configuration option (Section Section 4.1.3).
The change of RPI Option Type from 0x63 to 0x23, makes all [RFC8200] The change of RPI Option Type from 0x63 to 0x23, makes all [RFC8200]
Section 4.2 compliant nodes tolerant of the RPL artifacts. There is Section 4.2 compliant nodes tolerant of the RPL artifacts. There is
therefore no longer a necessity to remove the artifacts when sending no longer a need to remove the artifacts when sending traffic to the
traffic to the Internet. This change clarifies when to use IPv6-in- Internet. This change clarifies when to use IPv6-in-IPv6 headers,
IPv6 headers, and how to address them: The Hop-by-Hop Options header and how to address them: The Hop-by-Hop Options header containing the
containing the RPI MUST always be added when 6LRs originate packets RPI MUST always be added when 6LRs originate packets (without IPv6-
(without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST always in-IPv6 headers), and IPv6-in-IPv6 headers MUST always be added when
be added when a 6LR finds that it needs to insert a Hop-by-Hop a 6LR finds that it needs to insert a Hop-by-Hop Options header
Options header containing the RPL Option. The IPv6-in-IPv6 header is containing the RPL Option. The IPv6-in-IPv6 header is to be
to be addressed to the RPL root when on the way up, and to the end- addressed to the RPL root when on the way up, and to the end-host
host when on the way down. when on the way down.
In the non-storing case, dealing with not-RPL aware leaf nodes is In the non-storing case, dealing with not-RPL aware leaf nodes is
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.
skipping to change at page 16, line 17 skipping to change at page 16, line 17
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.
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 use cases are as follows:
Interaction between Leaf and Root: Interaction between Leaf and Root:
RAL to root RAL to root
root to RAL root to RAL
RUL to root RUL to root
root to RUL root to RUL
skipping to change at page 17, line 38 skipping to change at page 17, line 38
RPL Option are marked mutable but recoverable: so an IPsec AH RPL Option are marked mutable but recoverable: so an IPsec AH
security header can be applied across these headers, but it can not security header can be applied across these headers, but it can not
secure the values which mutate. secure the values which mutate.
The RPI MUST be present in every single RPL data packet. The RPI MUST be present in every single RPL data packet.
Prior to [RFC8138], there was significant interest in creating an Prior to [RFC8138], there was significant interest in creating an
exception to this rule and removing the RPI for downward flows in exception to this rule and removing the RPI for downward flows in
non-storing mode. This exception covered a very small number of non-storing mode. This exception covered a very small number of
cases, and caused significant interoperability challenges while cases, and caused significant interoperability challenges while
adding significant in the code and tests. The ability to compress adding significant interest in the code and tests. The ability to
the RPI down to three bytes or less removes much of the pressure to compress the RPI down to three bytes or less removes much of the
optimize this any further [I-D.ietf-anima-autonomic-control-plane]. pressure to optimize this any further
[I-D.ietf-anima-autonomic-control-plane].
Throughout the following subsections, the examples are described in Throughout the following subsections, the examples are described in
more details in the first subsections, and more concisely in the more details in the first subsections, and more concisely in the
later ones. later ones.
The uses cases are delineated based on the following IPV6 and RPL The uses cases are delineated based on the following IPV6 and RPL
mandates: mandates:
The RPI has to be in every packet that traverses the LLN. The RPI has to be in every packet that traverses the LLN.
skipping to change at page 18, line 41 skipping to change at page 18, line 44
- The RPI is ignored at the IPv6 dst node (RUL). - The RPI is ignored at the IPv6 dst node (RUL).
- In the uses cases, we assume that the RAL supports IP-in-IP - In the uses cases, we assume that the RAL supports IP-in-IP
encapsulation. encapsulation.
- In the uses cases, we don't assume that the RUL supports IP-in- - In the uses cases, we don't assume that the RUL supports IP-in-
IP encapsulation. IP encapsulation.
- For traffic leaving a RUL, if the RUL adds an opaque RPI then - For traffic leaving a RUL, if the RUL adds an opaque RPI then
the description of the RAL applies. The 6LR as a RPL border the 6LR as a RPL border router SHOULD rewrite the RPI to indicate
router SHOULD rewrite the RPI to indicate the selected Instance the selected Instance and set the flags.
and set the flags.
- The description for RALs applies to RAN in general. - The description for RALs applies to RAN in general.
- Non-constrained uses of RPL are not in scope of this document. - Non-constrained uses of RPL are not in scope of this document.
- Compression is based on [RFC8138]. - Compression is based on [RFC8138].
- The flow label [RFC6437] is not needed in RPL. - The flow label [RFC6437] is not needed in RPL.
7. Storing mode 7. Storing mode
skipping to change at page 27, line 37 skipping to change at page 27, line 37
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) Internet --> root (6LBR) --> 6LR_i --> RAL (6LN)
For example, a communication flow could be: Internet --> Node A For example, a communication flow could be: Internet --> Node A
root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL)
When the packet arrives from Internet to 6LBR the RPI is added in a When the packet arrives from Internet to 6LBR the RPI is added in a
outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address
set to the RAL) and sent to 6LR, which modifies the rank in the RPI. set to the RAL) and sent to 6LR, which modifies the rank in the RPI.
When the packet arrives at the RAL the RPI is removed and the packet When the packet arrives at the RAL, the packet is decapsulated, which
processed. removes the RPI before the packet is processed.
The Figure 15 shows the table that summarizes what headers are needed The Figure 15 shows the table that summarizes what headers are needed
for this use case. for this use case.
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Header | Internet | 6LBR | 6LR_i | RAL dst | | Header | Internet | 6LBR | 6LR_i | RAL dst |
| | src | | | | | | src | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Added | -- | IP6-IP6(RPI) | -- | -- | | Added | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
skipping to change at page 53, line 17 skipping to change at page 53, line 17
Roughly half of the situations described in this document involve Roughly half of the situations described in this document involve
leaf ("host") nodes that do not speak RPL. These nodes fall into two leaf ("host") nodes that do not speak RPL. These nodes fall into two
further categories: ones that drop a packet that have RPI or RH3 further categories: ones that drop a packet that have RPI or RH3
headers, and ones that continue to process a packet that has RPI and/ headers, and ones that continue to process a packet that has RPI and/
or RH3 headers. or RH3 headers.
[RFC8200] provides for new rules that suggest that nodes that have [RFC8200] provides for new rules that suggest that nodes that have
not been configured (explicitly) to examine Hop-by-Hop headers, not been configured (explicitly) to examine Hop-by-Hop headers,
should ignore those headers, and continue processing the packet. should ignore those headers, and continue processing the packet.
Despite this, and despite the switch from 0x63 to 0x23, there may be Despite this, and despite the switch from 0x63 to 0x23, there may be
hosts that are pre-RFC8200, or simply intolerant. Those hosts will nodes that are pre-RFC8200, or simply intolerant. Those nodes will
drop packets that continue to have RPL artifacts in them. In drop packets that continue to have RPL artifacts in them. In
general, such hosts can not be easily supported in RPL LLNs. general, such nodes can not be easily supported in RPL LLNs.
There are some specific cases where it is possible to remove the RPL There are some specific cases where it is possible to remove the RPL
artifacts prior to forwarding the packet to the leaf host. The artifacts prior to forwarding the packet to the leaf host. The
critical thing is that the artifacts have been inserted by the RPL critical thing is that the artifacts have been inserted by the RPL
root inside an IPv6-in-IPv6 header, and that the header has been root inside an IPv6-in-IPv6 header, and that the header has been
addressed to the 6LR immediately prior to the leaf node. In that addressed to the 6LR immediately prior to the leaf node. In that
case, in the process of removing the IPv6-in-IPv6 header, the case, in the process of removing the IPv6-in-IPv6 header, the
artifacts can also be removed. artifacts can also be removed.
The above case occurs whenever traffic originates from the outside The above case occurs whenever traffic originates from the outside
the LLN (the "Internet" cases above), and non-storing mode is used. the LLN (the "Internet" cases above), and non-storing mode is used.
In non-storing mode, the RPL root knows the exact topology (as it In non-storing mode, the RPL root knows the exact topology (as it
must create the RH3 header) and therefore knows which 6LR is prior to must create the RH3 header) and therefore knows which 6LR is prior to
the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf
Node G, or Node C is the 6LR prior to leaf Node J. Node G, or Node C is the 6LR prior to leaf Node J.
traffic originating from the RPL root (such as when the data Traffic originating from the RPL root (such as when the data
collection system is co-located on the RPL root), does not require an collection system is co-located on the RPL root), does not require an
IPv6-in-IPv6 header (in storing or non-storing mode), as the packet IPv6-in-IPv6 header (in storing or non-storing mode), as the packet
is originating at the root, and the root can insert the RPI and RH3 is originating at the root, and the root can insert the RPI and RH3
headers directly into the packet, as it is formed. Such a packet is headers directly into the packet, as it is formed. Such a packet is
slightly smaller, but only can be sent to nodes (whether RPL aware or slightly smaller, but only can be sent to nodes (whether RPL aware or
not), that will tolerate the RPL artifacts. not), that will tolerate the RPL artifacts.
An operator that finds itself with a high amount of traffic from the An operator that finds itself with a high amount of traffic from the
RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6
encapsulation if the leaf is not tolerant of the RPL artifacts. Such encapsulation if the leaf is not tolerant of the RPL artifacts. Such
skipping to change at page 54, line 29 skipping to change at page 54, line 29
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 is triggered when the DIO is both values . The migration procedure is triggered when the DIO 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 changes to 0x23. This options allows to send then it abruptly changes to 0x23. The 0x23 RPI Option allows to send
packets to not-RPL nodes, which should ignore the option and continue packets to not-RPL nodes. The not-RPL nodes should ignore the option
processing the packets. and continue 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 (abrupt
interoperation) in a network using 0x63 as the RPI Option Type value. changeover) in a network using 0x63 as the RPI Option Type value. It
It is suggested that RPL implementations accept both 0x63 and 0x23 is suggested that RPL implementations accept both 0x63 and 0x23 RPI
RPI Option type values when processing the header to enable Option type values when processing the header to enable
interoperability. interoperability.
11. IANA Considerations 11. IANA Considerations
11.1. Option Type in RPL Option 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.
skipping to change at page 55, line 35 skipping to change at page 55, line 35
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. Change to the DODAG Configuration Options Flags registry 11.2. Change to the DODAG Configuration Options Flags registry
This document requests IANA to change the name of the "DODAG This document requests IANA to change the name of the "DODAG
Configuration Option Flags" registry to "DODAG Configuration Option Configuration Option Flags" registry to "DODAG Configuration Option
Flags for MOP 0..6". Flags for MOP 0..6".
This document requests to be mentioned as a reference for this
change.
11.3. Change MOP value 7 to Reserved 11.3. Change MOP value 7 to Reserved
This document requests the changing the registration status of value This document requests the changing the registration status of value
7 in the Mode of Operation registry from Unassigned to Reserved. 7 in the Mode of Operation registry from Unassigned to Reserved.
This change is in support of future work. This change is in support of future work.
This document requests to be mentioned as a reference for this entry
in the registry.
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.
While a typical LLN may be a very poor origin for attack traffic (as While a typical LLN may be a very poor origin for attack traffic (as
the networks tend to be very slow, and the nodes often have very low the networks tend to be very slow, and the nodes often have very low
duty cycles), given enough nodes, LLNs could still have a significant duty cycles), given enough nodes, LLNs could still have a significant
impact, particularly if attack is targeting another LLN. impact, particularly if the attack is targeting another LLN.
Additionally, some uses of RPL involve large backbone ISP scale Additionally, some uses of RPL involve large backbone ISP scale
equipment [I-D.ietf-anima-autonomic-control-plane], which may be equipment [I-D.ietf-anima-autonomic-control-plane], which may be
equipped with multiple 100Gb/s interfaces. equipped with multiple 100Gb/s interfaces.
Blocking or careful filtering of IPv6-in-IPv6 traffic entering the Blocking or careful filtering of IPv6-in-IPv6 traffic entering the
LLN as described above will make sure that any attack that is mounted LLN as described above will make sure that any attack that is mounted
must originate from compromised nodes within the LLN. The use of must originate from compromised nodes within the LLN. The use of
BCP38 [BCP38] filtering at the RPL root on egress traffic will both BCP38 [BCP38] filtering at the RPL root on egress traffic will both
alert the operator to the existence of the attack, as well as drop alert the operator to the existence of the attack, as well as drop
the attack traffic. As the RPL network is typically numbered from a the attack traffic. As the RPL network is typically numbered from a
skipping to change at page 57, line 42 skipping to change at page 58, line 4
in-IPv6 and RH3 headers. As such, the compressor at the RPL-root in-IPv6 and RH3 headers. As such, the compressor at the RPL-root
will see the second RH3 header and MAY choose to discard the packet will see the second RH3 header and MAY choose to discard the packet
if the RH3 header has not been completely consumed. A consumed if the RH3 header has not been completely consumed. A consumed
(inert) RH3 header could be present in a packet that flows from one (inert) RH3 header could be present in a packet that flows from one
LLN, crosses the Internet, and enters another LLN. As per the LLN, crosses the Internet, and enters another LLN. As per the
discussion in this document, such headers do not need to be removed. discussion in this document, such headers do not need to be removed.
However, there is no case described in this document where an RH3 is However, there is no case described in this document where an RH3 is
inserted in a non-storing network on traffic that is leaving the LLN, inserted in a non-storing network on traffic that is leaving the LLN,
but this document should not preclude such a future innovation. It but this document should not preclude such a future innovation. It
should just be noted that an incoming RH3 must be fully consumed, or should just be noted that an incoming RH3 must be fully consumed, or
very carefully inspected. very carefully inspected to match a policy that applies to this
network and is correctly processed by the leaves.
The RPI, if permitted to enter the LLN, could be used by an attacker The RPI, if permitted to enter the LLN, could be used by an attacker
to change the priority of a packet by selecting a different to change the priority of a packet by selecting a different
RPLInstanceID, perhaps one with a higher energy cost, for instance. RPLInstanceID, perhaps one with a higher energy cost, for instance.
It could also be that not all nodes are reachable in an LLN using the It could also be that not all nodes are reachable in an LLN using the
default RPLInstanceID, but a change of RPLInstanceID would permit an default RPLInstanceID, but a change of RPLInstanceID would permit an
attacker to bypass such filtering. Like the RH3, an RPI is to be attacker to bypass such filtering. Like the RH3, an RPI is to be
inserted by the RPL root on traffic entering the LLN by first inserted by the RPL root on traffic entering the LLN by first
inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will
not be seen by the network. Upon reaching the destination node the not be seen by the network. Upon reaching the destination node the
RPI has no further meaning and is just skipped; the presence of a RPI has no further meaning and is just skipped; the presence of a
second RPI will have no meaning to the end node as the packet has second RPI will have no meaning to the end node as the packet has
already been identified as being at it's final destination. already been identified as being at it's final destination.
For traffic leaving a RUL, if the RUL adds an opaque RPI then the For traffic leaving a RUL, if the RUL adds an opaque RPI then the 6LR
description of the RAL applies. The 6LR as a RPL border router as a RPL border router SHOULD rewrite the RPI to indicate the
SHOULD rewrite the RPI to indicate the selected Instance and set the selected Instance and set the flags. This is done in order to avoid:
flags. This is done in order to avoid: 1) The leaf is an external 1) The leaf is an external router that passes a packet that it did
router that passes a packet that it did not generate and that carries not generate and that carries an unrelated RPI and 2) The leaf is an
an unrelated RPI and 2) The leaf is an attacker or presents attacker or presents misconfiguration and tries to inject traffic in
misconfiguration and tries to inject traffic in a protected instance. a protected instance. Also, this applies in the case where the leaf
Also, this applies in the case where the leaf is aware of the RPL is aware of the RPL instance and passes a correct RPI; the 6LR needs
instance and passes a correct RPI, the 6LR needs a configuration that a configuration that allows that leaf to inject in that instance.
allows that leaf to inject in that instance.
The RH3 and RPIs could be abused by an attacker inside of the network The RH3 and RPIs could be abused by an attacker inside of the network
to route packets on non-obvious ways, perhaps eluding observation. to route packets on non-obvious ways, perhaps eluding observation.
This usage appears consistent with a normal operation of [RFC6997] This usage appears consistent with a normal operation of [RFC6997]
and can not be restricted at all. This is a feature, not a bug. and can not be restricted at all. This is a feature, not a bug.
[RFC7416] deals with many other threats to LLNs not directly related [RFC7416] deals with many other threats to LLNs not directly related
to the use of IPv6-in-IPv6 headers, and this document does not change to the use of IPv6-in-IPv6 headers, and this document does not change
that analysis. that analysis.
skipping to change at page 61, line 47 skipping to change at page 62, line 7
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-45 (work in progress), November 2020. keyinfra-45 (work in progress), November 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-23 (work in progress), draft-ietf-roll-unaware-leaves-28 (work in progress),
November 2020. December 2020.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
skipping to change at page 63, line 17 skipping to change at page 63, line 28
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[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>.
Authors' Addresses Authors' Addresses
Maria Ines Robles Maria Ines Robles
Universidad Tecno. Nac.(UTN)-FRM, Argentina / Aalto University, Finland Universidad Tecno. Nac.(UTN)-FRM, Argentina/ Aalto University Finland
Email: mariainesrobles@gmail.com Email: mariainesrobles@gmail.com
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
470 Dawson Avenue 470 Dawson Avenue
Ottawa, ON K1Z 5V7 Ottawa, ON K1Z 5V7
CA CA
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/mcr/ URI: http://www.sandelman.ca/mcr/
 End of changes. 38 change blocks. 
99 lines changed or deleted 116 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/