draft-ietf-roll-useofrplinfo-38.txt   draft-ietf-roll-useofrplinfo-39.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: September 24, 2020 P. Thubert Expires: December 10, 2020 P. Thubert
Cisco Cisco
March 23, 2020 June 8, 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-38 draft-ietf-roll-useofrplinfo-39
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 September 24, 2020. This Internet-Draft will expire on December 10, 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 5 skipping to change at page 3, line 5
7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 27 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 27
7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 28 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 28
7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 29 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 29
7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 30 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 30
7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 30 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 30
7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 31 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 31
7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 33 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 33
7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 34 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 34
8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 35 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 37 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 37
8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 38 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 37
8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 39 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 38
8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 39 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 39
8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 40 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 40
8.2. Non-Storing Mode: Interaction between Leaf and Internet . 41 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 41
8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 42 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 41
8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 43 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 43
8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 44 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 44
8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45
8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46 8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46
8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46
8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49
8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51
8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52
9. Operational Considerations of supporting 9. Operational Considerations of supporting
RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53
skipping to change at page 6, line 12 skipping to change at page 6, line 12
forward and route IPv6 packets. 6LoWPAN routers are present only in forward and route IPv6 packets. 6LoWPAN routers are present only in
route-over topologies." route-over topologies."
6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border
router located at the junction of separate 6LoWPAN networks or router located at the junction of separate 6LoWPAN networks or
between a 6LoWPAN network and another IP network. There may be one between a 6LoWPAN network and another IP network. There may be one
or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the
responsible authority for IPv6 prefix propagation for the 6LoWPAN responsible authority for IPv6 prefix propagation for the 6LoWPAN
network it is serving. An isolated LoWPAN also contains a 6LBR in network it is serving. An isolated LoWPAN also contains a 6LBR in
the network, which provides the prefix(es) for the isolated network." the network, which provides the prefix(es) for the isolated network."
Flag Day: A transition that involves having a network with different Flag Day: In this document, refers to a transition that involves
values of RPI Option Type. Thus the network does not work correctly having a network with different values of RPI Option Type.
(Lack of interoperation).
Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL-
aware-nodes send information to the root about their parents. Thus, aware-nodes send information to the root about their parents. Thus,
the root knows the topology. Because the root knows the topology, the root knows the topology. Because the root knows the topology,
the intermediate 6LRs do not maintain routing state and source the intermediate 6LRs do not maintain routing state and source
routing is needed. routing is needed.
Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes
(6LRs) maintain routing state (of the children) so that source (6LRs) maintain routing state (of the children) so that source
routing is not needed. routing is not needed.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
direction, for traffic coming from an external target into the LLN, direction, for traffic coming from an external target into the LLN,
the parent (6LR) that injects the traffic always encapsulates to the the parent (6LR) that injects the traffic always encapsulates to the
root. This whole operation is transparent to intermediate routers root. This whole operation is transparent to intermediate routers
that only see traffic between the 6LR and the Root, and only the Root that only see traffic between the 6LR and the Root, and only the Root
and the 6LRs that inject external routes in the network need to be and the 6LRs that inject external routes in the network need to be
upgraded to add this function to the network. upgraded to add this function to the network.
A RUL is a special case of external target when the target is A RUL is a special case of external target when the target is
actually a host and it is known to support a consumed Routing Header actually a host and it is known to support a consumed Routing Header
and to ignore a HbH header as prescribed by [RFC8200]. The target and to ignore a HbH header as prescribed by [RFC8200]. The target
may have been learned through as a host route or may have been may have been learned through an external routing protocol or may
registered to the 6LR using [RFC8505]. have been registered to the 6LR using [RFC8505].
In order to enable IP-in-IP all the way to a 6LN, it is beneficial In order to enable IP-in-IP all the way to a 6LN, it is beneficial
that the 6LN supports decapsulating IP-in-IP, but that is not assumed that the 6LN supports decapsulating IP-in-IP, but that is not assumed
by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a
packet SHOULD terminate the tunnel at a parent 6LR unless it is aware packet SHOULD terminate the tunnel at a parent 6LR unless it is aware
that the RUL supports IP-in-IP decapsulation. that the RUL supports IP-in-IP decapsulation.
A node that is reachable over an external route is not expected to A node that is reachable over an external route is not expected to
support [RFC8138]. Whether a decapsulation took place or not and support [RFC8138]. Whether a decapsulation took place or not and
even when the 6LR is delivering the packet to a RUL, the 6LR that even when the 6LR is delivering the packet to a RUL, the 6LR that
skipping to change at page 10, line 20 skipping to change at page 10, line 20
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-
capable) receives a packet with an RPL Option, it should ignore the capable) receives a packet with a RPL Option, it should ignore the
Hop-by-Hop RPL Option (skip over this option and continue processing Hop-by-Hop RPL Option (skip over this option and continue processing
the header). This is relevant, as it was mentioned previously, in the header). This is relevant, as it was mentioned previously, in
the case that there is a flow from RAL to Internet (see the case that there is a flow from RAL to Internet (see
Section 7.2.1). Section 7.2.1).
This is a significant update to [RFC6553]. This is a significant update to [RFC6553].
+-------+-------------------+-------------+------------+ +-------+-------------------+-------------+------------+
| Hex | Binary Value | Description | Reference | | Hex | Binary Value | Description | Reference |
+ Value +-------------------+ + + + Value +-------------------+ + +
skipping to change at page 14, line 24 skipping to change at page 14, line 24
node. The 6LN is a RPL aware router, or host (as a leaf). node. The 6LN is a RPL aware router, or host (as a leaf).
Additionally, for simplification purposes, it is supposed that the Additionally, for simplification purposes, it is supposed that the
6LBR has direct access to Internet and is the root of the DODAG, thus 6LBR has direct access to Internet and is the root of the DODAG, thus
the 6BBR is not present in the figure. the 6BBR is not present in the figure.
The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no
children hosts. children hosts.
The leaves marked as RUL (G and J) are devices which do not speak RPL The leaves marked as RUL (G and J) are devices which do not speak RPL
at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/
DAC and efficient-ND only to participate in the network [RFC6775]. DAC and 6LoWPAN ND only to participate in the network [RFC8505]. In
In the document these leaves (G and J) are also referred to as an the document these leaves (G and J) are also referred to as a RUL.
IPv6 node.
The 6LBR ("A") in the figure is the root of the Global DODAG. The 6LBR ("A") in the figure is the root of the Global DODAG.
+------------+ +------------+
| INTERNET ----------+ | INTERNET ----------+
| | | | | |
+------------+ | +------------+ |
| |
| |
| |
skipping to change at page 17, line 22 skipping to change at page 17, line 22
DODAG root MUST force it to zero when passing the packet out to the DODAG root MUST force it to zero when passing the packet out to the
Internet. The Internet will therefore not see any SenderRank Internet. The Internet will therefore not see any SenderRank
information. information.
Despite being legal to leave the RPI artifact in place, an Despite being legal to leave the RPI artifact in place, an
intermediate router that needs to add an extension header (e.g. RH3 intermediate router that needs to add an extension header (e.g. RH3
or RPL Option) MUST still encapsulate the packet in an (additional) or RPL Option) MUST still encapsulate the packet in an (additional)
outer IP header. The new header is placed after this new outer IP outer IP header. The new header is placed after this new outer IP
header. header.
A corollary is that an RH3 or RPL Option can only be removed by an A corollary is that an intermediate router can remove an RH3 or RPL
intermediate router if it is placed in an encapsulating IPv6 Header, Option only if it is placed in an encapsulating IPv6 Header that is
which is addressed TO the intermediate router. When it does so, the addressed TO this intermediate router. When doing the above, the
whole encapsulating header must be removed. (A replacement may be whole encapsulating header must be removed. (A replacement may be
added). This sometimes can result in outer IP headers being added). This sometimes can result in outer IP headers being
addressed to the next hop router using link-local address. addressed to the next hop router using link-local address.
Both the RPL Option and the RH3 headers may be modified in very Both the RPL Option and the RH3 headers may be modified in very
specific ways by routers on the path of the packet without the need specific ways by routers on the path of the packet without the need
to add and remove an encapsulating header. Both headers were to add and remove an encapsulating header. Both headers were
designed with this modification in mind, and both the RPL RH3 and the designed with this modification in mind, and both the RPL RH3 and the
RPL Option are marked mutable but recoverable: so an IPsec AH RPL Option are marked mutable but recoverable: so an IPsec AH
security header can be applied across these headers, but it can not security header can be applied across these headers, but it can not
skipping to change at page 17, line 47 skipping to change at page 17, line 47
The RPI MUST be present in every single RPL data packet. The RPI MUST be present in every single RPL data packet.
Prior to [RFC8138], there was significant interest in creating an Prior to [RFC8138], there was significant interest in creating an
exception to this rule and removing the RPI for downward flows in exception to this rule and removing the RPI for downward flows in
non-storing mode. This exception covered a very small number of non-storing mode. This exception covered a very small number of
cases, and caused significant interoperability challenges while cases, and caused significant interoperability challenges while
adding significant in the code and tests. The ability to compress adding significant in the code and tests. The ability to compress
the RPI down to three bytes or less removes much of the pressure to the RPI down to three bytes or less removes much of the pressure to
optimize this any further [I-D.ietf-anima-autonomic-control-plane]. optimize this any further [I-D.ietf-anima-autonomic-control-plane].
The earlier examples are more extensive to make sure that the process Throughout the following subsections, the examples are described in
is clear, while later examples are more concise. more details in the first subsections, and more concisely in the
later ones.
The uses cases are delineated based on the following requirements: The uses cases are delineated based on the following IPV6 and RPL
mandates:
The RPI has to be in every packet that traverses the LLN. The RPI has to be in every packet that traverses the LLN.
- Because of the above requirement, packets from the Internet have - Because of the above requirement, packets from the Internet have
to be encapsulated. to be encapsulated.
- A Header cannot be inserted or removed on the fly inside an IPv6 - A Header cannot be inserted or removed on the fly inside an IPv6
packet that is being routed. packet that is being routed.
- Extension headers may not be added or removed except by the - Extension headers may not be added or removed except by the
skipping to change at page 19, line 18 skipping to change at page 19, line 20
the destination is inside the LLN by looking if the destination the destination is inside the LLN by looking if the destination
address is matched by the DIO's Prefix Information Option (PIO) address is matched by the DIO's Prefix Information Option (PIO)
option. option.
The following table (Figure 7) itemizes which headers are needed in The following table (Figure 7) itemizes which headers are needed in
each of the following scenarios. It indicates whether an IPv6-in- each of the following scenarios. It indicates whether an IPv6-in-
IPv6 header must be added and what destination it must be addressed IPv6 header must be added and what destination it must be addressed
to: (1) the final destination (the RAL node that is the target to: (1) the final destination (the RAL node that is the target
(tgt)), (2) the "root", or (3) the 6LR parent of a RUL. (tgt)), (2) the "root", or (3) the 6LR parent of a RUL.
In cases where no IPv6-in-IPv6 header is needed, the column states as In cases where no IPv6-in-IPv6 header is needed, the column states
"No". If the IPv6-in-IPv6 header is needed, the column shows "must". "No", and the destination is N/A (Not Applicable). If the IPv6-in-
IPv6 header is needed, the column shows "must".
In all cases, the RPI is needed, since it identifies inconsistencies In all cases, the RPI is needed, since it identifies inconsistencies
(loops) in the routing topology. In general, the RH3 is not needed (loops) in the routing topology. In general, the RH3 is not needed
because it is not used in storing mode. However, there is one because it is not used in storing mode. However, there is one
scenario (from the root to the RUL in SM) where the RH3 can be used scenario (from the root to the RUL in SM) where the RH3 can be used
to indicate the RUL (Figure 11). to point at the RUL (Figure 11).
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 | N/A |
+ +--------------+------------+----------------+ + +--------------+------------+----------------+
| Leaf - Root | root to RAL | No | No | | Leaf - Root | root to RAL | No | N/A |
+ +--------------+------------+----------------+ + +--------------+------------+----------------+
| | root to RUL | must | 6LR | | | root to RUL | must | 6LR |
+ +--------------+------------+----------------+ + +--------------+------------+----------------+
| | RUL to root | must | root | | | RUL to root | must | root |
+---------------------+--------------+------------+----------------+ +---------------------+--------------+------------+----------------+
| | RAL to Int | may | root | | | RAL to Int | may | root |
+ +--------------+------------+----------------+ + +--------------+------------+----------------+
| 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 | N/A |
| Leaf - Leaf +--------------+------------+----------------+ | Leaf - Leaf +--------------+------------+----------------+
| | RAL to RUL | No(up) | 6LR | | | RAL to RUL | No(up) | N/A |
| + +------------+----------------+ | + +------------+----------------+
| | | must(down) | 6LR | | | | must(down) | 6LR |
| +--------------+------------+----------------+ | +--------------+------------+----------------+
| | RUL to RAL | must(up) | root | | | RUL to RAL | must(up) | root |
| | +------------+----------------+ | | +------------+----------------+
| | | must(down) | RAL | | | | must(down) | RAL |
| +--------------+------------+----------------+ | +--------------+------------+----------------+
| | RUL to RUL | must(up) | root | | | RUL to RUL | must(up) | root |
| | +------------+----------------+ | | +------------+----------------+
| | | must(down) | 6LR | | | | must(down) | 6LR |
skipping to change at page 23, line 7 skipping to change at page 23, line 7
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 (6LBR) --> Node B For example, a communication flow could be: Node A (6LBR) --> Node B
(6LR_i) --> Node E (6LR_n) --> Node G (RUL) (6LR_i) --> Node E (6LR_n) --> Node G (RUL)
6LR_i (Node B) represents the intermediate routers from the source 6LR_i (Node B) represents the intermediate routers from the source
(6LBR) to the destination (RUL), 1 <= i <= n, where n is the total (6LBR) to the destination (RUL), 1 <= i <= n, where n is the total
number of routers (6LR) that the packet goes through from the 6LBR number of routers (6LR) that the packet goes through from the 6LBR
(Node A) to the RUL (Node G). (Node A) to the RUL (Node G).
The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and
The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR
(6LR_n). The 6LR parent of the RUL removes the header and sends the parent of the RUL (6LR_n). The 6LR parent of the RUL removes the
packet to the RUL. header and sends the packet to the RUL.
The Figure 10 summarizes what headers are needed for this use case. The Figure 10 summarizes what headers are needed for this use case.
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Header | 6LBR | 6LR_i | 6LR_n | RUL | | Header | 6LBR | 6LR_i | 6LR_n | RUL |
| | src | | | dst | | | src | | | dst |
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Added | IP6-IP6 | -- | -- | -- | | Added | IP6-IP6 | -- | -- | -- |
| headers | (RPI) | | | | | headers | RPI | | | |
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Modified | -- | | -- | -- | | Modified | -- | | -- | -- |
| headers | | RPI | | | | headers | | RPI | | |
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Removed | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | IP6-IP6 | -- |
| headers | | | (RPI) | | | headers | | | RPI | |
+-----------+---------+---------+---------+-----+ +-----------+---------+---------+---------+-----+
| Untouched | -- | -- | -- | -- | | 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 SRH 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 SRH, and the operation, then the 6LR forwards to the RUL based on the RH3, and the
RUL ignores both the consumed SRH 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 |
| | src | i=(1,..,n-1) | | dst | | | src | i=(1,..,n-1) | | dst |
| | | | | | | | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Added | RPI, RH3 | -- | -- | -- | | Added | RPI, RH3 | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Modified | -- | RPI | RPI | -- | | Modified | -- | RPI | RPI | -- |
| headers | | | RH3(consumed) | | | headers | | | RH3(consumed) | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Removed | -- | -- | -- | -- | | Removed | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Untouched | -- | -- | -- | RPI, RH3 | | Untouched | -- | RH3 | -- | RPI, RH3 |
| headers | | | | (both | | headers | | | | (both |
| | | | | ignored) | | | | | | ignored) |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
Figure 11: SM: Summary of the use of headers from root to RUL without Figure 11: SM: Summary of the use of headers from root to RUL without
encapsulation encapsulation
7.1.4. SM: Example of Flow from RUL to Root 7.1.4. SM: Example of Flow from RUL to Root
In this case the flow comprises: In this case the flow comprises:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR)
For example, a communication flow could be: Node G (RUL) --> Node E For example, a communication flow could be: Node G (RUL) --> Node E
(6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR)
6LR_i represents the intermediate routers from the source (RUL) to 6LR_i represents the intermediate routers from the source (RUL) to
the destination (6LBR), 1 <= i <= n, where n is the total number of the destination (6LBR), 1 <= i <= n, where n is the total number of
routers (6LR) that the packet goes through from the RUL to the 6LBR. routers (6LR) that the packet goes through from the RUL to the 6LBR.
When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the
the 6LR_1 will insert an RPI, encapsulated in a IPv6-in-IPv6 header. 6LR_1 will insert encapsulate the packet in an IPv6-in-IPv6 header
The IPv6-in-IPv6 header is addressed to the root (Node A). The root and prepend an RPI. The IPv6-in-IPv6 header is addressed to the root
removes the header and processes the packet. (Node A). The root removes the header and processes the packet.
The Figure 12 shows the table that summarizes what headers are needed The Figure 12 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 | | -- |
| headers | | | -- | | | headers | | RPI | -- | |
+-----------+------+--------------+----------------+-----------------+ +-----------+------+--------------+----------------+-----------------+
| Modified | -- | -- | RPI | -- | | Modified | -- | -- | RPI | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+----------------+-----------------+ +-----------+------+--------------+----------------+-----------------+
| Removed | -- | -- | --- | IP6-IP6(RPI) | | Removed | -- | -- | --- | IP6-IP6 |
| headers | | | | | | headers | | | | RPI |
+-----------+------+--------------+----------------+-----------------+ +-----------+------+--------------+----------------+-----------------+
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | IP6-IP6 | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+----------------+-----------------+ +-----------+------+--------------+----------------+-----------------+
Figure 12: SM: Summary of the use of headers from RUL to root. Figure 12: 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,
skipping to change at page 26, line 13 skipping to change at page 26, line 13
(6LR) that the packet goes through from the RAL to the 6LBR. (6LR) that the packet goes through from the RAL to the 6LBR.
RPL information from RFC 6553 may go out to Internet as it will be RPL information from RFC 6553 may go out to Internet as it will be
ignored by nodes which have not been configured to be RPI aware. No ignored by nodes which have not been configured to be RPI aware. No
IPv6-in-IPv6 header is required. IPv6-in-IPv6 header is required.
On the other hand, the RAL may insert the RPI encapsulated in a IPv6- On the other hand, the RAL may insert the RPI encapsulated in a IPv6-
in-IPv6 header to the root. Thus, the root removes the RPI and send in-IPv6 header to the root. Thus, the root removes the RPI and send
the packet to the Internet. the packet to the Internet.
No IPv6-in-IPv6 header is required.
Note: In this use case, it is used a node as a leaf, but this use Note: In this use case, it is used a node as a leaf, but this use
case can be also applicable to any RPL-aware-node type (e.g. 6LR) case can be also applicable to any RPL-aware-node type (e.g. 6LR)
The Figure 13 summarizes what headers are needed for this use case The Figure 13 summarizes what headers are needed for this use case
when there is no encapsulation. The Figure 14 summarizes what when there is no encapsulation. Note that the RPI is modified by
headers are needed when encapsulation to the root takes place. 6LBR to set the SenderRank to zero in case that it is not already
zero. The Figure 14 summarizes what headers are needed when
encapsulation to the root takes place.
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Header | RAL | 6LR_i | 6LBR | Internet | | Header | RAL | 6LR_i | 6LBR | Internet |
| | src | | | dst | | | src | | | dst |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Added | RPI | -- | -- | -- | | Added | RPI | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Modified | -- | RPI | -- | -- | | Modified | -- | RPI | RPI | -- |
| headers | | | | | | headers | | | | |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Removed | -- | -- | -- | -- | | Removed | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Untouched | -- | -- | RPI | RPI | | Untouched | -- | -- | -- | RPI |
| headers | | | | (Ignored) | | headers | | | | (Ignored) |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
Figure 13: SM: Summary of the use of headers from RAL to Internet Figure 13: SM: Summary of the use of headers from RAL to Internet
with no encapsulation with no encapsulation
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Header | RAL | 6LR_i | 6LBR | Internet dst | | Header | RAL | 6LR_i | 6LBR | Internet dst |
| | src | | | | | | src | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Added |IP6-IP6 | -- | -- | -- | | Added | IP6-IP6 | -- | -- | -- |
| headers | (RPI) | | | | | headers | RPI | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Modified | -- | RPI | -- | -- | | Modified | -- | RPI | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Removed | -- | -- |IP6-IP6(RPI) | -- | | Removed | -- | -- | IP6-IP6 | -- |
| headers | | | | | | headers | | | RPI | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Untouched | -- | -- | -- | -- | | Untouched | -- | IP6-IP6 | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
Figure 14: SM: Summary of the use of headers from RAL to Internet Figure 14: SM: Summary of the use of headers from RAL to Internet
with encapsulation to the root (6LBR). with encapsulation to the root (6LBR).
7.2.2. SM: Example of Flow from Internet to RAL 7.2.2. SM: Example of Flow from Internet to RAL
In this case the flow comprises: In this case the flow comprises:
skipping to change at page 32, line 9 skipping to change at page 32, line 9
Figure 18: SM: Summary of the Use of Headers from RAL to RAL Figure 18: SM: Summary of the Use of Headers from RAL to RAL
7.3.2. SM: Example of Flow from RAL to RUL 7.3.2. SM: Example of Flow from RAL to RUL
In this case the flow comprises: In this case the flow comprises:
RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) --> RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) -->
6LR_id --> RUL (IPv6 dst node) 6LR_id --> RUL (IPv6 dst node)
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 E --> Node G (RUL) --> Node B--> Node A -->Node B --> Node E --> Node G (RUL)
6LR_ia represents the intermediate routers from source (RAL) to the 6LR_ia represents the intermediate routers from source (RAL) to the
common parent (the Root), 1 <= ia <= n, where n is the total number common parent (the Root), 1 <= ia <= n, where n is the total number
of routers (6LR) that the packet goes through from RAL to the Root. of routers (6LR) that the packet goes through from RAL to the Root.
6LR_id (Node E) represents the intermediate routers from the Root 6LR_id (Node E) represents the intermediate routers from the Root
(Node B) to destination RUL (Node G). In this case, 1 <= id <= m, (Node B) to destination RUL (Node G). In this case, 1 <= id <= m,
where m is the total number of routers (6LR) that the packet goes where m is the total number of routers (6LR) that the packet goes
through from the Root down to the destination RUL. through from the Root down to the destination RUL.
In this case, the packet from the RAL goes to 6LBR because the route In this case, the packet from the RAL goes to 6LBR because the route
to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an
RPI (RPI1) addressed to the root(6LBR). The root removes the RPI1 RPI (RPI1) addressed to the root(6LBR). The root does not removes
and inserts an RPI2 encapsulated to the 6LR parent of the RUL, which the RPI1 (the root cannot remove an RPI if there is no
removes the RPI2 before pasing the packet to the RUL. encapsulation). The root inserts an RPI2 encapsulated to the 6LR
parent of the RUL, which removes the RPI2 before pasing the packet to
the RUL.
The Figure 19 summarizes what headers are needed for this use case. The Figure 19 summarizes what headers are needed for this use case.
+----------+-------+-------+---------+---------+---------+---------+ +----------+-------+-------+---------+---------+---------+---------+
| Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | | Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+----------+-------+-------+---------+---------+---------+---------+ +----------+-------+-------+---------+---------+---------+---------+
| Added | | | IP6-IP6 | -- | -- | -- | | Added | | | IP6-IP6 | -- | -- | -- |
| headers | RPI1 | -- | (RPI2) | | | | | headers | RPI1 | -- | (RPI2) | | | |
skipping to change at page 34, line 49 skipping to change at page 34, line 49
router from the RUL source (Node G) to the root (6LBR) (Node A). In router from the RUL source (Node G) to the root (6LBR) (Node A). In
this case, 1 <= ia <= n, where n is the total number of routers (6LR) this case, 1 <= ia <= n, where n is the total number of routers (6LR)
that the packet goes through from the RUL to the root. 6LR_1 refers that the packet goes through from the RUL to the root. 6LR_1 refers
when ia=1. when ia=1.
6LR_id (Node C) represents the intermediate routers from the root 6LR_id (Node C) represents the intermediate routers from the root
(Node A) to the destination RUL dst node (Node J). In this case, 1 (Node A) to the destination RUL dst node (Node J). In this case, 1
<= id <= m, where m is the total number of routers (6LR) that the <= id <= m, where m is the total number of routers (6LR) that the
packet goes through from the root to destination RUL. packet goes through from the root to destination RUL.
The RPI is ignored at the RUL dst node.
The 6LR_1 (Node E) receives the packet from the RUL (Node G) and The 6LR_1 (Node E) receives the packet from the RUL (Node G) and
inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header
directed to the root. The root removes the outer header including directed to the root. The root removes the outer header including
the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR
father of the RUL. father of the RUL.
The Figure 21 shows the table that summarizes what headers are needed The Figure 21 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+----+-------------+--------+---------+--------+-------+---+ +---------+----+-------------+--------+---------+--------+-------+---+
skipping to change at page 40, line 4 skipping to change at page 39, line 32
Figure 24: Non-SM: Summary of the use of headers from root to RAL Figure 24: 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 (RUL) --> Node E --> Node G (RUL)
6LR_i represents the intermediate routers from source to destination. 6LR_i represents the intermediate routers from source to destination.
In this case, 1 <= i <= n, where n is the total number of routers In this case, 1 <= i <= n, where n is the total number of routers
(6LR) that the packet goes through from source (6LBR) to destination (6LR) that the packet goes through from source (6LBR) to destination
(RUL). (RUL).
In the 6LBR, the RH3 is added; it is then modified at each In the 6LBR, the RH3 is added; it is then modified at each
intermediate 6LR (6LR_1 and so on), and it is fully consumed in the intermediate 6LR (6LR_1 and so on), and it is fully consumed in the
last 6LR (6LR_n) but is left in place. When the RPI is added, the last 6LR (6LR_n) but is left in place. When the RPI is added, the
IPv6 node, which does not understand the RPI, will ignore it (per RUL, which does not understand the RPI, will ignore it (per
[RFC8200]); thus, encapsulation is not necessary. [RFC8200]); thus, encapsulation is not necessary.
The Figure 25 depicts the table that summarizes what headers are The Figure 25 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 |
| | src | i=(1,..,n-1) | | dst | | | src | i=(1,..,n-1) | | dst |
| | | | | | | | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
skipping to change at page 41, line 5 skipping to change at page 40, line 39
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) 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 (root) Node B --> Node A (root)
6LR_i represents the intermediate routers from source to destination. 6LR_i represents the intermediate routers from source to destination.
In this case, 1 <= i <= n, where n is the total number of routers In this case, 1 <= i <= n, where n is the total number of routers
(6LR) that the packet goes through from source (RUL) to destination (6LR) that the packet goes through from source (RUL) to destination
(6LBR). For example, 6LR_1 (i=1) is the router that receives the (6LBR). For example, 6LR_1 (i=1) is the router that receives the
packets from the IPv6 node. packets from the RUL.
In this case, the RPI is added by the first 6LR (6LR_1) (Node E), In this case, the RPI is added by the first 6LR (6LR_1) (Node E),
encapsulated in an IPv6-in-IPv6 header, and modified in the encapsulated in an IPv6-in-IPv6 header, and modified in the
subsequent 6LRs in the flow. The RPI and the entire packet are subsequent 6LRs in the flow. The RPI and the entire packet are
consumed by the root. consumed by the root.
The Figure 26 shows the table that summarizes what headers are needed The Figure 26 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+----+-----------------+-----------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
skipping to change at page 42, line 37 skipping to change at page 42, line 24
when no encapsulation is used. The Figure 28 summarizes what headers when no encapsulation is used. The Figure 28 summarizes what headers
are needed for this use case when encapsulation to the root is used. are needed for this use case when encapsulation to the root is used.
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Header | RAL | 6LR_i | 6LBR | Internet | | Header | RAL | 6LR_i | 6LBR | Internet |
| | src | | | dst | | | src | | | dst |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Added | RPI | -- | -- | -- | | Added | RPI | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Modified | -- | RPI | -- | -- | | Modified | -- | RPI | RPI | -- |
| headers | | | | | | headers | | | | |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Removed | -- | -- | -- | -- | | Removed | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
| Untouched | -- | -- | RPI | RPI | | Untouched | -- | -- | -- | RPI |
| headers | | | | (Ignored) | | headers | | | | (Ignored) |
+-----------+-----+-------+------+-----------+ +-----------+-----+-------+------+-----------+
Figure 27: Non-SM: Summary of the use of headers from RAL to Internet Figure 27: Non-SM: Summary of the use of headers from RAL to Internet
with no encapsulation with no encapsulation
+-----------+--------------+--------------+--------------+----------+ +-----------+--------------+--------------+--------------+----------+
| Header | RAL | 6LR_i | 6LBR | Internet | | Header | RAL | 6LR_i | 6LBR | Internet |
| | src | | | dst | | | src | | | dst |
+-----------+--------------+--------------+--------------+----------+ +-----------+--------------+--------------+--------------+----------+
skipping to change at page 44, line 34 skipping to change at page 44, line 34
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
6LR_i are the intermediate routers from source to destination, 1 <= i 6LR_i represents the intermediate routers from source to destination,
<= n, where n is the total number of routers (6LRs) that the packet 1 <= i <= n, where n is the total number of routers (6LRs) that the
goes through from the source (RUL) to the 6LBR, e.g., 6LR_1 (i=1). packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1
(i=1).
In this case the flow label is recommended to be zero in the IPv6 In this case the flow label is recommended to be zero in the RUL. As
node. As RPL headers are added in the IPv6 node packet, the first RPL headers are added in the RUL packet, the first 6LR (6LR_1) will
6LR (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The add an RPI inside a new IPv6-in-IPv6 header. The IPv6-in-IPv6 header
IPv6-in-IPv6 header will be addressed to the root. This case is will be addressed to the root. This case is identical to the
identical to the storing-mode case (see Section 7.2.3). storing-mode case (see Section 7.2.3).
The Figure 30 shows the table that summarizes what headers are needed The Figure 30 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet|
| |src | | [i=2,..,n] | | dst | | |src | | [i=2,..,n] | | dst |
| |node| | | | | | |node| | | | |
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Added | -- |IP6-IP6(RPI) | -- | -- | -- | | Added | -- |IP6-IP6(RPI) | -- | -- | -- |
skipping to change at page 47, line 19 skipping to change at page 47, line 19
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 an RPI to the original packet, and send the packet node will add an RPI to the original packet, and send the packet
upwards. upwards.
The originating node may 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 the RPI1 is forwarded down from the header. If it does not, then the RPI1 is forwarded down from the
root in the inner header to no avail. 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 removes the RPI(RPI1), as it was
RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to contained in an IPv6-in-IPv6 header addressed to it. Otherwise,
it. Otherwise, there may be an RPI buried inside the inner IP there may be an RPI buried inside the inner IP header, which should
header, which should get ignored. The root inserts an RPI (RPI2) get ignored. The root inserts an RPI (RPI2) alongside the RH3.
alongside 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 32 shows the table that summarizes what headers are needed The Figure 32 shows the table that summarizes what headers are needed
for this use case when encapsulation to the root takes place. for this use case when encapsulation to the root takes place.
The Figure 33 shows the table that summarizes what headers are needed The Figure 33 shows the table that summarizes what headers are needed
for this use case when there is no encapsulation to the root. Note for this use case when there is no encapsulation to the root. Note
that in the Modified headers row, going up in each 6LR_ia only the that in the Modified headers row, going up in each 6LR_ia only the
RPI1 is changed. Going down, in each 6LR_id the IPv6 header is RPI1 is changed. Going down, in each 6LR_id the IPv6 header is
swapped with the SRH so both are changed alongside with the RPI2. swapped with the RH3 so both are changed alongside with the RPI2.
+---------+-------+----------+------------+----------+------------+ +---------+-------+----------+------------+----------+------------+
| 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 | -- | | Modified| -- | | -- | IP6-IP6 | -- |
skipping to change at page 48, line 43 skipping to change at page 48, line 43
+-----------+------+--------+---------+---------+---------+ +-----------+------+--------+---------+---------+---------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | | Modified | -- | RPI1 | -- | IP6-IP6 | -- |
| headers | | | | (RH3, | | | headers | | | | (RH3, | |
| | | | | RPI2) | | | | | | | RPI2) | |
+-----------+------+--------+---------+---------+---------+ +-----------+------+--------+---------+---------+---------+
| Removed | -- | -- | -- | -- | IP6-IP6 | | Removed | -- | -- | -- | -- | IP6-IP6 |
| headers | | | | | (RH3, | | headers | | | | | (RH3, |
| | | | | | RPI2) | | | | | | | RPI2) |
| | | | | | | | | | | | | |
+-----------+------+--------+---------+---------+---------+ +-----------+------+--------+---------+---------+---------+
| Untouched | -- | -- | RPI1 | RPI1 | RPI | | Untouched | -- | -- | RPI1 | RPI1 | RPI1 |
| headers | | | | |(Ignored)| | headers | | | | |(Ignored)|
+-----------+------+--------+---------+---------+---------+ +-----------+------+--------+---------+---------+---------+
Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL
without encapsulation to the root. 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:
skipping to change at page 53, line 38 skipping to change at page 53, line 38
The above case occurs whenever traffic originates from the outside The above case occurs whenever traffic originates from the outside
the LLN (the "Internet" cases above), and non-storing mode is used. the LLN (the "Internet" cases above), and non-storing mode is used.
In non-storing mode, the RPL root knows the exact topology (as it In non-storing mode, the RPL root knows the exact topology (as it
must create the RH3 header) and therefore knows which 6LR is prior to must create the RH3 header) and therefore knows which 6LR is prior to
the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf
Node G, or Node C is the 6LR prior to leaf Node J. Node G, or Node C is the 6LR prior to leaf Node J.
traffic originating from the RPL root (such as when the data traffic originating from the RPL root (such as when the data
collection system is co-located on the RPL root), does not require an collection system is co-located on the RPL root), does not require an
IPv6-in-IPv6 header (in either mode), as the packet is originating at IPv6-in-IPv6 header (in storing or non-storing mode), as the packet
the root, and the root can insert the RPI and RH3 headers directly is originating at the root, and the root can insert the RPI and RH3
into the packet, as it is formed. Such a packet is slightly smaller, headers directly into the packet, as it is formed. Such a packet is
but only can be sent to nodes (whether RPL aware or not), that will slightly smaller, but only can be sent to nodes (whether RPL aware or
tolerate the RPL artifacts. not), that will tolerate the RPL artifacts.
An operator that finds itself with a lot of traffic from the RPL root An operator that finds itself with a high amount of traffic from the
to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6
if the leaf is not tolerant of the RPL artifacts. Such an operator encapsulation if the leaf is not tolerant of the RPL artifacts. Such
could otherwise omit this unnecessary header if it was certain of the an operator could otherwise omit this unnecessary header if it was
properties of the leaf. certain of the properties of the leaf.
As storing mode can not know the final path of the traffic, As storing mode can not know the final path of the traffic,
intolerant (that drop packets with RPL artifacts) leaf nodes can not intolerant (that drop packets with RPL artifacts) leaf nodes can not
be supported. be supported.
10. Operational considerations of introducing 0x23 10. Operational considerations of introducing 0x23
This section describes the operational considerations of introducing This section describes the operational considerations of introducing
the new RPI Option Type of 0x23. the new RPI Option Type of 0x23.
skipping to change at page 54, line 33 skipping to change at page 54, line 33
DODAG Configuration option has been seen by all nodes. DODAG Configuration option has been seen by all nodes.
Before the migration happens, all the RPL-aware nodes should support Before the migration happens, all the RPL-aware nodes should support
both values . The migration procedure it is triggered when the DIO both values . The migration procedure it is triggered when the DIO
is sent with the flag indicating the new RPI Option Type. Namely, it is sent with the flag indicating the new RPI Option Type. Namely, it
remains at 0x63 until it is sure that the network is capable of 0x23, remains at 0x63 until it is sure that the network is capable of 0x23,
then it abruptly change to 0x23. This options allows to send packets then it abruptly change to 0x23. This options allows to send packets
to not-RPL nodes, which should ignore the option and continue to not-RPL nodes, which should ignore the option and continue
processing the packets. processing the packets.
In case that a node join to a network that only process 0x63, it As mentioned previously, indicating the new RPI in the DODAG
would produce a flag day as was mentioned previously. Indicating the Configuration option flag is a way to avoid the flag day (lack of
new RPI in the DODAG Configuration option Flag is a way to avoid the interoperation) in a network using 0x63 as the RPI Option Type value.
flag day in a network. It is recommended that a network process both It is suggested that RPL implementations accept both 0x63 and 0x23
options to enable interoperability. RPI Option type values when processing the header 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 38. Figure 38.
+-------+-------------------+------------------------+---------- -+ +-------+-------------------+------------------------+---------- -+
| Hex | Binary Value | Description | Reference | | Hex | Binary Value | Description | Reference |
+ Value +-------------------+ + + + Value +-------------------+ + +
skipping to change at page 60, line 50 skipping to change at page 60, line 50
[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-20 (work in Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in
progress), March 2020. progress), April 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-19 (work Backbone Router", draft-ietf-6lo-backbone-router-20 (work
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-24 (work in progress), March 2020. plane-24 (work in progress), March 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-38 (work in progress), March 2020. keyinfra-41 (work in progress), April 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-13 (work in progress), draft-ietf-roll-unaware-leaves-15 (work in progress),
March 2020. April 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
 End of changes. 57 change blocks. 
106 lines changed or deleted 109 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/