< draft-ietf-roll-useofrplinfo-41.txt   draft-ietf-roll-useofrplinfo-42.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: March 25, 2021 P. Thubert Expires: May 16, 2021 P. Thubert
Cisco Cisco
September 21, 2020 November 12, 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-41 draft-ietf-roll-useofrplinfo-42
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
RFC6553 adding a change to the RPI Option Type. Additionally, this RFC6553 adding a change to the RPI Option Type. Additionally, this
document updates RFC6550 defining a flag in the DIO Configuration document updates RFC6550 defining a flag in the DIO Configuration
option to indicate about this change and updates [RFC8138] as well to option to indicate about this change and updates RFC8138 as well to
consider the new Option Type when the RPL Option is decompressed. consider the new Option Type when the RPL Option is decompressed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 25, 2021. This Internet-Draft will expire on May 16, 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 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
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 RFC6550, RFC6553 and RFC8138 . . . . . . . . . . . 7
4.1. Updates to RFC6550: Advertising External Routes with Non- 4.1. Updates to RFC6550 . . . . . . . . . . . . . . . . . . . 7
Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 4.1.1. Advertising External Routes with Non-Storing Mode
4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8 Signaling. . . . . . . . . . . . . . . . . . . . . . 7
4.3. Updates to RFC6550: 4.1.2. Configuration Options and Mode
Configuration Options and Mode of Operation . . . . . . . . . . . . . . . . . . . . 8
of Operation . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Indicating the new RPI in the
4.4. Updates to RFC6550: Indicating the new RPI in the DODAG Configuration option Flag. . . . . . . . . . . 9
DODAG Configuration option Flag. . . . . . . . . . . . . 12 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 10
4.5. Updates to RFC8138: Indicating the way to decompress with 4.3. Updates to RFC8138: Indicating the way to decompress with
the new RPI Option Type. . . . . . . . . . . . . . . . . 13 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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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.1. Option Type in RPL Option . . . . . . . . . . . . . . . 54
11.2. Changes to DODAG Configuration Options Flags . . . . . . 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 . . . . . . . . . . . . . . . . . . . 55
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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 traffic: in storing mode (SM), it
is fully stateful; in non-storing mode (Non-SM), it is fully source is fully stateful; in non-storing mode (Non-SM), it is fully source
routed. A RPL Instance is either fully storing or fully non-storing, routed. A RPL Instance is either fully storing or fully non-storing,
i.e. a RPL Instance with a combination of storing and non-storing i.e. a RPL Instance with a combination of storing and non-storing
nodes is not supported with the current specifications at the time of nodes is not supported with the current specifications at the time of
writing this document. writing this document.
4. Updates to RFC6553, RFC6550 and RFC8138 4. Updates to RFC6550, RFC6553 and RFC8138
4.1. Updates to RFC6550: Advertising External Routes with Non-Storing 4.1. Updates to RFC6550
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
has been learned through an alternate protocol, for instance a route has been learned through an alternate protocol, for instance a route
to a prefix that is outside the RPL domain but reachable via a 6LR. to a prefix that is outside the RPL domain but reachable via a 6LR.
Being outside of the RPL domain, a node that is reached via an Being outside of the RPL domain, a node that is reached via an
external target cannot be guaranteed to ignore the RPL artifacts and external target cannot be guaranteed to ignore the RPL artifacts and
cannot be expected to process the [RFC8138] compression correctly. cannot be expected to process the [RFC8138] compression correctly.
This means that the RPL artifacts should be contained in an IP-in-IP This means that the RPL artifacts should be contained in an IP-in-IP
skipping to change at page 8, line 39 skipping to change at page 8, line 39
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
injected an external route MUST uncompress the packet before injected an external route MUST uncompress the packet before
forwarding over that external route. forwarding over that external route.
4.1.2. Configuration Options and Mode of Operation
Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as
containing a series of Flags in the first octet of the payload.
Anticipating future work to revise RPL relating to how the LLN and
DODAG are configured, this document renames the DODAG Configuration
Option Flags registry so that it applies to Mode of Operation (MOP)
values zero (0) to six (6) only, leaving the flags unassigned for MOP
value seven (7).The MOP is described in RFC6550 section 6.3.1.
In addition, this document reserves MOP value 7 for future expansion.
See Sections 11.2 and 11.3.
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
new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this
section defines a flag in the DIO Configuration option, to indicate
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
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
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
Type of the RPL Option.
This is done using a DODAG Configuration option flag which will
signal "RPI 0x23 enable" and propagate through the network.
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
between 0 to 6.
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
DIO messages. The DODAG Configuration option distributes
configuration information. It is generally static, and does not
change within the DODAG. This information is configured at the DODAG
root and distributed throughout the DODAG with the DODAG
Configuration option. Nodes other than the DODAG root do not modify
this information when propagating the DODAG Configuration option.
Currently, the DODAG Configuration option in [RFC6550] states: "the
unused bits MUST be initialize to zero by the sender and MUST be
ignored by the receiver". If the flag is received with a value zero
(which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI Option Type
(0x63) value. If the flag is received with a value of 1, then the
value for the RPL Option MUST be set to 0x23.
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
Section 11 and is shown here for convenience):
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
Figure 2: DODAG Configuration option Flag to indicate the RPI-flag-
day.
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
will not trigger DIO messages until a DIO message is received
indicating the RPI value to be used. The node will use the value
0x23 if the network supports this feature.
4.2. Updates to RFC6553: Indicating the new RPI Option Type. 4.2. Updates to RFC6553: Indicating the new RPI Option Type.
This modification is required in order to be able to send, for This modification is required in order to be able to send, for
example, IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node example, IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node
through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6
encapsulation. encapsulation.
[RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in [RFC6553] (Section 6, Page 7) states as shown in Figure 3, that in
the Option Type field of the RPL Option, the two high order bits must the Option Type field of the RPL Option, the two high order bits must
be set to '01' and the third bit is equal to '1'. The first two bits be set to '01' and the third bit is equal to '1'. The first two bits
indicate that the IPv6 node must discard the packet if it doesn't indicate that the IPv6 node must discard the packet if it doesn't
recognize the Option Type, and the third bit indicates that the recognize the Option Type, and the third bit indicates that the
Option Data may change in route. The remaining bits serve as the Option Data may change in route. The remaining bits serve as the
Option Type. Option Type.
+-------+-------------------+----------------+-----------+ +-------+-------------------+----------------+-----------+
| Hex | Binary Value | Description | Reference | | Hex | Binary Value | Description | Reference |
+ Value +-------------------+ + + + Value +-------------------+ + +
| | act | chg | rest | | | | | act | chg | rest | | |
+-------+-----+-----+-------+----------------+-----------+ +-------+-----+-----+-------+----------------+-----------+
| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |
+-------+-----+-----+-------+----------------+-----------+ +-------+-----+-----+-------+----------------+-----------+
Figure 2: Option Type in RPL Option. Figure 3: Option Type in RPL Option.
This document illustrates that it is not always possible to know for This document illustrates that it is not always possible to know for
sure at the source that a packet will only travel within the RPL sure at the source that a packet will only travel within the RPL
domain or may leave it. domain or may leave it.
At the time [RFC6553] was published, leaking a Hop-by-Hop header in At the time [RFC6553] was published, leaking a Hop-by-Hop header in
the outer IPv6 header chain could potentially impact core routers in the outer IPv6 header chain could potentially impact core routers in
the internet. So at that time, it was decided to encapsulate any the internet. So at that time, it was decided to encapsulate any
packet with a RPL Option using IPv6-in-IPv6 in all cases where it was packet with a RPL Option using IPv6-in-IPv6 in all cases where it was
unclear whether the packet would remain within the RPL domain. In unclear whether the packet would remain within the RPL domain. In
skipping to change at page 10, line 9 skipping to change at page 11, line 40
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], abusively naming it RPI Option Type for simplicity, to
(Figure 3): the two high order bits MUST be set to '00' and the third (Figure 4): the two high order bits MUST be set to '00' and the third
bit is equal to '1'. The first two bits indicate that the IPv6 node bit is equal to '1'. The first two bits indicate that the IPv6 node
MUST skip over this option and continue processing the header MUST skip over this option and continue processing the header
([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and ([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and
the third bit continues to be set to indicate that the Option Data the third bit continues to be set to indicate that the Option Data
may change en route. The rightmost five bits remain at 0x3(00011). may change en route. The rightmost five bits remain at 0x3(00011).
This ensures that a packet that leaves the RPL domain of an LLN (or This ensures that a packet that leaves the RPL domain of an LLN (or
that leaves the LLN entirely) will not be discarded when it contains that leaves the LLN entirely) will not be discarded when it contains
the RPL Option. the 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-
skipping to change at page 10, line 36 skipping to change at page 12, line 19
This is a significant update to [RFC6553]. This is a significant update to [RFC6553].
+-------+-------------------+-------------+------------+ +-------+-------------------+-------------+------------+
| 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](*)|
+-------+-----+-----+-------+-------------+------------+ +-------+-----+-----+-------+-------------+------------+
Figure 3: Revised Option Type in RPL Option. (*)represents this Figure 4: Revised Option Type in RPL Option. (*)represents this
document document
Without the signaling described below, this change would otherwise Without the signaling described below, this change would otherwise
create a lack of interoperation (flag day) for existing networks create a lack of interoperation (flag day) for existing networks
which are currently using 0x63 as the RPI Option Type value. A move which are currently using 0x63 as the RPI Option Type value. A move
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
skipping to change at page 11, line 33 skipping to change at page 13, line 17
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.(see change does not adversely affect the non-storing case.(see
Section 4.4) Section 4.1.3)
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.
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
section defines a flag in the DIO Configuration option, to indicate
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
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
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
Type of the RPL Option.
This is done using a DODAG Configuration option flag which will
signal "RPI 0x23 enable" and propagate through the network.
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
between 0 to 6.
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
DIO messages. The DODAG Configuration option distributes
configuration information. It is generally static, and does not
change within the DODAG. This information is configured at the DODAG
root and distributed throughout the DODAG with the DODAG
Configuration option. Nodes other than the DODAG root do not modify
this information when propagating the DODAG Configuration option.
Currently, the DODAG Configuration option in [RFC6550] states: "the
unused bits MUST be initialize to zero by the sender and MUST be
ignored by the receiver". If the flag is received with a value zero
(which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI Option Type
(0x63) value. If the flag is received with a value of 1, then the
value for the RPL Option MUST be set to 0x23.
Bit number three of the flag field in the DODAG Configuration option
is to be used as shown in Figure 4 (which is the same as Figure 39 in
Section 11 and is shown here for convenience):
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
Figure 4: DODAG Configuration option Flag to indicate the RPI-flag-
day.
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
will not trigger DIO messages until a DIO message is received
indicating the RPI value to be used. The node will use the value
0x23 if the network supports this feature.
4.5. Updates to RFC8138: Indicating the way to decompress with the new 4.3. 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.4. E.g. If the network is Configuration option defined in Section 4.1.3. E.g. If the network
in 0x23 mode (by DIO option), then it should be decompressed to 0x23. is 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
and RUL to RUL include compression of the IPv6-in-IPv6 and RPI and RUL to RUL include compression of the IPv6-in-IPv6 and RPI
skipping to change at page 18, line 37 skipping to change at page 18, line 37
- Each IPv6 node (including Internet routers) obeys [RFC8200], so - Each IPv6 node (including Internet routers) obeys [RFC8200], so
that 0x23 RPI Option Type can be safely inserted. that 0x23 RPI Option Type can be safely inserted.
- All 6LRs obey [RFC8200]. - All 6LRs obey [RFC8200].
- 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 dont assume that the RUL supports IP-in-IP - In the uses cases, we don't assume that the RUL supports IP-in-
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 description of the RAL applies. The 6LR as a RPL border
router SHOULD rewrite the RPI to indicate the selected Instance
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 23, line 33 skipping to change at page 23, line 33
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Removed | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | IP6-IP6 | -- |
| headers | | | RPI | | | headers | | | RPI | |
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Untouched | -- | IP6-IP6 | -- | -- | | Untouched | -- | IP6-IP6 | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
Figure 10: SM: Summary of the use of headers from root to RUL Figure 10: SM: Summary of the use of headers from root to RUL
IP-in-IP encapsulation MAY be avoided for Root to RUL communication. IP-in-IP encapsulation may be avoided for Root to RUL communication.
In SM, it can be replaced by a loose RH3 header that indicates the In SM, it can be replaced by a loose RH3 header that indicates the
RUL, in which case the packet is routed to the 6LR as a normal SM RUL, in which case the packet is routed to the 6LR as a normal SM
operation, then the 6LR forwards to the RUL based on the RH3, and the operation, then the 6LR forwards to the RUL based on the RH3, and the
RUL ignores both the consumed RH3 and the RPI, as in Non-Storing RUL ignores both the consumed RH3 and the RPI, as in Non-Storing
Mode. Mode.
The Figure 11 summarizes what headers are needed for this scenario. The Figure 11 summarizes what headers are needed for this scenario.
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Header | 6LBR | 6LR_i | 6LR_n | RUL | | Header | 6LBR | 6LR_i | 6LR_n | RUL |
skipping to change at page 41, line 46 skipping to change at page 41, line 46
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. Having the RAL information about --> Node B --> Node A --> Internet. Having the RAL information about
the RPL domain, it may encapsulate to the root when the destination the RPL domain, the packet may be encapsulated to the root when the
is not in the RPL domain of the RAL. 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 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 11.2. Change to the DODAG Configuration Options Flags registry
This document changes the name of the "DODAG Configuration Option This document requests IANA to change the name of the "DODAG
Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP 0..6". Configuration Option Flags" registry to "DODAG Configuration Option
Flags for MOP 0..6".
11.3. Change MOP value 7 to Reserved 11.3. Change MOP value 7 to Reserved
This document changes the allocation status of the Mode of Operation This document requests the changing the registration status of value
(MOP) [ianamop] from Unassigned to Reserved. This change is in 7 in the Mode of Operation registry from Unassigned to Reserved.
support of future work related to capabilities. This change is in support of future work.
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
skipping to change at page 58, line 9 skipping to change at page 58, line 9
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
description of the RAL applies. The 6LR as a RPL border router
SHOULD rewrite the RPI to indicate the selected Instance and set the
flags. This is done in order to avoid: 1) The leaf is an external
router that passes a packet that it did not generate and that carries
an unrelated RPI and 2) The leaf is an attacker or presents
misconfiguration and tries to inject traffic in a protected instance.
Also, this applies in the case where the leaf is aware of the RPL
instance and passes a correct RPI, the 6LR needs a configuration that
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.
Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an
skipping to change at page 59, line 33 skipping to change at page 59, line 43
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 5 skipping to change at page 61, line 5
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
14.2. Informative References 14.2. Informative References
[DDOS-KREBS] [DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016, >145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k- <http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>. cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
skipping to change at page 61, line 36 skipping to change at page 61, line 32
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-29 (work in progress), September 2020. plane-30 (work in progress), October 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-43 (work in progress), August 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-18 (work in progress), June draft-ietf-roll-unaware-leaves-23 (work in progress),
2020. November 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 10 skipping to change at page 63, line 5
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>. May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/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
 End of changes. 31 change blocks. 
131 lines changed or deleted 134 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/