draft-ietf-roll-useofrplinfo-34.txt   draft-ietf-roll-useofrplinfo-35.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Aalto/UTN-FRM 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: July 23, 2020 P. Thubert Expires: August 15, 2020 P. Thubert
Cisco Cisco
January 20, 2020 February 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-34 draft-ietf-roll-useofrplinfo-35
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 July 23, 2020. This Internet-Draft will expire on August 15, 2020.
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 3, line 4 skipping to change at page 3, line 4
7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 23 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 23
7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 24 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 24
7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 25 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 25
7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 26 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 26
7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 27 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 27
7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 27 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 27
7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 28 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 28
7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 29 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 29
7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 30 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 30
8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 31 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 32 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 33
8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 33 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 34
8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 33 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 34
8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 34 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 35
8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 35 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 36
8.2. Non-Storing Mode: Interaction between Leaf and Internet . 36 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 37
8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 36 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 37
8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 37 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 38
8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 38 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 39
8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 39 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 40
8.3. Non-SM: Interaction between Leafs . . . . . . . . . . . . 40 8.3. Non-SM: Interaction between Leafs . . . . . . . . . . . . 41
8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 40 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 41
8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 42 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 44
8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 43 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 46
8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 44 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 47
9. Operational Considerations of supporting 9. Operational Considerations of supporting
RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 45 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Operational considerations of introducing 0x23 . . . . . . . 46 10. Operational considerations of introducing 0x23 . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . 51 14.1. Normative References . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . 52 14.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
[RFC6550] is a routing protocol for constrained networks. [RFC6553] [RFC6550] is a routing protocol for constrained networks. [RFC6553]
defines the RPL Option carried within the IPv6 Hop-by-Hop Header to defines the RPL Option carried within the IPv6 Hop-by-Hop Header to
carry the RPLInstanceID and quickly identify inconsistencies (loops) carry the RPLInstanceID and quickly identify inconsistencies (loops)
in the routing topology. The RPL Option is commonly referred to as in the routing topology. The RPL Option is commonly referred to as
the RPL Packet Information (RPI) though the RPI is really the the RPL Packet Information (RPI) though the RPI is really the
abstract information that is defined in [RFC6550] and transported in abstract information that is defined in [RFC6550] and transported in
skipping to change at page 20, line 5 skipping to change at page 20, line 5
(loops) in the routing topology. In all cases the RH3 is not needed (loops) in the routing topology. In all cases the RH3 is not needed
because it is not used in storing mode. because it is not used in storing mode.
In each case, 6LR_i are the intermediate routers from source to In each case, 6LR_i are the intermediate routers from source to
destination. "1 <= i <= n", n is the number of routers (6LR) that destination. "1 <= i <= n", n is the number of routers (6LR) that
the packet goes through from source (6LN) to destination. the packet goes through from source (6LN) to destination.
The leaf can be a router 6LR or a host, both indicated as 6LN. The The leaf can be a router 6LR or a host, both indicated as 6LN. The
root refers to the 6LBR (see Figure 6). root refers to the 6LBR (see Figure 6).
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+----------------+
| Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | | Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst|
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+----------------+
| | RAL to root | No | No | | | RAL to root | No | No |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| Leaf - Root | root to RAL | No | No | | Leaf - Root | root to RAL | No | No |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| | root to RUL | No | No | | | root to RUL | No | No |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| | RUL to root | must | root | | | RUL to root | must | root |
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+----------------+
| | RAL to Int | No | No | | | RAL to Int | No | No |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| Leaf - Internet | Int to RAL | must | RAL (tgt) | | Leaf - Internet | Int to RAL | must | RAL (tgt) |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| | RUL to Int | must | root | | | RUL to Int | must | root |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| | Int to RUL | must | 6LR | | | Int to RUL | must | 6LR |
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+----------------+
| | RAL to RAL | No | No | | | RAL to RAL | No | No |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| | RAL to RUL | No | No | | | RAL to RUL | No | No |
+ Leaf - Leaf +--------------+------------+------------------+ + Leaf - Leaf +--------------+------------+----------------+
| | RUL to RAL | must | root/RAL(tgt) | | | RUL to RAL | must | root |
+ +--------------+------------+------------------+ + +--------------+------------+----------------+
| | RUL to RUL | must | root/6LR | | | RUL to RUL | must | root |
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+----------------+
Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode.
7.1. Storing Mode: Interaction between Leaf and Root 7.1. Storing Mode: Interaction between Leaf and Root
In this section is described the communication flow in storing mode In this section is described the communication flow in storing mode
(SM) between, (SM) between,
RAL to root RAL to root
skipping to change at page 23, line 13 skipping to change at page 23, line 13
(6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR)
When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),
the 6LR_1 will insert a RPI, encapsulated in a IPv6-in-IPv6 header. the 6LR_1 will insert a RPI, encapsulated in a IPv6-in-IPv6 header.
The IPv6-in-IPv6 header is addressed to the root (Node A). The root The IPv6-in-IPv6 header is addressed to the root (Node A). The root
removes the header and processes the packet. removes the header and processes the packet.
The Figure 8 shows the table that summarizes what headers are needed The Figure 8 shows the table that summarizes what headers are needed
for this use case where the IPv6-in-IPv6 header is addressed to the for this use case where the IPv6-in-IPv6 header is addressed to the
root (Node A). root (Node A).
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+----------------+-----------------+
| Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst |
| | src | | | | | | src | | | |
| | node | | | | | | node | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+----------------+-----------------+
| Added | -- | IP6-IP6(RPI) | | -- | | Added | -- | IP6-IP6(RPI) | | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+----------------+-----------------+
| Modified | -- | -- | IP6-IP6(RPI) | -- | | Modified | -- | -- | IP6-IP6(RPI) | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+----------------+-----------------+
| Removed | -- | -- | | IP6-IP6(RPI) | | Removed | -- | -- | | IP6-IP6(RPI) |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+----------------+-----------------+
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+----------------+-----------------+
Figure 8: SM: Summary of the use of headers from RUL to root. Figure 8: SM: Summary of the use of headers from RUL to root.
7.2. SM: Interaction between Leaf and Internet. 7.2. SM: Interaction between Leaf and Internet.
In this section is described the communication flow in storing mode In this section is described the communication flow in storing mode
(SM) between, (SM) between,
RAL to Internet RAL to Internet
skipping to change at page 26, line 5 skipping to change at page 26, line 5
modified. modified.
The originating node will ideally leave the IPv6 flow label as zero The originating node will ideally leave the IPv6 flow label as zero
so that the packet can be better compressed through the LLN. The so that the packet can be better compressed through the LLN. The
6LBR will set the flow label of the packet to a non-zero value when 6LBR will set the flow label of the packet to a non-zero value when
sending to the Internet, for details check [RFC6437]. sending to the Internet, for details check [RFC6437].
The Figure 10 shows the table that summarizes what headers are needed The Figure 10 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+-------------+-------------+--------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet|
| | src | | [i=2,...,n] | | dst | | | src | | [i=2,...,n] | | dst |
| | node | | | | | | | node | | | | |
| | (RUL) | | | | | | | (RUL) | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+-------------+-------------+--------+
| Added | -- |IP6-IP6(RPI)| -- | -- | -- | | Added | -- |IP6-IP6(RPI)| -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+-------------+-------------+--------+
| Modified| -- | -- | IP6-IP6(RPI) | -- | -- | | Modified| -- | -- |IP6-IP6(RPI) | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+-------------+-------------+--------+
| Removed | -- | -- | -- | IP6-IP6(RPI)| -- | | Removed | -- | -- | -- | IP6-IP6(RPI)| -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+-------------+-------------+--------+
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+-------------+-------------+--------+
Figure 10: SM: Summary of the use of headers from RUL to Internet. Figure 10: SM: Summary of the use of headers from RUL to Internet.
7.2.4. SM: Example of Flow from Internet to RUL. 7.2.4. SM: Example of Flow from Internet to RUL.
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
For example, a communication flow could be: Internet --> Node A For example, a communication flow could be: Internet --> Node A
skipping to change at page 27, line 5 skipping to change at page 27, line 5
Further details about this are mentioned in Further details about this are mentioned in
[I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN
acting as a plain host and not being aware of RPL. acting as a plain host and not being aware of RPL.
The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to
zero in order to aid in compression [RFC8138][RFC6437]. zero in order to aid in compression [RFC8138][RFC6437].
The Figure 11 shows the table that summarizes what headers are needed The Figure 11 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+-------+
| Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL | | Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL |
| | net | |[i=1,..,n-1] | | dst | | | net | |[i=1,..,n-1] | | dst |
| | src | | | | | | | src | | | | |
| | | | | | | | | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+-------+
| Inserted| -- |IP6-IP6(RPI)| | -- | -- | | Inserted| -- |IP6-IP6(RPI)| | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+-------+
| Modified| -- | -- | IP6-IP6(RPI) | -- | -- | | Modified| -- | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+-------+
| Removed | -- | -- | | IP6-IP6(RPI)| -- | | Removed | -- | -- | | IP6-IP6(RPI)| -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+-------+
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+-------+
Figure 11: SM: Summary of the use of headers from Internet to RUL. Figure 11: SM: Summary of the use of headers from Internet to RUL.
7.3. SM: Interaction between Leaf and Leaf 7.3. SM: Interaction between Leaf and Leaf
In this section is described the communication flow in storing mode In this section is described the communication flow in storing mode
(SM) between, (SM) between,
RAL to RAL RAL to RAL
skipping to change at page 31, line 50 skipping to change at page 31, line 50
In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG
root) has complete knowledge about the connectivity of all DODAG root) has complete knowledge about the connectivity of all DODAG
nodes, and all traffic flows through the root node. Thus, there is nodes, and all traffic flows through the root node. Thus, there is
no need for all nodes to know about the existence of RPL-unaware no need for all nodes to know about the existence of RPL-unaware
nodes. Only the 6LBR needs to act if compensation is necessary for nodes. Only the 6LBR needs to act if compensation is necessary for
not-RPL aware receivers. not-RPL aware receivers.
The table (Figure 14) summarizes what headers are needed in the The table (Figure 14) summarizes what headers are needed in the
following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6
header are to be inserted. It depicts the target destination address header are to be inserted. It depicts the target destination address
possible to a 6LN (indicated by "RAL"), to a 6LR (parent of a 6LN) or possible to a 6LN (indicated by "RAL"), to a 6LR (parent of a RUL) or
to the root. In cases where no IPv6-in-IPv6 header is needed, the to the root. In cases where no IPv6-in-IPv6 header is needed, the
column states as "No". There is no expectation on RPL that RPI can column states as "No". There is no expectation on RPL that RPI can
be omitted, because it is needed for routing, quality of service and be omitted, because it is needed for routing, quality of service and
compression. This specification expects that is always a RPI compression. This specification expects that is always a RPI
Present. Present. The term "may(up)" refers that the IPv6-in-IPv6 header may
be necessary in the upwards direction. The term "must(up)" refers
that the IPv6-in-IPv6 header must be present in the upwards
direction. The term "must(down)" refers that the IPv6-in-IPv6 header
must be present in the downward direction.
The leaf can be a router 6LR or a host, both indicated as 6LN The leaf can be a router 6LR or a host, both indicated as 6LN
(Figure 6). In the table (Figure 14) the (1) indicates a 6tisch case (Figure 6). In the table (Figure 14) the (1) indicates a 6tisch case
[RFC8180], where the RPI may still be needed for the instanceID to be [RFC8180], where the RPI may still be needed for the instanceID to be
available for priority/channel selection at each hop. available for priority/channel selection at each hop.
+-----------------+--------------+-----+-----+------------+------------+ The root always have to encapuslate on the way down
| Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6|
| between | | | | | dst | +--- ------------+-------------+-----+-----+--------------+----------+
+-----------------+--------------+-----+-----+------------+------------+ | Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP |
| | RAL to root | Yes | No | No | No | | between | | | | | dst |
+ +--------------+-----+-----+------------+------------+ +----------------+-------------+-----+-----+--------------+----------+
| Leaf - Root | root to RAL | Yes | Yes | No | No | | | RAL to root | Yes | No | No | No |
+ +--------------+-----+-----+------------+------------+ | +-------------+-----+-----+--------------+----------+
| | root to RUL | Yes | Yes | must | 6LR | | Leaf - Root | root to RAL | Yes | Yes | No | No |
| | | (1) | | | | | +-------------+-----+-----+--------------+----------+
+ +--------------+-----+-----+------------+------------+ | | root to RUL | Yes | Yes | must | 6LR |
| | RUL to root | Yes | No | must | root | | | | (1) | | | |
+-----------------+--------------+-----+-----+------------+------------+ | +-------------+-----+-----+--------------+----------+
| | RAL to Int | Yes | No | No | No | | | RUL to root | Yes | No | must | root |
+ +--------------+-----+-----+------------+------------+ +----------------+-------------+-----+-----+--------------+----------+
| Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | | | RAL to Int | Yes | No | may(up) | root |
+ +--------------+-----+-----+------------+------------+ | +-------------+-----+-----+--------------+----------+
| | RUL to Int | Yes | No | must | root | |Leaf - Internet | Int to RAL | Yes | Yes | must | RAL |
+ +--------------+-----+-----+------------+------------+ | +-------------+-----+-----+--------------+----------+
| | Int to RUL | Yes | Yes | must | 6LR | | | RUL to Int | Yes | No | must | root |
+-----------------+--------------+-----+-----+------------+------------+ | +-------------+-----+-----+--------------+----------+
| | RAL to RAL | Yes | Yes | must | root/RAL | | | Int to RUL | Yes | Yes | must | 6LR |
+ +--------------+-----+-----+------------+------------+ +----------------+-------------+-----+-----+--------------+----------+
| | RAL to RUL | Yes | Yes | must | root/6LR | | | RAL to RAL | Yes | Yes | may(up) | root |
+ Leaf - Leaf +--------------+-----+-----+------------+------------+ | | | | +--------------+----------+
| | RUL to RAL | Yes | Yes | must | root/RAL | | | | | | must(down) | RAL |
+ +--------------+-----+-----+------------+------------+ | Leaf - Leaf +-------------+-----+-----+--------------+----------+
| | RUL to RUL | Yes | Yes | must | root/6LR | | | RAL to RUL | Yes | Yes | may(up) | root |
+-----------------+--------------+-----+-----+------------+------------+ | | | | +--------------+----------+
| | | | | must(down) | 6LR |
| +-------------+-----+-----+--------------+----------+
| | RUL to RAL | Yes | Yes | must(up) | root |
| | | | +--------------+----------+
| | | | | must(down) | RAL |
| +-------------+-----+-----+--------------+----------+
| | RUL to RUL | Yes | Yes | must(up) | root |
| | | | +--------------+----------+
| | | | | must(down) | 6LR |
+----------------+-------------+-----+-----+--------------+----------+
Figure 14: Table that shows headers needed in Non-Storing mode: RPI, Figure 14: Table that shows headers needed in Non-Storing mode: RPI,
RH3, IPv6-in-IPv6 encapsulation. RH3, IPv6-in-IPv6 encapsulation.
8.1. Non-Storing Mode: Interaction between Leaf and Root 8.1. Non-Storing Mode: Interaction between Leaf and Root
In this section is described the communication flow in Non Storing In this section is described the communication flow in Non Storing
Mode (Non-SM) between, Mode (Non-SM) between,
RAL to root
RAL to root
root to RAL root to RAL
RUL to root RUL to root
root to RUL root to RUL
8.1.1. Non-SM: Example of Flow from RAL to root 8.1.1. Non-SM: Example of Flow from RAL to root
In non-storing mode the leaf node uses default routing to send In non-storing mode the leaf node uses default routing to send
traffic to the root. The RPI must be included since it contains the traffic to the root. The RPI must be included since it contains the
skipping to change at page 33, line 35 skipping to change at page 34, line 33
packet goes through from source (RAL) to destination (6LBR). packet goes through from source (RAL) to destination (6LBR).
This situation is the same case as storing mode. This situation is the same case as storing mode.
The Table 7 summarizes what headers are needed for this use case. The Table 7 summarizes what headers are needed for this use case.
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
| Header | RAL src | 6LR_i | 6LBR dst | | Header | RAL src | 6LR_i | 6LBR dst |
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
| Added headers | RPI | -- | -- | | Added headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI |
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Removed headers | -- | -- | RPI |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
Table 7: Non-SM: Summary of the use of headers from RAL to root Table 7: Non-SM: Summary of the use of headers from RAL to root
8.1.2. Non-SM: Example of Flow from root to RAL 8.1.2. Non-SM: Example of Flow from root to RAL
In this case the flow comprises: In this case the flow comprises:
root (6LBR) --> 6LR_i --> RAL (6LN) root (6LBR) --> 6LR_i --> RAL (6LN)
skipping to change at page 34, line 33 skipping to change at page 35, line 30
Table 8: Non-SM: Summary of the use of headers from root to RAL Table 8: Non-SM: Summary of the use of headers from root to RAL
8.1.3. Non-SM: Example of Flow from root to RUL 8.1.3. Non-SM: Example of Flow from root to RUL
In this case the flow comprises: In this case the flow comprises:
root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
For example, a communication flow could be: Node A (root) --> Node B For example, a communication flow could be: Node A (root) --> Node B
--> Node E --> Node G --> Node E --> Node G (RUL)
6LR_i are the intermediate routers from source to destination. In 6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i <= n", n is the number of routers (6LR) that the this case, "1 <= i <= n", n is the number of routers (6LR) that the
packet goes through from source (6LBR) to destination (RUL). packet goes through from source (6LBR) to destination (RUL).
In 6LBR the RH3 is added, it is modified at each intermediate 6LR In the 6LBR the RH3 is added, it is modified at each intermediate 6LR
(6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n),
but left there. As the RPI is added, then the IPv6 node which does but left there. As the RPI is added, then the IPv6 node which does
not understand the RPI, will ignore it (following RFC8200), thus not understand the RPI, will ignore it (following RFC8200), thus
encapsulation is not necessary. encapsulation is not necessary.
The Figure 15 depicts the table that summarizes what headers are The Figure 15 depicts the table that summarizes what headers are
needed for this use case. needed for this use case.
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Header | 6LBR | 6LR_i | 6LR_n | RUL | | Header | 6LBR | 6LR_i | 6LR_n | RUL |
skipping to change at page 36, line 51 skipping to change at page 38, line 5
RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst
For example, a communication flow could be: Node F (RAL) --> Node D For example, a communication flow could be: Node F (RAL) --> Node D
--> Node B --> Node A --> Internet --> Node B --> Node A --> Internet
6LR_i are the intermediate routers from source to destination. In 6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i <= n", n is the number of routers (6LR) that the this case, "1 <= i <= n", n is the number of routers (6LR) that the
packet goes through from source (RAL) to 6LBR. packet goes through from source (RAL) to 6LBR.
This case is identical to storing-mode case. 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 table
show 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
[RFC8138], and the 6LBR will set it to a non-zero value when sending [RFC8138], and the 6LBR will set it to a non-zero value when sending
towards the Internet [RFC6437]. towards the Internet [RFC6437].
The Table 9 summarizes what headers are needed for this use case. The Table 9 summarizes what headers are needed for this use case when
no encapsulation is used. The Table 10 summarizes what headers are
needed for this use case when encapsulation to the root is used.
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
| Header | RAL src | 6LR_i | 6LBR | Internet dst | | Header | RAL src | 6LR_i | 6LBR | Internet dst |
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
| Added headers | RPI | -- | -- | -- | | Added headers | RPI | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
| Untouched headers | -- | -- | RPI | RPI (Ignored) | | Untouched headers | -- | -- | RPI | RPI (Ignored) |
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
Table 9: Non-SM: Summary of the use of headers from RAL to Internet Table 9: Non-SM: Summary of the use of headers from RAL to Internet
with no encapsulation
+-----------+--------------+--------------+--------------+----------+
| Header | RAL src | 6LR_i | 6LBR | Internet |
| | | | | dst |
+-----------+--------------+--------------+--------------+----------+
| Added | IPv6-in-IPv6 | -- | -- | -- |
| headers | (RPI) | | | |
| Modified | -- | IPv6-in-IPv6 | -- | -- |
| headers | | (RPI) | | |
| Removed | -- | -- | IPv6-in-IPv6 | -- |
| headers | | | (RPI) | |
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+-----------+--------------+--------------+--------------+----------+
Table 10: Non-SM: Summary of the use of headers from RAL to Internet
with encapsulation to the root
8.2.2. Non-SM: Example of Flow from Internet to RAL 8.2.2. Non-SM: Example of Flow from Internet to RAL
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN) Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN)
For example, a communication flow could be: Internet --> Node A For example, a communication flow could be: Internet --> Node A
(root) --> Node B --> Node D --> Node F (RAL) (root) --> Node B --> Node D --> Node F (RAL)
6LR_i are the intermediate routers from source to destination. In 6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i <= n", n is the number of routers (6LR) that the this case, "1 <= i <= n", n is the number of routers (6LR) that the
packet goes through from 6LBR to destination (RAL). packet goes through from 6LBR to destination (RAL).
The 6LBR must add an RH3 header. As the 6LBR will know the path and The 6LBR must add an RH3 header. As the 6LBR will know the path and
address of the target node, it can address the IPv6-in-IPv6 header to address of the target node, it can address the IPv6-in-IPv6 header to
that node. The 6LBR will zero the flow label upon entry in order to that node. The 6LBR will zero the flow label upon entry in order to
skipping to change at page 37, line 40 skipping to change at page 39, line 16
6LR_i are the intermediate routers from source to destination. In 6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i <= n", n is the number of routers (6LR) that the this case, "1 <= i <= n", n is the number of routers (6LR) that the
packet goes through from 6LBR to destination (RAL). packet goes through from 6LBR to destination (RAL).
The 6LBR must add an RH3 header. As the 6LBR will know the path and The 6LBR must add an RH3 header. As the 6LBR will know the path and
address of the target node, it can address the IPv6-in-IPv6 header to address of the target node, it can address the IPv6-in-IPv6 header to
that node. The 6LBR will zero the flow label upon entry in order to that node. The 6LBR will zero the flow label upon entry in order to
aid compression [RFC8138]. aid compression [RFC8138].
The Table 10 summarizes what headers are needed for this use case. The Table 11 summarizes what headers are needed for this use case.
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Header | Internet | 6LBR | 6LR_i | RAL dst | | Header | Internet | 6LBR | 6LR_i | RAL dst |
| | src | | | | | | src | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Added | -- | IPv6-in-IPv6 | -- | -- | | Added | -- | IPv6-in-IPv6 | -- | -- |
| headers | | (RH3,RPI) | | | | headers | | (RH3,RPI) | | |
| Modified | -- | -- | IPv6-in-IPv6 | -- | | Modified | -- | -- | IPv6-in-IPv6 | -- |
| headers | | | (RH3,RPI) | | | headers | | | (RH3,RPI) | |
| Removed | -- | -- | -- | IPv6-in-IPv6 | | Removed | -- | -- | -- | IPv6-in-IPv6 |
| headers | | | | (RH3,RPI) | | headers | | | | (RH3,RPI) |
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
Table 10: Non-SM: Summary of the use of headers from Internet to RAL Table 11: Non-SM: Summary of the use of headers from Internet to RAL
8.2.3. Non-SM: Example of Flow from RUL to Internet 8.2.3. Non-SM: Example of Flow from RUL to Internet
In this case the flow comprises: In this case the flow comprises:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet
dst dst
For example, a communication flow could be: Node G --> Node E --> For example, a communication flow could be: Node G --> Node E -->
Node B --> Node A --> Internet Node B --> Node A --> Internet
skipping to change at page 40, line 22 skipping to change at page 41, line 22
| Modified | -- | -- | IP6-IP6 | -- | -- | | Modified | -- | -- | IP6-IP6 | -- | -- |
| headers | | | (RH3,RPI) | | | | headers | | | (RH3,RPI) | | |
+----------+--------+------------------+-----------+-----------+-----+ +----------+--------+------------------+-----------+-----------+-----+
| Removed | -- | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RH3,RPI) | | | headers | | | | (RH3,RPI) | |
+----------+--------+------------------+-----------+-----------+-----+ +----------+--------+------------------+-----------+-----------+-----+
|Untouched | -- | -- | -- | -- | -- | |Untouched | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+----------+--------+------------------+-----------+-----------+-----+ +----------+--------+------------------+-----------+-----------+-----+
Figure 18: Non-SM: Summary of the use of headers from Internet to RUL Figure 18: Non-SM: Summary of the use of headers from Internet to
[1] The last 6LR before the IPv6 node. RUL.
8.3. Non-SM: Interaction between Leafs 8.3. Non-SM: Interaction between Leafs
In this section is described the communication flow in Non Storing In this section is described the communication flow in Non Storing
Mode (Non-SM) between, Mode (Non-SM) between,
RAL to RAL RAL to RAL
RAL to RUL RAL to RUL
RUL to RAL RUL to RAL
RUL to RUL RUL to RUL
8.3.1. Non-SM: Example of Flow from RAL to RAL 8.3.1. Non-SM: Example of Flow from RAL to RAL
In this case the flow comprises: In this case the flow comprises:
RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F (RAL src)--> Node
Node B --> Node A (root) --> Node B --> Node E --> Node H D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL
dst)
6LR_ia are the intermediate routers from source to the root In this 6LR_ia are the intermediate routers from source to the root In this
case, 1 <= ia <= n, n is the number of routers (6LR) that the packet case, 1 <= ia <= n, n is the number of routers (6LR) that the packet
goes through from RAL to the root. goes through from RAL to the root.
6LR_id are the intermediate routers from the root to the destination. 6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia <= m", m is the number of the intermediate In this case, "1 <= ia <= m", m is the number of the intermediate
routers (6LR). routers (6LR).
This case involves only nodes in same RPL Domain. The originating This case involves only nodes in same RPL Domain. The originating
node will add a RPI to the original packet, and send the packet node will add a RPI to the original packet, and send the packet
upwards. upwards.
The originating node must put the RPI (RPI1) into an IPv6-in-IPv6 The originating node may put the RPI (RPI1) into an IPv6-in-IPv6
header addressed to the root, so that the 6LBR can remove that header addressed to the root, so that the 6LBR can remove that
header. If it does not, then additional resources are wasted on the header. If it does not, then the RPI1 is forwarded down from the
way down to carry the useless RPI. root in the inner header to no avail.
The 6LBR will need to insert an RH3 header, which requires that it The 6LBR will need to insert an RH3 header, which requires that it
add an IPv6-in-IPv6 header. It should be able to remove the add an IPv6-in-IPv6 header. It should be able to remove the
RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to
it. Otherwise, there may be a RPI buried inside the inner IP header, it. Otherwise, there may be a RPI buried inside the inner IP header,
which should get ignored. The root inserts a RPI (RPI2) alongside which should get ignored. The root inserts a RPI (RPI2) alongside
the RH3. the RH3.
Networks that use the RPL P2P extension [RFC6997] are essentially Networks that use the RPL P2P extension [RFC6997] are essentially
non-storing DODAGs and fall into this scenario or scenario non-storing DODAGs and fall into this scenario or scenario
Section 8.1.2, with the originating node acting as 6LBR. Section 8.1.2, with the originating node acting as 6LBR.
The Figure 19 shows the table that summarizes what headers are needed The Figure 19 shows the table that summarizes what headers are needed
for this use case. for this use case when encapsulation to the root takes place.
The Figure 20 shows the table that summarizes what headers are needed
for this use case when there is no encapsulation to the root.
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | dst | | | src | | | | dst |
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
| Added |IP6-IP6| | IP6-IP6 | -- | -- | | Added |IP6-IP6| | IP6-IP6 | -- | -- |
| headers |(RPI1) | |(RH3-> RAL, | | | | headers |(RPI1) | |(RH3-> RAL, | | |
| | | | RPI2) | | | | | | | RPI2) | | |
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
| Modified| -- | IP6-IP6 | -- | IP6-IP6 | -- | | Modified| -- | IP6-IP6 | -- | IP6-IP6 | -- |
| headers | | (RPI1) | |(RH3,RPI) | | | headers | | (RPI1) | |(RH3,RPI) | |
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
| Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 |
| headers | | | (RPI1) | | (RH3, | | headers | | | (RPI1) | | (RH3, |
| | | | | | RPI2) | | | | | | | RPI2) |
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
Figure 19: Non-SM: Summary of the use of headers for RAL to RAL. Figure 19: Non-SM: Summary of the use of headers for RAL to RAL with
encapsulation to the root.
+-----------+------+--------+---------+---------+---------+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL |
+-----------+------+--------+---------+---------+---------+
| Inserted | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | (RH3, | | |
| | | | RPI2) | | |
+-----------+------+--------+---------+---------+---------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- |
| headers | | | | (RH3, | |
| | | | | RPI2) | |
+-----------+------+--------+---------+---------+---------+
| Removed | -- | -- | -- | -- | IP6-IP6 |
| headers | | | | | (RH3, |
| | | | | | RPI2) |
| | | | | | RPI1 |
+-----------+------+--------+---------+---------+---------+
| Untouched | -- | -- | RPI1 | RPI1 | -- |
| headers | | | | | |
+-----------+------+--------+---------+---------+---------+
Figure 20: Non-SM: Summary of the use of headers for RAL to RAL
without encapsulation to the root.
8.3.2. Non-SM: Example of Flow from RAL to RUL 8.3.2. Non-SM: Example of Flow from RAL to RUL
In this case the flow comprises: In this case the flow comprises:
RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node) RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F (RAL) --> Node D
Node B --> Node A (root) --> Node B --> Node E --> Node G --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL)
6LR_ia are the intermediate routers from source to the root In this 6LR_ia are the intermediate routers from source to the root In this
case, 1 <= ia <= n, n is the number of intermediate routers (6LR) case, 1 <= ia <= n, n is the number of intermediate routers (6LR)
6LR_id are the intermediate routers from the root to the destination. 6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia <= m", m is the number of the intermediate In this case, "1 <= ia <= m", m is the number of the intermediate
routers (6LRs). routers (6LRs).
As in the previous case, the RAL (6LN) will insert a RPI (RPI_1) As in the previous case, the RAL (6LN) may insert a RPI (RPI1) header
header which must be in an IPv6-in-IPv6 header addressed to the root which must be in an IPv6-in-IPv6 header addressed to the root so that
so that the 6LBR can remove this RPI. The 6LBR will then insert an the 6LBR can remove this RPI. The 6LBR will then insert an RH3
RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id inside a new IPv6-in-IPv6 header addressed to the last 6LR_id (6LR_id
(6LR_id = m). = m) alongside the insertion of RPI2.
The Figure 20 shows the table that summarizes what headers are needed If the originating node does not not put the RPI (RPI1) into an IPv6-
for this use case. in-IPv6 header addressed to the root. Then, the RPI1 is forwarded
down from the root in the inner header to no avail.
The Figure 21 shows the table that summarizes what headers are needed
for this use case when encapsulation to the root takes place. The
Figure 22 shows the table that summarizes what headers are needed for
this use case when no encapsulation to the root takes place.
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- | | Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- |
| headers | (RPI1) | | (RH3, | | | | | headers | (RPI1) | | (RH3, | | | |
| | | | RPI2) | | | | | | | | RPI2) | | | |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
skipping to change at page 42, line 51 skipping to change at page 45, line 26
| | | | | RPI2) | | | | | | | | RPI2) | | |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- |
| headers | | | (RPI1) | | (RH3, | | | headers | | | (RPI1) | | (RH3, | |
| | | | | | RPI2) | | | | | | | | RPI2) | |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Untouched | -- | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- | -- |
| headers | | | | | | | | headers | | | | | | |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
Figure 20: Non-SM: Summary of the use of headers from RAL to RUL. Figure 21: Non-SM: Summary of the use of headers from RAL to RUL with
encapsulation to the root.
+-----------+------+--------+---------+---------+---------+---------+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL |
| | src | | | | | dst |
| | node | | | | | node |
+-----------+------+--------+---------+---------+---------+---------+
| Inserted | RPI1 | -- | IP6-IP6 | -- | -- | -- |
| headers | | | (RH3, | | | |
| | | | RPI2) | | | |
+-----------+------+--------+---------+---------+---------+---------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | | (RH3, | | |
| | | | | RPI2) | | |
+-----------+------+--------+---------+---------+---------+---------+
| Removed | -- | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | | (RH3, | |
| | | | | | RPI2) | |
+-----------+------+--------+---------+---------+---------+---------+
| Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 |
| headers | | | | | |(Ignored)|
+-----------+------+--------+---------+---------+---------+---------+
Figure 22: Non-SM: Summary of the use of headers from RAL to RUL
without encapsulation to the root.
8.3.3. Non-SM: Example of Flow from RUL to RAL 8.3.3. Non-SM: Example of Flow from RUL to RAL
In this case the flow comprises: In this case the flow comprises:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id
--> RAL dst (6LN) --> RAL dst (6LN)
For example, a communication flow could be: Node G --> Node E --> For example, a communication flow could be: Node G (RUL)--> Node E
Node B --> Node A (root) --> Node B --> Node E --> Node H --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL)
6LR_ia are the intermediate routers from source to the root. In this 6LR_ia are the intermediate routers from source to the root. In this
case, 1 <= ia <= n, n is the number of intermediate routers (6LR) case, 1 <= ia <= n, n is the number of intermediate routers (6LR)
6LR_id are the intermediate routers from the root to the destination. 6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia <= m", m is the number of the intermediate In this case, "1 <= ia <= m", m is the number of the intermediate
routers (6LR). routers (6LR).
This scenario is mostly identical to the previous one. The RPI In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1)
(RPI1) is added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will
header addressed to the root. The 6LBR will remove this RPI, and add remove this RPI, and add it's own IPv6-in-IPv6 header containing an
it's own IPv6-in-IPv6 header containing an RH3 header and an RPI RH3 header and an RPI (RPI2).
(RPI2).
The Figure 21 shows the table that summarizes what headers are needed The Figure 23 shows the table that summarizes what headers are needed
for this use case. for this use case.
+-----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+-----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
| Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- |
| headers | | (RPI1) | | (RH3, | | | | headers | | (RPI1) | | (RH3, | | |
| | | | | RPI2) | | | | | | | | RPI2) | | |
+-----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
| Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- |
| headers | | | (RPI1) | | (RH3, | | | headers | | | (RPI1) | | (RH3, | |
| | | | | | RPI2) | | | | | | | | RPI2) | |
+-----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
| Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 |
| headers | | | | (RPI1) | | (RH3, | | headers | | | | (RPI1) | | (RH3, |
| | | | | | | RPI2) | | | | | | | | RPI2) |
+-----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
| Untouched | -- | | -- | -- | -- | -- | |Untouched | -- | | -- | -- | -- | -- |
| headers | | | | | | | | headers | | | | | | |
+-----------+------+---------+---------+---------+---------+---------+ +----------+------+---------+---------+---------+---------+---------+
Figure 21: Non-SM: Summary of the use of headers from RUL to RAL. Figure 23: Non-SM: Summary of the use of headers from RUL to RAL.
8.3.4. Non-SM: Example of Flow from RUL to RUL 8.3.4. Non-SM: Example of Flow from RUL to RUL
In this case the flow comprises: In this case the flow comprises:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id
--> RUL (IPv6 dst node) --> RUL (IPv6 dst node)
For example, a communication flow could be: Node G --> Node E --> For example, a communication flow could be: Node G --> Node E -->
Node B --> Node A (root) --> Node C --> Node J Node B --> Node A (root) --> Node C --> Node J
6LR_ia are the intermediate routers from source to the root. In this 6LR_ia are the intermediate routers from source to the root. In this
case, 1 <= ia <= n, n is the number of intermediate routers (6LR) case, 1 <= ia <= n, n is the number of intermediate routers (6LR)
6LR_id are the intermediate routers from the root to the destination. 6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia <= m", m is the number of the intermediate In this case, "1 <= ia <= m", m is the number of the intermediate
routers (6LR). routers (6LR).
This scenario is the combination of the previous two cases. This scenario is the combination of the previous two cases.
The Figure 22 shows the table that summarizes what headers are needed The Figure 24 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
| Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL | | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL |
| | src | | | | | | dst | | | src | | | | | | dst |
| | node | | | | | | node | | | node | | | | | | node |
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
| Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | | Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI1)| | (RH3, | | | | | headers | | (RPI1)| | (RH3, | | | |
| | | | | RPI2) | | | | | | | | | RPI2) | | | |
skipping to change at page 44, line 48 skipping to change at page 47, line 48
| | | | | | RPI2)| | | | | | | | | RPI2)| | |
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
| Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- |
| headers | | | | (RPI1) | | (RH3, | | | headers | | | | (RPI1) | | (RH3, | |
| | | | | | | RPI2) | | | | | | | | | RPI2) | |
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
|Untouched| -- | -- | -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- | -- | -- |
| headers | | | | | | | | | headers | | | | | | | |
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
Figure 22: Non-SM: Summary of the use of headers from RUL to RUL Figure 24: Non-SM: Summary of the use of headers from RUL to RUL
9. Operational Considerations of supporting RUL-leaves 9. Operational Considerations of supporting RUL-leaves
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
skipping to change at page 46, line 43 skipping to change at page 49, line 43
In case that a node join to a network that only process 0x63, it In case that a node join to a network that only process 0x63, it
would produce a flag day as was mentioned previously. Indicating the would produce a flag day as was mentioned previously. Indicating the
new RPI in the DODAG Configuration Option Flag is a way to avoid the new RPI in the DODAG Configuration Option Flag is a way to avoid the
flag day in a network. It is recommended that a network process both flag day in a network. It is recommended that a network process both
options to enable interoperability. options to enable interoperability.
11. IANA Considerations 11. IANA Considerations
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 23. Figure 25.
+-------+-------------------+------------------------+---------- -+ +-------+-------------------+------------------------+---------- -+
| 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](*)|
+-------+-----+-----+-------+------------------------+------------+ +-------+-----+-----+-------+------------------------+------------+
| 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] |
| | | | | |[RFCXXXX](*)| | | | | | |[RFCXXXX](*)|
+-------+-----+-----+-------+------------------------+------------+ +-------+-----+-----+-------+------------------------+------------+
Figure 23: Option Type in RPL Option.(*)represents this document Figure 25: Option Type in RPL Option.(*)represents this document
DODAG Configuration option is updated as follows (Figure 24): DODAG Configuration option is updated as follows (Figure 26):
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document | | 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- Figure 26: DODAG Configuration Option Flag to indicate the RPI-flag-
day. day.
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
skipping to change at page 52, line 39 skipping to change at page 55, line 39
[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,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-13 (work in Lossy Networks", draft-ietf-6lo-ap-nd-19 (work in
progress), January 2020. progress), February 2020.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", draft-ietf-6lo-backbone-router-13 (work Backbone Router", draft-ietf-6lo-backbone-router-16 (work
in progress), September 2019. in progress), February 2020.
[I-D.ietf-6tisch-dtsecurity-secure-join] [I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf- Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress), 6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017. February 2017.
[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-21 (work in progress), November 2019. plane-22 (work in progress), February 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-34 (work in progress), January 2020. keyinfra-35 (work in progress), February 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-08 (work in progress), draft-ietf-roll-unaware-leaves-09 (work in progress),
December 2019. January 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 54, line 40 skipping to change at page 57, line 40
May 2017, <https://www.rfc-editor.org/info/rfc8180>. May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[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
Aalto University, Finland/Uni. Tec. Nac.(UTN) - FRM, Argentina 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/
Pascal Thubert Pascal Thubert
 End of changes. 54 change blocks. 
214 lines changed or deleted 307 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/