< draft-ietf-roll-useofrplinfo-31.txt   draft-ietf-roll-useofrplinfo-32.txt >
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Aalto Internet-Draft Aalto/UTN-FRM
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: January 5, 2020 P. Thubert Expires: May 7, 2020 P. Thubert
Cisco Cisco
July 4, 2019 November 4, 2019
Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 Using RPL 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-31 draft-ietf-roll-useofrplinfo-32
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 (RPL Option Type), RFC6554 enumerates the cases where RFC6553 (RPL 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 January 5, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Requirements Language . . . . . . . . . . . . 4 2. Terminology and Requirements Language . . . . . . . . . . . . 4
3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7
4.1. Updates to RFC6553: Indicating the new RPI value. . . . . 7 4.1. Updates to RFC6550: Advertise External Routes with Non-
4.2. Updates to RFC6550: Indicating the new RPI in the Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7
DODAG Configuration Option Flag. . . . . . . . . . . . . 10 4.2. Updates to RFC6553: Indicating the new RPI value. . . . . 8
4.3. Updates to RFC8138: Indicating the way to decompress with 4.3. Updates to RFC6550: Indicating the new RPI in the
the new RPI value. . . . . . . . . . . . . . . . . . . . 11 DODAG Configuration Option Flag. . . . . . . . . . . . . 11
5. Sample/reference topology . . . . . . . . . . . . . . . . . . 12 4.4. Updates to RFC8138: Indicating the way to decompress with
6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 the new RPI value. . . . . . . . . . . . . . . . . . . . 12
7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14
7.1. Storing Mode: Interaction between Leaf and Root . . . . . 18 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.1. SM: Example of Flow from RAL to root . . . . . . . . 18 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. SM: Example of Flow from root to RAL . . . . . . . . 19 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20
7.1.3. SM: Example of Flow from root to RUL . . . . . . . . 20 7.1.1. SM: Example of Flow from RAL to root . . . . . . . . 21
7.1.4. SM: Example of Flow from RUL to root . . . . . . . . 20 7.1.2. SM: Example of Flow from root to RAL . . . . . . . . 21
7.2. SM: Interaction between Leaf and Internet. . . . . . . . 21 7.1.3. SM: Example of Flow from root to RUL . . . . . . . . 22
7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 22 7.1.4. SM: Example of Flow from RUL to root . . . . . . . . 23
7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 22 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 23
7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 23 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 24
7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 24 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 24
7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 25 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 25
7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 25 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 26
7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 27 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 27
7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 27 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 28
7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 29 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 29
8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 30 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 30
8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 31 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 31
8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 32 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 32 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 33
8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 33 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 34
8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 34 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 34
8.2. Non-Storing Mode: Interaction between Leaf and Internet . 35 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 35
8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 35 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 36
8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 36 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 37
8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 37 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 37
8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 38 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 38
8.3. Non-SM: Interaction between Leafs . . . . . . . . . . . . 39 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 39
8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 39 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 40
8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 41 8.3. Non-SM: Interaction between Leafs . . . . . . . . . . . . 41
8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 42 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 41
8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 43 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 43
8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 44
8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 45
9. Operational Considerations of supporting 9. Operational Considerations of supporting
not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 44 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 46
10. Operational considerations of introducing 0x23 . . . . . . . 45 10. Operational considerations of introducing 0x23 . . . . . . . 47
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 12. Security Considerations . . . . . . . . . . . . . . . . . . . 49
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . 50 14.1. Normative References . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . 51 14.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
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
[RFC6553] defines the "RPL option" (RPL Packet Information or RPI), [RFC6553] defines the "RPL option" (RPL Packet Information or RPI),
carried within the IPv6 Hop-by-Hop header to quickly identify carried within the IPv6 Hop-by-Hop header to quickly identify
inconsistencies (loops) in the routing topology. RFC6554 [RFC6554] inconsistencies (loops) in the routing topology. RFC6554 [RFC6554]
defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header
to deliver datagrams within a RPL routing domain, particularly in to deliver datagrams within a RPL routing domain, particularly in
skipping to change at page 4, line 34 skipping to change at page 4, line 37
tunnels to existing protocol layers and the challenges in supporting tunnels to existing protocol layers and the challenges in supporting
IP tunneling. IP tunneling.
Non-constrained uses of RPL are not in scope of this document, and Non-constrained uses of RPL are not in scope of this document, and
applicability statements for those uses may provide different advice, applicability statements for those uses may provide different advice,
E.g. [I-D.ietf-anima-autonomic-control-plane]. E.g. [I-D.ietf-anima-autonomic-control-plane].
1.1. Overview 1.1. Overview
The rest of the document is organized as follows: Section 2 describes The rest of the document is organized as follows: Section 2 describes
the used terminology. Section 3 describes the updates to RFC6553, the used terminology. Section 3 provides a RPL Overview. Section 4
RFC6550 and RFC 8138. Section 4 provides the reference topology used describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5
for the uses cases. Section 5 describes the uses cases included. provides the reference topology used for the uses cases. Section 6
Section 6 describes the storing mode cases and section 7 the non- describes the uses cases included. Section 7 describes the storing
storing mode cases. Section 8 describes the operational mode cases and section 8 the non-storing mode cases. Section 9
considerations of supporting not-RPL-aware-leaves. Section 9 depicts describes the operational considerations of supporting RPL-unaware-
operational considerations for the proposed change on RPL Option leaves. Section 10 depicts operational considerations for the
type, section 10 the IANA considerations and then section 11 proposed change on RPL Option type, section 11 the IANA
describes the security aspects. considerations and then section 12 describes the security aspects.
2. Terminology and Requirements Language 2. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Terminology defined in [RFC7102] applies to this document: LLN, RPL, Terminology defined in [RFC7102] applies to this document: LLN, RPL,
RPL Domain and ROLL. RPL Domain and ROLL.
RPL-aware-node: A device which implements RPL. Please note that the RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
device can be found inside the LLN or outside LLN. connectivity through a RPL Destination Oriented Directed Acyclic
Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a
consumed Routing Header and as an IPv6 host, it is expected to ignore
a Hop-by-Hop header. It results that a RPL Leaf can correctly
receive a packet with RPL artifacts. On the other hand, a RPL Leaf
is not expected to generate RPL artifacts or to support IP-in-IP
encapsulation. For simplification, this document uses the standalone
term leaf to mean a RPL leaf.
RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a RPL-aware-node (RAN): A device which implements RPL. Please note
(Destination Oriented Directed Acyclic Graph) DODAG. that the device can be found inside the LLN or outside LLN.
RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf.
RPL-unaware-node: A device which does not implement RPL, thus the RPL-unaware-node: A device which does not implement RPL, thus the
device is not-RPL-aware. Please note that the device can be found device is not-RPL-aware. Please note that the device can be found
inside the LLN. inside the LLN.
RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.
(Destination Oriented Directed Acyclic Graph) DODAG.
6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any
host or router participating in a LoWPAN. This term is used when host or router participating in a LoWPAN. This term is used when
referring to situations in which either a host or router can play the referring to situations in which either a host or router can play the
role described.". In this document, a 6LN acts as a leaf. role described.". In this document, a 6LN acts as a leaf.
6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate
router in the LoWPAN that is able to send and receive Router router in the LoWPAN that is able to send and receive Router
Advertisements (RAs) and Router Solicitations (RSs) as well as Advertisements (RAs) and Router Solicitations (RSs) as well as
forward and route IPv6 packets. 6LoWPAN routers are present only in forward and route IPv6 packets. 6LoWPAN routers are present only in
skipping to change at page 5, line 39 skipping to change at page 6, line 4
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: A transition that involves having a network with different
values of RPL Option Type. Thus the network does not work correctly values of RPL Option Type. Thus the network does not work correctly
(Lack of interoperation). (Lack of interoperation).
Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation" Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation"
header refers to adding a header that originates from a node to an header refers to adding a header that originates from a node to an
adjacent node, using the addresses (usually the GUA or ULA, but could adjacent node, using the addresses (usually the GUA or ULA, but could
use the link-local addresses) of each node. If the packet must use the link-local addresses) of each node. If the packet must
traverse multiple hops, then it must be decapsulated at each hop, and traverse multiple hops, then it must be decapsulated at each hop, and
then re-encapsulated again in a similar fashion. then re-encapsulated again in a similar fashion.
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 its parents. Thus, aware-nodes send information to the root about its parents. Thus,
the root know the topology, then the intermediate 6LRs do not the root know the topology, then the intermediate 6LRs do not
maintain routing state so that source routing is needed. maintain routing state so that source 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.
Due to lack of space in some figures (tables) we refers IPv6-in-IPv6 Note: Due to lack of space in some figures (tables) we refers IPv6-
as IP6-IP6. in-IPv6 as IP6-IP6.
3. RPL Overview 3. RPL Overview
RPL defines the RPL Control messages (control plane), a new ICMPv6 RPL defines the RPL Control messages (control plane), a new ICMPv6
[RFC4443] message with Type 155. DIS (DODAG Information [RFC4443] message with Type 155. DIS (DODAG Information
Solicitation), DIO (DODAG Information Object) and DAO (Destination Solicitation), DIO (DODAG Information Object) and DAO (Destination
Advertisement Object) messages are all RPL Control messages but with Advertisement Object) messages are all RPL Control messages but with
different Code values. A RPL Stack is shown in Figure 1. different Code values. A RPL Stack is shown in Figure 1.
+--------------+ +--------------+
skipping to change at page 7, line 7 skipping to change at page 7, line 36
RPL supports two modes of Downward traffic: in storing mode (SM), it RPL supports two modes of Downward traffic: in storing mode (SM), it
is fully stateful; in non-storing mode (Non-SM), it is fully source is fully stateful; in non-storing mode (Non-SM), it is fully source
routed. A RPL Instance is either fully storing or fully non-storing, routed. A RPL Instance is either fully storing or fully non-storing,
i.e. a RPL Instance with a combination of storing and non-storing i.e. a RPL Instance with a combination of storing and non-storing
nodes is not supported with the current specifications at the time of nodes is not supported with the current specifications at the time of
writing this document. writing this document.
4. Updates to RFC6553, RFC6550 and RFC8138 4. Updates to RFC6553, RFC6550 and RFC8138
4.1. Updates to RFC6553: Indicating the new RPI value. 4.1. Updates to RFC6550: Advertise External Routes with Non-Storing
Mode Signaling.
Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to
indicate that the 6LR that generates the DAO redistributes external
targets into the RPL network. An external Target is a Target that
has been learned through an alternate protocol, for instance a route
to a prefix that is outside the RPL domain but reachable via a 6LR.
Being outside of the RPL domain, a node that is reached via an
external target cannot be guaranteed to ignore the RPL artifacts and
cannot be expected to process the [RFC8138] compression correctly.
This means that the RPL artifacts should be contained in an IP-in-IP
encapsulation that is removed by the 6LR, and that any remaining
compression should be expanded by the 6LR before it forwards a packet
outside the RPL domain.
This specification updates [RFC6550] to RECOMMEND that external
targets are advertised using Non-Storing Mode DAO messaging even in a
Storing-Mode network. This way, external routes are not advertised
within the DODAG and all packets to an external target reach the Root
like normal Non-Storing Mode traffic. The Non-Storing Mode DAO
informs the Root of the address of the 6LR that injects the external
route, and the root uses IP-in-IP encapsulation to that 6LR, which
terminates the IP-in-IP tunnel and forwards the original packet
outside the RPL domain free of RPL artifacts. This whole operation
is transparent to intermediate routers 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 upgraded to add this
function to the network.
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
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
registered to the 6LR using [RFC8505]. IP-in-IP encapsulation MAY be
avoided for Root to RUL communication if the RUL is known to process
the packets as forwarded by the parent 6LR without decapsulation.
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
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
that the RUL supports IP-in-IP decapsulation.
A node that is reachable over an external route is not expected to
support [RFC8138]. Whether a decapsulation took place or not and
even when the 6LR is delivering the packet to a RUL, the 6LR that
injected an external route MUST uncompress the packet before
forwarding over that external route.
4.2. Updates to RFC6553: Indicating the new RPI value.
This modification is required to be able to send, for example, IPv6 This modification is required to be able to send, for example, IPv6
packets from a RPL-Aware-Leaf to a not-RPL-aware node through packets from a RPL-Aware-Leaf to a RPL-unaware node through Internet
Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 (see Section 7.2.1), without requiring IPv6-in-IPv6 encapsulation.
encapsulation.
[RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in
the Option Type field of the RPL Option header, the two high order the Option Type field of the RPL Option header, the two high order
bits must be set to '01' and the third bit is equal to '1'. The bits must be set to '01' and the third bit is equal to '1'. The
first two bits indicate that the IPv6 node must discard the packet if first two bits indicate that the IPv6 node must discard the packet if
it doesn't recognize the option type, and the third bit indicates it doesn't recognize the option type, and the third bit indicates
that the Option Data may change in route. The remaining bits serve that the Option Data may change in route. The remaining bits serve
as the option type. as the option type.
+-------+-------------------+----------------+-----------+ +-------+-------------------+----------------+-----------+
skipping to change at page 10, line 15 skipping to change at page 11, line 41
The 6LBR can recognize not-RPL aware leaf nodes because it will The 6LBR can recognize not-RPL aware leaf nodes because it will
receive a DAO about that node from the 6LR immediately above that receive a DAO about that node from the 6LR immediately above that
not-RPL aware node. This means that the non-storing mode case can not-RPL aware node. This means that the non-storing mode case can
avoid ever using hop-by-hop re-encapsulation headers for traffic avoid ever using hop-by-hop re-encapsulation headers for traffic
originating from the root to the leafs. originating from the root to the leafs.
The non-storing mode case does not require the type change from 0x63 The non-storing mode case does not require the type change from 0x63
to 0x23, as the root can always create the right packet. The type to 0x23, as the root can always create the right packet. The type
change does not adversely affect the non-storing case. change does not adversely affect the non-storing case.
4.2. Updates to RFC6550: Indicating the new RPI in the DODAG 4.3. Updates to RFC6550: Indicating the new RPI in the DODAG
Configuration Option Flag. Configuration Option Flag.
In order to avoid a Flag Day caused by lack of interoperation between In order to avoid a Flag Day caused by lack of interoperation between
new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag
in the DIO Configuration Option, to indicate when then new RPI value in the DIO Configuration Option, to indicate when then new RPI value
can be safely used. This means, the flag is going to indicate the can be safely used. This means, the flag is going to indicate the
type of RPI that the network is using. Thus, when a node join to a type of RPI that the network is using. Thus, when a node join to a
network will know which value to use. With this, RPL-capable nodes network will know which value to use. With this, RPL-capable nodes
know if it is safe to use 0x23 when creating a new RPI. A node that know if it is safe to use 0x23 when creating a new RPI. A node that
forwards a packet with an RPI MUST NOT modify the option type of the forwards a packet with an RPI MUST NOT modify the option type of the
skipping to change at page 11, line 20 skipping to change at page 12, line 41
Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag-
day. day.
In case of rebooting, the node (6LN or 6LR) does not remember the RPL In case of rebooting, the node (6LN or 6LR) does not remember the RPL
Option Type, that is if the flag is set, so DIO messages sent by the Option Type, that is if the flag is set, so DIO messages sent by the
node would be set with the flag unset until a DIO message is received node would be set with the flag unset until a DIO message is received
with the flag set indicating the new RPI value. The node sets to with the flag set indicating the new RPI value. The node sets to
0x23 if the node supports this feature. 0x23 if the node supports this feature.
4.3. Updates to RFC8138: Indicating the way to decompress with the new 4.4. Updates to RFC8138: Indicating the way to decompress with the new
RPI value. RPI value.
This modification is required to be able to decompress the RPL RPI This modification is required to be able to decompress the RPL RPI
option with the new value (0x23). option with the new value (0x23).
RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138]
in section 6. A node that is decompressing this header MUST in section 6. A node that is decompressing this header MUST
decompress using the RPL RPI option type that is currently active: decompress using the RPL RPI option type that is currently active:
that is, a choice between 0x23 (new) and 0x63 (old). The node will that is, a choice between 0x23 (new) and 0x63 (old). The node will
know which to use based upon the presence of the flag in the DODAG know which to use based upon the presence of the flag in the DODAG
Configuration Option defined in Section 4.2. E.g. If the network is Configuration Option defined in Section 4.3. E.g. If the network is
in 0x23 mode (by DIO option), then it should be decompressed to 0x23. in 0x23 mode (by DIO option), then it should be decompressed to 0x23.
[RFC8138] section 7 documents how to compress the IPv6-in-IPv6 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6
header. header.
There are potential significant advantages to having a single code There are potential significant advantages to having a single code
path that always processes IPv6-in-IPv6 headers with no conditional path that always processes IPv6-in-IPv6 headers with no conditional
branches. branches.
In Storing Mode, for the examples of Flow from RAL to RUL and RUL to In Storing Mode, for the examples of Flow from RAL to RUL and RUL to
RUL comprise an IPv6-in-IPv6 and RPI compression headers. The use of RUL comprise an IPv6-in-IPv6 and RPI compression headers. The use of
the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be
compressed with [RFC8138] section 7. Figure 5 illustrates the case compressed with [RFC8138] section 7. Figure 5 illustrates the case
in Storing mode where the packet is received from the Internet, then in Storing mode where the packet is received from the Internet, then
the root encapsulates the packet to insert the RPI. In that example, the root encapsulates the packet to insert the RPI. In that example,
the leaf is not known to support RFC 8138, and the packet is the leaf is not known to support RFC 8138, and the packet is
encapsulated to the 6LR that is the parent and last hop to the final encapsulated to the 6LR that is the parent and last hop to the final
destination. destination.
+-+ ... -+-+ ... +-+- ... -+-+- .... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-...
|11110001|SRH-6LoRH| RPI- |IPv6-in-IPv6| NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-- ...+-+-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-...
<-4bytes-> <- RFC 6282 -> <-4bytes-> <- RFC 6282 ->
No RPL artifact No RPL artifact
Figure 5: RPI Inserted by the Root in Storing Mode Figure 5: RPI Inserted by the Root in Storing Mode
In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the
Root, so it is elided in the IPv6-in-IPv6 6LoRH. The destination is Root, so it is elided in the IP-in-IP 6LoRH. The destination is the
the parent 6LR of the destination of the inner packet so it cannot be parent 6LR of the destination of the inner packet so it cannot be
elided. It is placed as the single entry in an SRH-6LoRH as the elided. It is placed as the single entry in an SRH-6LoRH as the
first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In
that example, the type is 1 so the 6LR address is compressed to 2 that example, the type is 1 so the 6LR address is compressed to 2
bytes. It results that the total length of the SRH-6LoRH is 4 bytes. bytes. It results that the total length of the SRH-6LoRH is 4 bytes.
Follows the RPI-6LoRH and then the IPv6-in-IPv6 6LoRH. When the Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP
IPv6-in-IPv6 6LoRH is removed, all the router headers that precede it 6LoRH is removed, all the router headers that precede it are also
are also removed. The Paging Dispatch [RFC8025] may also be removed removed. The Paging Dispatch [RFC8025] may also be removed if there
if there was no previous Page change to a Page other than 0 or 1, was no previous Page change to a Page other than 0 or 1, since the
since the LOWPAN_IPHC is encoded in the same fashion in the default LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and
Page 0 and in Page 1. The resulting packet to the destination is the in Page 1. The resulting packet to the destination is the inner
inner packet compressed with [RFC6282]. packet compressed with [RFC6282].
5. Sample/reference topology 5. Sample/reference topology
A RPL network in general is composed of a 6LBR, Backbone Router A RPL network in general is composed of a 6LBR, Backbone Router
(6BBR), 6LR and 6LN as leaf logically organized in a DODAG structure. (6BBR), 6LR and 6LN as leaf logically organized in a DODAG structure.
Figure 6 shows the reference RPL Topology for this document. The Figure 6 shows the reference RPL Topology for this document. The
letters above the nodes are there so that they may be referenced in letters above the nodes are there so that they may be referenced in
subsequent sections. In the figure, 6LR represents a full router subsequent sections. In the figure, 6LR represents a full router
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, thus the 6BBR is not present in 6LBR has direct access to Internet and is the root of the DODAG, thus
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 leafs marked as RUL (G and J) are devices which do not speak RPL The leafs 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 efficient-ND only to participate in the network [RFC6775].
In the document these leafs (G and J) are also referred to as an IPv6 In the document these leafs (G and J) are also referred to as an IPv6
node. node.
skipping to change at page 14, line 44 skipping to change at page 16, line 44
RAL to Internet RAL to Internet
Internet to RAL Internet to RAL
RUL to Internet RUL to Internet
Internet to RUL Internet to RUL
Interaction between Leafs: Interaction between Leafs:
RAL to RAL (storing and non-storing) RAL to RAL
RAL to RUL (non-storing) RAL to RUL
RUL to RAL (storing and non-storing) RUL to RAL
RUL to RUL (non-storing) RUL to RUL
This document is consistent with the rule that a Header cannot be This document is consistent with the rule that a Header cannot be
inserted or removed on the fly inside an IPv6 packet that is being inserted or removed on the fly inside an IPv6 packet that is being
routed. This is a fundamental precept of the IPv6 architecture as routed. This is a fundamental precept of the IPv6 architecture as
outlined in [RFC8200]. outlined in [RFC8200].
As the rank information in the RPI artifact is changed at each hop, As the rank information in the RPI artifact is changed at each hop,
it will typically be zero when it arrives at the DODAG root. The it will typically be zero when it arrives at the DODAG root. The
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
skipping to change at page 16, line 5 skipping to change at page 18, line 5
of the pressure to optimize this any further of the pressure to optimize this any further
[I-D.ietf-anima-autonomic-control-plane]. [I-D.ietf-anima-autonomic-control-plane].
The earlier examples are more extensive to make sure that the process The earlier examples are more extensive to make sure that the process
is clear, while later examples are more concise. is clear, while later examples are more concise.
The uses cases are delineated based on the following requirements: The uses cases are delineated based on the following requirements:
The RPI option has to be in every packet that traverses the LLN. The RPI option has to be in every packet that traverses the LLN.
- Because of (1), packets from the Internet have to be - Because of the previous requirement, packets from the Internet
encapsulated. have 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
sender or the receiver. sender or the receiver.
- RPI and RH3 headers may be modified by routers on the path of - RPI and RH3 headers may be modified by routers on the path of
the packet without the need to add and remove an encapsulating the packet without the need to add and remove an encapsulating
header. header.
skipping to change at page 16, line 30 skipping to change at page 18, line 30
addressed to the intermediate router. addressed to the intermediate router.
- Non-storing mode requires downstream encapsulation by root for - Non-storing mode requires downstream encapsulation by root for
RH3. RH3.
The uses cases are delineated based on the following assumptions: The uses cases are delineated based on the following assumptions:
This document assumes that the LLN is using the no-drop RPI option This document assumes that the LLN is using the no-drop RPI option
(0x23). (0x23).
- Each IPv6 node (including Internet routers) obeys [RFC8200] - Each IPv6 node (including Internet routers) obeys [RFC8200] RFC
8200, so that 0x23 RPI can be safely inserted. 8200, so that 0x23 RPI can be safely inserted.
- All 6LRs obey [RFC8200]. - All 6LRs obey RFC 8200 [RFC8200].
- The RPI is ignored at the IPv6 dst node (RPL-unaware-leaf). - The RPI is ignored at the IPv6 dst node (RUL).
- The leaf can be a router 6LR or a host, both indicated as 6LN. - In the uses cases, we assume that the RAL supports IP-in-IP
encapsulation.
- In the uses cases, we dont assume that the RUL supports IP-in-IP
encapsulation.
- Non-constrained uses of RPL are not in scope of this document. - Non-constrained uses of RPL are not in scope of this document.
- Compression is based on [RFC8138]. - Compression is based on [RFC8138].
- The flow label [RFC6437] is not needed in RPL. - The flow label [RFC6437] is not needed in RPL.
7. Storing mode 7. Storing mode
In storing mode (SM) (fully stateful), the sender can determine if In storing mode (SM) (fully stateful), the sender can determine if
skipping to change at page 18, line 14 skipping to change at page 20, line 14
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+------------------+
| 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 | hop or 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 | hop or root |
+ +--------------+------------+------------------+ + +--------------+------------+------------------+
| | Int to RUL | must | hop | | | 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 | RAL (tgt) | | | RUL to RAL | must | RAL (tgt) |
+ +--------------+------------+------------------+ + +--------------+------------+------------------+
| | RUL to RUL | must | hop | | | RUL to RUL | must | 6LR |
+---------------------+--------------+------------+------------------+ +---------------------+--------------+------------+------------------+
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 19, line 12 skipping to change at page 21, line 17
In storing mode, RFC 6553 (RPI) is used to send RPL Information In storing mode, RFC 6553 (RPI) is used to send RPL Information
instanceID and rank information. instanceID and rank information.
In this case the flow comprises: In this case the flow comprises:
RAL (6LN) --> 6LR_i --> root(6LBR) RAL (6LN) --> 6LR_i --> root(6LBR)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> Node D -->
Node B --> Node A root(6LBR) Node B --> Node A root(6LBR)
The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR The RAL (Node F) inserts the RPI header, and sends the packet to 6LR
(Node E) which decrements the rank in RPI and sends the packet up. (Node D) which decrements the rank in RPI and sends the packet up.
When the packet arrives at 6LBR (Node A), the RPI is removed and the When the packet arrives at 6LBR (Node A), the RPI is removed and the
packet is processed. packet is processed.
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
The RPI header can be removed by the 6LBR because the packet is The RPI header can be removed by the 6LBR because the packet is
addressed to the 6LBR. The 6LN must know that it is communicating addressed to the 6LBR. The RAL must know that it is communicating
with the 6LBR to make use of this scenario. The 6LN can know the with the 6LBR to make use of this scenario. The RAL can know the
address of the 6LBR because it knows the address of the root via the address of the 6LBR because it knows the address of the root via the
DODAGID in the DIO messages. DODAGID in the DIO messages.
The Table 1 summarizes what headers are needed for this use case. The Table 1 summarizes what headers are needed for this use case.
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
| Header | 6LN src | 6LR_i | 6LBR dst | | Header | RAL src | 6LR_i | 6LBR dst |
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI | | Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
Table 1: SM: Summary of the use of headers from RAL to root Table 1: SM: Summary of the use of headers from RAL to root
skipping to change at page 19, line 47 skipping to change at page 22, line 4
Table 1: SM: Summary of the use of headers from RAL to root Table 1: SM: Summary of the use of headers from RAL to root
7.1.2. SM: Example of Flow from root to RAL 7.1.2. 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)
For example, a communication flow could be: Node A root(6LBR) --> For example, a communication flow could be: Node A root(6LBR) -->
Node B --> Node D --> Node F Node B --> Node D --> Node F
In this case the 6LBR inserts RPI header and sends the packet down, In this case the 6LBR inserts RPI header and sends the packet down,
the 6LR is going to increment the rank in RPI (it examines the the 6LR is going to increment the rank in RPI (it examines the
instanceID to identify the right forwarding table), the packet is instanceID to identify the right forwarding table), the packet is
processed in the 6LN and the RPI removed. processed in the RAL and the RPI removed.
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
The Table 2 summarizes what headers are needed for this use case. The Table 2 summarizes what headers are needed for this use case.
+-------------------+------+-------+------+ +-------------------+----------+-------+---------+
| Header | 6LBR | 6LR_i | 6LN | | Header | 6LBR src | 6LR_i | RAL dst |
+-------------------+------+-------+------+ +-------------------+----------+-------+---------+
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI | | Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+------+-------+------+ +-------------------+----------+-------+---------+
Table 2: SM: Summary of the use of headers from root to RAL Table 2: SM: Summary of the use of headers from root to RAL
7.1.3. SM: Example of Flow from root to RUL 7.1.3. 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) root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
For example, a communication flow could be: Node A root(6LBR) --> For example, a communication flow could be: Node A root(6LBR) -->
Node B --> Node E --> Node G Node B --> Node E --> Node G
As the RPI extension can be ignored by the not-RPL-aware leaf, this As the RPI extension can be ignored by the RUL, this situation is
situation is identical to the previous scenario. identical to the previous scenario.
The Table 3 summarizes what headers are needed for this use case. The Table 3 summarizes what headers are needed for this use case.
+-------------------+----------+-------+----------------+ +-------------------+----------+-------+----------------------+
| Header | 6LBR src | 6LR_i | IPv6 dst node | | Header | 6LBR src | 6LR_i | RUL (IPv6 dst node) |
+-------------------+----------+-------+----------------+ +-------------------+----------+-------+----------------------+
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | -- | | Removed headers | -- | -- | -- |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | RPI (Ignored) | | Untouched headers | -- | -- | RPI (Ignored) |
+-------------------+----------+-------+----------------+ +-------------------+----------+-------+----------------------+
Table 3: SM: Summary of the use of headers from root to RUL Table 3: SM: Summary of the use of headers from root to RUL
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) --> 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 --> Node E --> For example, a communication flow could be: Node G --> Node E -->
Node B --> Node A root(6LBR) Node B --> 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 header, encapsulated in a IPv6-in-IPv6 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6
header. The IPv6-in-IPv6 header can be addressed to the next hop header. The IPv6-in-IPv6 header can be addressed to the next hop
(Node B), or to the root (Node A). The root removes the header and (Node B), or to the root (Node A). The root removes the header and
processes the packet. 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. [1] refers the case where the IPv6-in-IPv6 header for this use case. [1] refers the case where the IPv6-in-IPv6 header
is addressed to the next hop (Node B). [2] refers the case where the is addressed to the next hop (Node B). [2] refers the case where the
IPv6-in-IPv6 header is addressed to the root (Node A). IPv6-in-IPv6 header is addressed to the root (Node A).
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+-----------------+------------------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst |
| | src | | | | | | src | | | |
| | node | | | | | | node | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+-----------------+------------------+
| Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+-----------------+------------------+
| Removed | -- | -- | -- |IP6-IP6(RPI)[1][2]| | Removed | -- | -- | IP6-IP6(RPI)[1] |IP6-IP6(RPI)[1][2]|
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+-----------------+------------------+
| Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+------------------+ +-----------+------+--------------+-----------------+------------------+
| Modified | -- | -- | IP6-IP6(RPI)[2] | -- | | Modified | -- | -- | IP6-IP6(RPI)[2] | -- |
| 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.
skipping to change at page 22, line 26 skipping to change at page 24, line 32
Node B --> Node A root(6LBR) --> Internet Node B --> Node A root(6LBR) --> Internet
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
Note: In this use case it is used a node as leaf, but this use case Note: In this use case it is used a node as leaf, but this use case
can be also applicable to any RPL-aware-node type (e.g. 6LR) can be also applicable to any RPL-aware-node type (e.g. 6LR)
The Table 4 summarizes what headers are needed for this use case. The Table 4 summarizes what headers are needed for this use case.
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
| Header | 6LN src | 6LR_i | 6LBR | Internet dst | | Header | RAL src | 6LR_i | 6LBR | Internet dst |
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
| Inserted headers | RPI | -- | -- | -- | | Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
| Untouched headers | -- | -- | RPI | RPI (Ignored) | | Untouched headers | -- | -- | RPI | RPI (Ignored) |
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
Table 4: SM: Summary of the use of headers from RAL to Internet Table 4: SM: Summary of the use of headers from RAL to Internet
skipping to change at page 22, line 45 skipping to change at page 25, line 4
Table 4: SM: Summary of the use of headers from RAL to Internet Table 4: SM: Summary of the use of headers from RAL to Internet
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:
Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) Internet --> root (6LBR) --> 6LR_i --> RAL (6LN)
For example, a communication flow could be: Internet --> Node A For example, a communication flow could be: Internet --> Node A
root(6LBR) --> Node B --> Node D --> Node F root(6LBR) --> Node B --> Node D --> Node F
When the packet arrives from Internet to 6LBR the RPI header is added When the packet arrives from Internet to 6LBR the RPI header is added
in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination
address set to the 6LR) and sent to 6LR, which modifies the rank in address set to the RAL) and sent to 6LR, which modifies the rank in
the RPI. When the packet arrives at 6LN the RPI header is removed the RPI. When the packet arrives at the RAL the RPI header is
and the packet processed. removed and the packet processed.
The Figure 9 shows the table that summarizes what headers are needed The Figure 9 shows the table that summarizes what headers are needed
for this use case. for this use case.
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Header | Internet | 6LBR | 6LR_i | 6LN dst | | Header | Internet | 6LBR | 6LR_i | RAL dst |
| | src | | | | | | src | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Inserted | -- | IP6-IP6(RPI) | -- | -- | | Inserted | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Removed | -- | -- | -- | IP6-IP6(RPI) | | Removed | -- | -- | -- | IP6-IP6(RPI) |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
skipping to change at page 23, line 34 skipping to change at page 25, line 39
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
Figure 9: SM: Summary of the use of headers from Internet to RAL. Figure 9: SM: Summary of the use of headers from Internet to RAL.
7.2.3. SM: Example of Flow from RUL to Internet 7.2.3. SM: Example of Flow from RUL to Internet
In this case the flow comprises: In this case the flow comprises:
RUL (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet
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(6LBR) --> Internet Node B --> Node A root(6LBR) --> Internet
The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed
either to the root, or hop-by-hop such that the root can remove the either to the root, or hop-by-hop such that the root can remove the
RPI header before passing upwards. The IPv6-in-IPv6 addressed to the RPI header before passing upwards. The IPv6-in-IPv6 addressed to the
root cause less processing overhead. On the other hand, with hop-by- root cause less processing overhead. On the other hand, with hop-by-
hop the intermediate routers can check the routing tables for a hop the intermediate routers can check the routing tables for a
better routing path, thus it could be more efficient and faster. better routing path, thus it could be more efficient and faster.
Implementation should decide which approach to take. Implementation should decide which approach to take.
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. In the table, [1] shows the case when packet is
addressed to the root. [2] shows the case when the packet is
addressed hop-by-hop.
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+--------+
| 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) | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+--------+
| Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- |
| headers | | | [2] | | | | headers | | | [2] | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+--------+
| Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- |
| headers | | | [2] | [1][2] | | | headers | | | [2] | [1][2] | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+--------+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+--------+
| Modified| -- | -- | IP6-IP6(RPI) | -- | -- | | Modified| -- | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | [1] | | | | headers | | | [1] | | |
+---------+-------+------------+--------------+-------------+--------+ +---------+-------+------------+--------------+-------------+--------+
|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.
[1] Case when packet is addressed to the root. [2] Case when the
packet is addressed hop-by-hop.
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) 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
root(6LBR) --> Node B --> Node E --> Node G root(6LBR) --> Node B --> Node E --> Node G
The 6LBR will have to add an RPI header within an IPv6-in-IPv6 The 6LBR will have to add an RPI header within an IPv6-in-IPv6
header. The IPv6-in-IPv6 is addressed hop-by-hop. header. The IPv6-in-IPv6 is addressed to the 6LR parent of the
6lR_i.
The final node should be able to remove one or more IPv6-in-IPv6 Further details about this are mentioned in
headers which are all addressed to it. The final node does not [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN
process the RPI, the node ignores the RPI. Furhter details about acting as a plain host and not being aware of RPL.
this are mentioned in [I-D.thubert-roll-unaware-leaves], which
specifies RPL routing for a 6LN acting as a plain host and not 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 | Internet | 6LBR | 6LR_i |IPv6 dst node | | Header | Internet | 6LBR | 6LR_i |IPv6 dst node |
| | src | | | | | | src | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Inserted | -- | IP6-IP6(RPI) | -- | -- | | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Removed | -- | -- | | IP6-IP6(RPI)| | Removed | -- | -- | IP6-IP6(RPI) | -- |
| headers | | | | RPI Ignored | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Modified | -- | -- | IP6-IP6(RPI) | -- | | Modified | -- | -- | -- | -- |
| 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
skipping to change at page 26, line 8 skipping to change at page 28, line 15
7.3.1. SM: Example of Flow from RAL to RAL 7.3.1. SM: Example of Flow from RAL to RAL
In [RFC6550] RPL allows a simple one-hop optimization for both In [RFC6550] RPL allows a simple one-hop optimization for both
storing and non-storing networks. A node may send a packet destined storing and non-storing networks. A node may send a packet destined
to a one-hop neighbor directly to that node. See section 9 in to a one-hop neighbor directly to that node. See section 9 in
[RFC6550]. [RFC6550].
When the nodes are not directly connected, then in storing mode, the When the nodes are not directly connected, then in storing mode, the
flow comprises: flow comprises:
6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL
dst (6LN)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> Node D -->
Node B --> Node E --> Node H Node B --> Node E --> Node H
6LR_ia (Node D) are the intermediate routers from source to the 6LR_ia (Node D) are the intermediate routers from source to the
common parent (6LR_x) (Node B) In this case, 1 <= ia <= n, n is the common parent (6LR_x) (Node B). In this case, 1 <= ia <= n, n is the
number of routers (6LR) that the packet goes through from 6LN (Node number of routers (6LR) that the packet goes through from RAL (Node
F) to the common parent (6LR_x). F) to the common parent 6LR_x (Node B).
6LR_id (Node E) are the intermediate routers from the common parent 6LR_id (Node E) are the intermediate routers from the common parent
(6LR_x) (Node B) to destination 6LN (Node H). In this case, 1 <= id (6LR_x) (Node B) to destination RAL (Node H). In this case, 1 <= id
<= m, m is the number of routers (6LR) that the packet goes through <= m, m is the number of routers (6LR) that the packet goes through
from the common parent (6LR_x) to destination 6LN. from the common parent (6LR_x) to destination RAL (Node H).
It is assumed that the two nodes are in the same RPL Domain (that It is assumed that the two nodes are in the same RPL Domain (that
they share the same DODAG root). At the common parent (Node B), the they share the same DODAG root). At the common parent (Node B), the
direction of RPI is changed (from increasing to decreasing the rank). direction of RPI is changed (from decreasing to increasing the rank).
While the 6LR nodes will update the RPI, no node needs to add or While the 6LR nodes will update the RPI, no node needs to add or
remove the RPI, so no IPv6-in-IPv6 headers are necessary. remove the RPI, so no IPv6-in-IPv6 headers are necessary.
The Table 5 summarizes what headers are needed for this use case. The Table 5 summarizes what headers are needed for this use case.
+---------------+--------+--------+---------------+--------+--------+ +---------------+--------+--------+---------------+--------+--------+
| Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | | Header | RAL | 6LR_ia | 6LR_x (common | 6LR_id | RAL |
| | src | | parent) | | dst | | | src | | parent) | | dst |
+---------------+--------+--------+---------------+--------+--------+ +---------------+--------+--------+---------------+--------+--------+
| Inserted | RPI | -- | -- | -- | -- | | Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Removed | -- | -- | -- | -- | RPI | | Removed | -- | -- | -- | -- | RPI |
| headers | | | | | | | headers | | | | | |
| Re-added | -- | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Modified | -- | RPI | RPI | RPI | -- | | Modified | -- | RPI | RPI | RPI | -- |
| headers | | | | | | | headers | | | | | |
| Untouched | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------------+--------+--------+---------------+--------+--------+ +---------------+--------+--------+---------------+--------+--------+
Table 5: SM: Summary of the use of headers for RAL to RAL Table 5: SM: Summary of the use of headers for 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:
6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RUL
6LN (IPv6) (IPv6 dst node)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> Node D -->
Node B --> Node E --> Node G Node B --> Node E --> Node G
6LR_ia are the intermediate routers from source (6LN) to the common 6LR_ia are the intermediate routers from source (RAL) to the common
parent (6LR_x) In this case, 1 <= ia <= n, n is the number of routers parent (6LR_x) In this case, 1 <= ia <= n, n is the number of routers
(6LR) that the packet goes through from 6LN to the common parent (6LR) that the packet goes through from RAL to the common parent
(6LR_x). (6LR_x).
6LR_id (Node E) are the intermediate routers from the common parent 6LR_id (Node E) are the intermediate routers from the common parent
(6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). (6LR_x) (Node B) to destination RUL (Node G). In this case, 1 <= id
In this case, 1 <= id <= m, m is the number of routers (6LR) that the <= m, m is the number of routers (6LR) that the packet goes through
packet goes through from the common parent (6LR_x) to destination from the common parent (6LR_x) to destination RUL.
6LN.
This situation is identical to the previous situation Section 7.3.1 This situation is identical to the previous situation Section 7.3.1
The Table 6 summarizes what headers are needed for this use case. The Table 6 summarizes what headers are needed for this use case.
+-----------+------+--------+---------------+--------+--------------+ +-----------+------+--------+---------------+--------+--------------+
| Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | | Header | RAL | 6LR_ia | 6LR_x(common | 6LR_id | RUL dst |
| | src | | parent) | | node | | | src | | parent) | | |
+-----------+------+--------+---------------+--------+--------------+ +-----------+------+--------+---------------+--------+--------------+
| Inserted | RPI | -- | -- | -- | -- | | Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Removed | -- | -- | -- | -- | -- | | Removed | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Re-added | -- | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Modified | -- | RPI | RPI | RPI | -- | | Modified | -- | RPI | RPI | RPI | -- |
| headers | | | | | | | headers | | | | | |
| Untouched | -- | -- | -- | -- | RPI(Ignored) | | Untouched | -- | -- | -- | -- | RPI(Ignored) |
| headers | | | | | | | headers | | | | | |
+-----------+------+--------+---------------+--------+--------------+ +-----------+------+--------+---------------+--------+--------------+
Table 6: SM: Summary of the use of headers for RAL to RUL Table 6: SM: Summary of the use of headers for RAL to RUL
7.3.3. SM: Example of Flow from RUL to RAL 7.3.3. SM: Example of Flow from RUL to RAL
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> RUL (IPv6 src node) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id
6LR_id --> 6LN --> RAL dst (6LN)
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 D --> Node F Node B --> Node D --> Node F
6LR_ia (Node E) are the intermediate routers from source (not-RPL- 6LR_ia (Node E) are the intermediate routers from source (RUL) (Node
aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In G) to the common parent (6LR_x) (Node B). In this case, 1 <= ia <=
this case, 1 <= ia <= n, n is the number of routers (6LR) that the n, n is the number of routers (6LR) that the packet goes through from
packet ges through from source to the common parent. source to the common parent.
6LR_id (Node D) are the intermediate routers from the common parent 6LR_id (Node D) are the intermediate routers from the common parent
(6LR_x) (Node B) to destination 6LN (Node F). In this case, 1 <= id (6LR_x) (Node B) to destination RAL (Node F). In this case, 1 <= id
<= m, m is the number of routers (6LR) that the packet goes through <= m, m is the number of routers (6LR) that the packet goes through
from the common parent (6LR_x) to destination 6LN. from the common parent (6LR_x) to the destination RAL.
The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node The 6LR_ia (ia=1) (Node E) receives the packet from the RUL (Node G)
(Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 and inserts the RPI header encapsulated in a IPv6-in-IPv6 header.
header. The IPv6-in-IPv6 header is addressed to the destination 6LN The IPv6-in-IPv6 header is addressed to the destination RAL (Node F).
(Node F).
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. for this use case.
+---------+-----+------------+-------------+-------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | | Header |RUL | 6LR_ia | Common | 6LR_id | RAL |
| |src | | Parent | | dst | | |src | | Parent | | dst |
| |node | | (6LRx) | | | | |node | | (6LRx) | | |
+---------+-----+------------+-------------+-------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-----+------------+-------------+-------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Removed | -- | -- | -- | -- |IP6-IP6(RPI)| | Removed | -- | -- | -- | -- |IP6-IP6(RPI)|
| headers | | | | | | | headers | | | | | |
+---------+-----+------------+-------------+-------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
skipping to change at page 29, line 9 skipping to change at page 31, line 32
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+-----+------------+-------------+-------------+------------+ +---------+-----+------------+-------------+-------------+------------+
Figure 12: SM: Summary of the use of headers from RUL to RAL. Figure 12: SM: Summary of the use of headers from RUL to RAL.
7.3.4. SM: Example of Flow from RUL to RUL 7.3.4. SM: Example of Flow from RUL to RUL
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> RUL
--> not-RPL-aware 6LN (IPv6 dst) (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
Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate
router from the not-RPL-aware source (Node G) to the root (6LBR) router from the RUL source (Node G) to the root (6LBR) (Node A). In
(Node A). In this case, "1 < ia <= n", n is the number of routers this case, "1 < ia <= n", n is the number of routers (6LR) that the
(6LR) that the packet goes through from IPv6 src to the root. packet goes through from the RUL to the root.
6LR_id (Node C) are the intermediate routers from the root (Node A) 6LR_id (Node C) are the intermediate routers from the root (Node A)
to the destination Node J. In this case, 1 <= id <= m, m is the to the destination RUL dst node (Node J). In this case, 1 <= id <=
number of routers (6LR) that the packet goes through from the root to m, m is the number of routers (6LR) that the packet goes through from
destination (IPv6 dst). the root to destination RUL.
The RPI is ignored at the IPv6 dst node. The RPI is ignored at the RUL dst node.
The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node The 6LR_1 (Node E) receives the packet from the RUL (Node G) and
G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 header
header. The IPv6-in-IPv6 header is addressed hop-by-hop. directed to the root. The root removes the RPI and inserts a new RPI
header addressed to the 6LR father of the RUL.
The Figure 13 shows the table that summarizes what headers are needed The Figure 13 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
| Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | IPv6 | | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | RUL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | node | | | node | | | | | node |
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
| Inserted| -- |IP6-IP6| -- | | -- | -- | | Inserted| -- |IP6-IP6|IP6-IP6| IP6-IP6 |IP6-IP6| -- |
| headers | | (RPI )| | | | | | headers | | (RPI )| (RPI) | (RPI2) | (RPI2)| |
| | | | | | | | | | | | | | | |
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
| Removed | -- | -- | -- | | -- |IP6-IP6| | Removed | -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| |
| headers | | | | | |(RPI) | | headers | | | (RPI) | (RPI1) | (RPI2)| |
| | | | | | | RPI | | | | | | | | |
| | | | | | |Ignored| | | | | | | | |
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
| Re-added| -- | -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- | -- |
| headers | | | | | | | | headers | | | | | | |
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
| Modified| -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| -- | | Modified| -- | -- | | | | -- |
| headers | | | (RPI) | (RPI) | (RPI) | | | headers | | | | | | |
| | | | | | | | | | | | | | | |
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
|Untouched| -- | -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- | -- |
| headers | | | | | | | | headers | | | | | | |
+---------+------+-------+-------+---------+-------+-------+ +---------+------+-------+-------+---------+-------+-------+
Figure 13: SM: Summary of the use of headers from RUL to RUL Figure 13: SM: Summary of the use of headers from RUL to RUL
8. Non Storing mode 8. Non Storing mode
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 not-RPL aware 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 following table (Figure 14) summarizes what headers are needed in The table (Figure 14) summarizes what headers are needed in the
the following scenarios, and indicates when the RPI, RH3 and IPv6-in- following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6
IPv6 header are to be inserted. It depicts the target destination header are to be inserted. It depicts the target destination address
address possible (indicated by "RAL"), to a 6LR (parent of a 6LN) or possible to a 6LN (indicated by "RAL"), to a 6LR (parent of a 6LN) 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 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 3). In the Figure the (1) indicates a 6tisch case [RFC8180], (Figure 6). In the table (Figure 14) the (1) indicates a 6tisch case
where the RPI header may still be needed for the instanceID to be [RFC8180], where the RPI header may still be needed for the
available for priority/channel selection at each hop. instanceID to be available for priority/channel selection at each
hop.
+-----------------+--------------+-----+-----+------------+------------+ +-----------------+--------------+-----+-----+------------+------------+
| Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6|
| between | | | | | dst | | between | | | | | dst |
+-----------------+--------------+-----+-----+------------+------------+ +-----------------+--------------+-----+-----+------------+------------+
| | RAL to root | Yes | No | No | No | | | RAL to root | Yes | No | No | No |
+ +--------------+-----+-----+------------+------------+ + +--------------+-----+-----+------------+------------+
| Leaf - Root | root to RAL | Yes | Yes | No | No | | Leaf - Root | root to RAL | Yes | Yes | No | No |
+ +--------------+-----+-----+------------+------------+ + +--------------+-----+-----+------------+------------+
| | root to RUL | Yes | Yes | must | 6LR | | | root to RUL | Yes | Yes | must | 6LR |
skipping to change at page 32, line 18 skipping to change at page 34, line 25
traffic to the root. The RPI header must be included since it traffic to the root. The RPI header must be included since it
contains the rank information, which is used to avoid/detect loops. contains the rank information, which is used to avoid/detect loops.
RAL (6LN) --> 6LR_i --> root(6LBR) RAL (6LN) --> 6LR_i --> root(6LBR)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> Node D -->
Node B --> Node A (root) Node B --> Node A (root)
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 (6LN) 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 | 6LN src | 6LR_i | 6LBR dst | | Header | RAL src | 6LR_i | 6LBR dst |
+-------------------+---------+-------+----------+ +-------------------+---------+-------+----------+
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI | | Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- | | Modified 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
skipping to change at page 32, line 44 skipping to change at page 35, line 4
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)
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 D --> Node F --> Node D --> Node F
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 (6LN). packet goes through from source (6LBR) to destination (RAL).
The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is
necessary as the traffic originates with an RPL aware node, the 6LBR. necessary as the traffic originates with an RPL aware node, the 6LBR.
The destination is known to be RPL-aware because the root knows the The destination is known to be RPL-aware because the root knows the
whole topology in non-storing mode. whole topology in non-storing mode.
The Table 8 summarizes what headers are needed for this use case. The Table 8 summarizes what headers are needed for this use case.
+-------------------+----------+-----------+-----------+ +-------------------+----------+-----------+-----------+
| Header | 6LBR src | 6LR_i | 6LN dst | | Header | 6LBR src | 6LR_i | RAL dst |
+-------------------+----------+-----------+-----------+ +-------------------+----------+-----------+-----------+
| Inserted headers | RPI, RH3 | -- | -- | | Inserted headers | RPI, RH3 | -- | -- |
| Removed headers | -- | -- | RH3, RPI | | Removed headers | -- | -- | RH3, RPI |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI, RH3 | -- | | Modified headers | -- | RPI, RH3 | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+----------+-----------+-----------+ +-------------------+----------+-----------+-----------+
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) 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
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 (IPv6). packet goes through from source (6LBR) to destination (RUL).
In 6LBR the RH3 is added, it is modified at each intermediate 6LR In 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 | IPv6 | | Header | 6LBR | 6LR_i | 6LR_n | IPv6 |
| | | i=(1,..,n-1) | | dst | | | | i=(1,..,n-1) | |dst node |
| | | | | node | | | | | | (RUL) |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Inserted | RPI, RH3 | -- | -- | -- | | Inserted | RPI, RH3 | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Removed | -- | -- | | -- | | Removed | -- | -- | | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
skipping to change at page 34, line 33 skipping to change at page 36, line 33
| headers | | | | (both | | headers | | | | (both |
| | | | | ignored) | | | | | | ignored) |
+-----------+----------+--------------+----------------+----------+ +-----------+----------+--------------+----------------+----------+
Figure 15: Non-SM: Summary of the use of headers from root to RUL Figure 15: Non-SM: Summary of the use of headers from root to RUL
8.1.4. Non-SM: Example of Flow from RUL to root 8.1.4. Non-SM: Example of Flow from RUL to root
In this case the flow comprises: In this case the flow comprises:
RUL (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 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 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 (IPv6) to destination (6LBR). For packet goes through from source (RUL) to destination (6LBR). For
example, 6LR_1 (i=1) is the router that receives the packets from the example, 6LR_1 (i=1) is the router that receives the packets from the
IPv6 node. IPv6 node.
In this case the RPI is added by the first 6LR (6LR1) (Node E), In this case the RPI is added by the first 6LR (6LR1) (Node E),
encapsulated in an IPv6-in-IPv6 header, and is modified in the encapsulated in an IPv6-in-IPv6 header, and is modified in the
following 6LRs. The RPI and entire packet is consumed by the root. following 6LRs. The RPI and the entire packet is consumed by the
root.
The Figure 16 shows the table that summarizes what headers are needed The Figure 16 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+----+-----------------+-----------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Header |IPv6| 6LR_1 | 6LR_i | 6LBR dst | | |RUL | | | |
| |src | | | | | Header |src | 6LR_1 | 6LR_i | 6LBR dst |
| |node| | | | | |node| | | |
+---------+----+-----------------+-----------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- | | Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- |
| headers | | | | | | headers | | | | |
+---------+----+-----------------+-----------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)|
| headers | | | | | | headers | | | | |
+---------+----+-----------------+-----------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Re-added| -- | -- | -- | -- | | Re-added| -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
skipping to change at page 35, line 45 skipping to change at page 37, line 45
Internet to RAL Internet to RAL
RUL to Internet RUL to Internet
Internet to RUL Internet to RUL
8.2.1. Non-SM: Example of Flow from RAL to Internet 8.2.1. Non-SM: Example of Flow from RAL to Internet
In this case the flow comprises: In this case the flow comprises:
RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> 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 (6LN) to 6LBR. packet goes through from source (RAL) to 6LBR.
This case is identical to storing-mode case. This case is identical to storing-mode case.
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.
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
| Header | 6LN src | 6LR_i | 6LBR | Internet dst | | Header | RAL src | 6LR_i | 6LBR | Internet dst |
+-------------------+---------+-------+------+----------------+ +-------------------+---------+-------+------+----------------+
| Inserted headers | RPI | -- | -- | -- | | Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
| 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
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 (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 (root) --> Node B --> Node D --> Node F
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(6LN). 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 10 summarizes what headers are needed for this use case.
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Header | Internet | 6LBR | 6LR_i | 6LN src | | Header | Internet | 6LBR | 6LR_i | RAL dst |
| | dst | | | | | | src | | | |
+-----------+----------+--------------+--------------+--------------+ +-----------+----------+--------------+--------------+--------------+
| Inserted | -- | IPv6-in-IPv6 | -- | -- | | Inserted | -- | IPv6-in-IPv6 | -- | -- |
| headers | | (RH3,RPI) | | | | headers | | (RH3,RPI) | | |
| Removed | -- | -- | -- | IPv6-in-IPv6 | | Removed | -- | -- | -- | IPv6-in-IPv6 |
| headers | | | | (RH3,RPI) | | headers | | | | (RH3,RPI) |
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
| Modified | -- | -- | IPv6-in-IPv6 | -- | | Modified | -- | -- | 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 10: 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) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet
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. 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(IPv6) to 6LBR. e.g 6LR_1 (i=1). packet goes through from source (RUL) to 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 IPv6
node. As RPL headers are added in the IPv6 node packet, the first node. As RPL headers are added in the IPv6 node packet, the first
6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header.
The IPv6-in-IPv6 header will be addressed to the root. This case is The IPv6-in-IPv6 header will be addressed to the root. This case is
identical to the storing-mode case (see Section 7.2.3). identical to the storing-mode case (see Section 7.2.3).
The Figure 17 shows the table that summarizes what headers are needed The Figure 17 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 |RUL | 6LR_1 | 6LR_i | 6LBR |Internet|
| |src | | [i=2,..,n] | | dst | | |src | | [i=2,..,n] | | dst |
| |node| | | | | | |node| | | | |
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Inserted| -- |IP6-IP6(RPI) | -- | -- | -- | | Inserted| -- |IP6-IP6(RPI) | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Removed | -- | -- | -- | IP6-IP6(RPI) | -- | | Removed | -- | -- | -- | IP6-IP6(RPI) | -- |
| headers | | | | | | | headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
skipping to change at page 38, line 32 skipping to change at page 40, line 32
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+ +---------+----+-------------+--------------+--------------+--------+
Figure 17: Non-SM: Summary of the use of headers from RUL to Internet Figure 17: Non-SM: Summary of the use of headers from RUL to Internet
8.2.4. Non-SM: Example of Flow from Internet to RUL 8.2.4. Non-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) Internet src --> 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
(root) --> Node B --> Node E --> Node G (root) --> Node B --> Node E --> Node G
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 RUL (IPv6). packet goes through from 6LBR to RUL.
The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The
6LBR will know the path, and will recognize that the final node is 6LBR will know the path, and will recognize that the final node is
not an RPL capable node as it will have received the connectivity DAO not an RPL capable node as it will have received the connectivity DAO
from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6
header destination be the last 6LR. The 6LBR will set to zero the header destination be the last 6LR. The 6LBR will set to zero the
flow label upon entry in order to aid compression [RFC8138]. flow label upon entry in order to aid compression [RFC8138].
The Figure 18 shows the table that summarizes what headers are needed The Figure 18 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+--------+-------------+--------------+--------------+-----+ +---------+--------+-------------+--------------+--------------+-----+
| Header |Internet| 6LBR | 6LR_1 | 6lR_i |IPv6 | | Header |Internet| 6LBR | 6LR_1 | 6lR_i |RUL |
| | src | | | (i=2,...,n) |dst | | | src | | | (i=2,...,n) |dst |
| | | | | |node | | | | | | |node |
+---------+--------+-------------+--------------+--------------+-----+ +---------+--------+-------------+--------------+--------------+-----+
| Inserted| -- | IPv6-in-IPv6| -- | -- | -- | | Inserted| -- | IPv6-in-IPv6| -- | -- | -- |
| headers | | (RH3,RPI) | | | | | headers | | (RH3,RPI) | | | |
+---------+--------+-------------+--------------+--------------+-----+ +---------+--------+-------------+--------------+--------------+-----+
| Removed | -- | -- | -- | IPv6-in-IPv6 | -- | | Removed | -- | -- | -- | IPv6-in-IPv6 | -- |
| headers | | | | (RH3,RPI)[1] | | | headers | | | | (RH3,RPI)[1] | |
+---------+--------+-------------+--------------+--------------+-----+ +---------+--------+-------------+--------------+--------------+-----+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
skipping to change at page 39, line 46 skipping to change at page 41, line 46
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:
6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN 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 --> Node D -->
Node B --> Node A (root) --> Node B --> Node E --> Node H Node B --> Node A (root) --> Node B --> Node E --> Node H
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 6LN 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 header to the original packet, and send the node will add a RPI header to the original packet, and send the
packet upwards. packet upwards.
The originating node must put the RPI into an IPv6-in-IPv6 header The originating node must put the RPI (RPI1) into an IPv6-in-IPv6
addressed to the root, so that the 6LBR can remove that header. If header addressed to the root, so that the 6LBR can remove that
it does not, then additional resources are wasted on the way down to header. If it does not, then additional resources are wasted on the
carry the useless RPI option. way down to carry the useless RPI option.
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 RPI, as add an IPv6-in-IPv6 header. It should be able to remove the
it was contained in an IPv6-in-IPv6 header addressed to it. RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to
Otherwise, there may be a RPI header buried inside the inner IP it. Otherwise, there may be a RPI header buried inside the inner IP
header, which should get ignored. header, which should get ignored. The root inserts a RPI (RPI2)
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 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.
+---------+------------+----------+------------+----------+------------+ +---------+------------+----------+------------+----------+------------+
| Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | dst | | | src | | | | dst |
+---------+------------+----------+------------+----------+------------+ +---------+------------+----------+------------+----------+------------+
| Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- |
| headers | (RPI1) | |(RH3-> 6LN, | | | | headers | (RPI1) | |(RH3-> RAL, | | |
| | | | RPI2) | | | | | | | RPI2) | | |
+---------+------------+----------+------------+----------+------------+ +---------+------------+----------+------------+----------+------------+
| Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6|
| headers | | | (RPI1) | | (RH3, | | headers | | | (RPI1) | | (RH3, |
| | | | | | RPI2) | | | | | | | RPI2) |
+---------+------------+----------+------------+----------+------------+ +---------+------------+----------+------------+----------+------------+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+------------+----------+------------+----------+------------+ +---------+------------+----------+------------+----------+------------+
| Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- | | Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- |
skipping to change at page 41, line 34 skipping to change at page 43, line 34
| 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.
IP6-in-IP6 refers to IPv6-in-IPv6. IP6-in-IP6 refers to IPv6-in-IPv6.
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:
6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 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 --> Node D -->
Node B --> Node A (root) --> Node B --> Node E --> Node G Node B --> Node A (root) --> Node B --> Node E --> Node G
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 6LN will insert a RPI (RPI_1) header As in the previous case, the RAL (6LN) will insert a RPI (RPI_1)
which must be in an IPv6-in-IPv6 header addressed to the root so that header which must be in an IPv6-in-IPv6 header addressed to the root
the 6LBR can remove this RPI. The 6LBR will then insert an RH3 so that the 6LBR can remove this RPI. The 6LBR will then insert an
inside a new IPv6-in-IPv6 header addressed to the 6LR_id. RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id
(6LR_id = m).
The Figure 20 shows the table that summarizes what headers are needed The Figure 20 shows the table that summarizes what headers are needed
for this use case. for this use case.
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
| | src | | | | | dst | | | src | | | | | dst |
| | | | | | | node | | | node | | | | | node |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | | Inserted | 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) | |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
| Re-added | -- | -- | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- | -- | -- |
skipping to change at page 42, line 35 skipping to change at page 44, line 38
| Untouched | -- | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- | -- |
| headers | | | | | | | | headers | | | | | | |
+-----------+---------+---------+---------+---------+---------+------+ +-----------+---------+---------+---------+---------+---------+------+
Figure 20: Non-SM: Summary of the use of headers from RAL to RUL. Figure 20: Non-SM: Summary of the use of headers from RAL to RUL.
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:
not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id
6LR_id --> 6LN --> RAL dst (6LN)
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 E --> Node H Node B --> Node A (root) --> Node B --> Node E --> Node H
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 is This scenario is mostly identical to the previous one. The RPI
added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header (RPI1) is added by the first 6LR (6LR_1) inside an IPv6-in-IPv6
addressed to the root. The 6LBR will remove this RPI, and add it's header addressed to the root. The 6LBR will remove this RPI, and add
own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). it's own IPv6-in-IPv6 header containing an RH3 header and an RPI
(RPI2).
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.
+-----------+------+---------+---------+---------+---------+---------+ +-----------+------+---------+---------+---------+---------+---------+
| Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | | dst | | | src | | | | | dst |
| | node | | | | | | | | node | | | | | node |
+-----------+------+---------+---------+---------+---------+---------+ +-----------+------+---------+---------+---------+---------+---------+
| Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | | Inserted | -- | 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) |
+-----------+------+---------+---------+---------+---------+---------+ +-----------+------+---------+---------+---------+---------+---------+
| Re-added | -- | | -- | -- | -- | -- | | Re-added | -- | | -- | -- | -- | -- |
skipping to change at page 43, line 38 skipping to change at page 45, line 41
| Untouched | -- | | -- | -- | -- | -- | | Untouched | -- | | -- | -- | -- | -- |
| headers | | | | | | | | headers | | | | | | |
+-----------+------+---------+---------+---------+---------+---------+ +-----------+------+---------+---------+---------+---------+---------+
Figure 21: Non-SM: Summary of the use of headers from RUL to RAL. Figure 21: 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:
not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id
6LR_id --> not-RPL-aware (IPv6 dst) --> 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 22 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
| Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL |
| | src | | | | | | dst | | | src | | | | | | dst |
| | node | | | | | | node | | | node | | | | | | node |
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
| Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | | Inserted| -- |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) | |
+---------+------+-------+-------+---------+-------+---------+------+ +---------+------+-------+-------+---------+-------+---------+------+
skipping to change at page 44, line 34 skipping to change at page 46, line 39
| Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | | Modified| -- | -- |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 22: Non-SM: Summary of the use of headers from RUL to RUL
9. Operational Considerations of supporting not-RPL-aware-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
not been configured (explicitly) to examine Hop-by-Hop headers, not been configured (explicitly) to examine Hop-by-Hop headers,
should ignore those headers, and continue processing the packet. should ignore those headers, and continue processing the packet.
skipping to change at page 50, line 17 skipping to change at page 52, line 27
Note: there are some situations where a prefix will spread across Note: there are some situations where a prefix will spread across
multiple LLNs via mechanisms such as the one described in multiple LLNs via mechanisms such as the one described in
[I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering
needs to take this into account, either by exchanging detailed needs to take this into account, either by exchanging detailed
routing information on each LLN, or by moving the BCP38 filtering routing information on each LLN, or by moving the BCP38 filtering
further towards the Internet, so that the details of the multiple further towards the Internet, so that the details of the multiple
LLNs do not matter. LLNs do not matter.
13. Acknowledgments 13. Acknowledgments
This work is done thanks to the grant by the Stand.ICT project. This work is done thanks to the grant given by the StandICT.eu
project.
A special BIG thanks to C. M. Heard for the help with the A special BIG thanks to C. M. Heard for the help with the
Section 4. Much of the redaction in that section is based on his Section 4. Much of the redaction in that section is based on his
comments. comments.
Additionally, the authors would like to acknowledge the review, Additionally, the authors would like to acknowledge the review,
feedback, and comments of (alphabetical order): Robert Cragie, Simon feedback, and comments of (alphabetical order): Robert Cragie, Simon
Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Benjamin Kaduk,
Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. Matthias Kovatsch, Charlie Perkins, Alvaro Retana, Peter van der
Stok, Xavier Vilajosana, Eric Vyncke and Thomas Watteyne.
14. References 14. References
14.1. Normative References 14.1. Normative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/bcp38>. May 2000, <https://www.rfc-editor.org/info/bcp38>.
skipping to change at page 51, line 48 skipping to change at page 54, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
14.2. Informative References 14.2. Informative References
[DDOS-KREBS] [DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016, >145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k- <http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>. cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
progress), April 2019. progress), April 2019.
[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-11 (work Backbone Router", draft-ietf-6lo-backbone-router-13 (work
in progress), February 2019. in progress), September 2019.
[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-19 (work in progress), March 2019. plane-20 (work in progress), July 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
S., 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-22 (work in progress), June 2019. keyinfra-29 (work in progress), October 2019.
[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-09 (work in Architecture", draft-ietf-intarea-tunnels-10 (work in
progress), July 2018. progress), September 2019.
[I-D.thubert-roll-unaware-leaves] [I-D.ietf-roll-unaware-leaves]
Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- Thubert, P. and M. Richardson, "Routing for RPL Leaves",
unaware-leaves-07 (work in progress), April 2019. draft-ietf-roll-unaware-leaves-06 (work in progress),
November 2019.
[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 13 skipping to change at page 56, line 24
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 Aalto University, Finland - / - Universidad Tecnologica Nacional - Facultad Regional Mendoza, Argentina
Otaniemi
Espoo 02150
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
Cisco Systems, Inc Cisco Systems, Inc
Village d'Entreprises Green Side 400, Avenue de Roumanille Building D
Batiment T3, Biot - Sophia Antipolis 06410 45 Allee des Ormes - BP1200
France MOUGINS - Sophia Antipolis 06254
FRANCE
Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
 End of changes. 146 change blocks. 
312 lines changed or deleted 382 lines changed or added

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