rfc9008xml2.original.xml   rfc9008.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-roll-useofrp
linfo-44" number="9008" ipr="trust200902" updates="6550, 6553, 8138" obsoletes="
" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude
="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!ENTITY RFC6550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!-- xml2rfc v2v3 conversion 3.5.0 -->
.6550.xml">
<!ENTITY RFC8138 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8138.xml">
<!ENTITY RFC8200 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8200.xml">
<!ENTITY RFC6553 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6553.xml">
<!ENTITY RFC6554 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6554.xml">
<!ENTITY RFC6040 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6040.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC7102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7102.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4443.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6775.xml">
<!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2473.xml">
<!ENTITY RFC4302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4302.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4301.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4303.xml">
<!ENTITY RFC7321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7321.xml">
<!ENTITY RFC7416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7416.xml">
<!ENTITY RFC8180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8180.xml">
<!ENTITY RFC8505 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8505.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2460.xml">
<!ENTITY RFC6437 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6437.xml">
]>
<!-- -->
<!--<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-roll-useofrplinfo-44" ipr="trust200902"
updates="6553, 6550, 8138">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!-- [rfced] FYI There are [auth] comments included throughout
the file. We have left them in for now, in case you want to review.
However, please note that these will be removed from the XML file
prior to publication.
-->
-&gt;
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="RPL-data-plane">Using RPI Option Type, Routing Header for Sour
ce Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane</title>
<author initials="M.I." surname="Robles" fullname="Maria Ines Robles"> <title abbrev="RPL Data Plane">Using RPI Option Type, Routing Header for Sour
<organization abbrev="UTN-FRM/Aalto"> ce Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane</title>
<seriesInfo name="RFC" value="9008"/>
<author initials="M.I." surname="Robles" fullname="Maria Ines Robles">
<organization abbrev="UTN-FRM/Aalto">
Universidad Tecno. Nac.(UTN)-FRM, Argentina /Aalto University Finland Universidad Tecno. Nac.(UTN)-FRM, Argentina /Aalto University Finland
</organization> </organization>
<address> <address>
<postal>
<street>Coronel Rodríguez 273</street>
<city>Mendoza</city>
<region>Provincia de Mendoza</region>
<code>M5500</code>
<country>Argentina</country>
</postal>
<email>mariainesrobles@gmail.com</email>
</address>
</author>
<author initials="M." surname="Richardson" fullname="Michael C. Richardson">
<organization abbrev="SSW">Sandelman Software Works</organization>
<address>
<postal> <postal>
<street>470 Dawson Avenue</street> <street>Coronel Rodríguez 273</street>
<city>Ottawa</city> <city>Mendoza</city>
<region>ON</region> <region>Provincia de Mendoza</region>
<code>K1Z 5V7</code> <code>M5500</code>
<country>CA</country> <country>Argentina</country>
</postal>
<email>mariainesrobles@gmail.com</email>
</address>
</author>
<author initials="M." surname="Richardson" fullname="Michael C. Richardson">
<organization abbrev="SSW">Sandelman Software Works</organization>
<address>
<postal>
<street>470 Dawson Avenue</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Z 5V7</code>
<country>Canada</country>
</postal> </postal>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/mcr/</uri> <uri>http://www.sandelman.ca/mcr/</uri>
</address> </address>
</author>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert"> <author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco">Cisco Systems, Inc</organization> <organization abbrev="Cisco">Cisco Systems, Inc</organization>
<address> <address>
<postal> <postal>
<street>Building D</street> <extaddr>Building D</extaddr>
<street>45 Allee des Ormes - BP1200 </street> <street>45 Allee des Ormes - BP1200 </street>
<city>MOUGINS - Sophia Antipolis</city> <city>MOUGINS - Sophia Antipolis</city>
<code>06254</code> <code>06254</code>
<country>FRANCE</country> <country>France</country>
</postal> </postal>
<phone>+33 497 23 26 34</phone> <phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email> <email>pthubert@cisco.com</email>
</address> </address>
</author> </author>
<date year="2021" month="March"/>
<date /> <area>Internet</area>
<workgroup>ROLL Working Group</workgroup>
<area>Internet</area> <keyword>RPL Option</keyword>
<keyword>6LoWPAN</keyword>
<workgroup>ROLL Working Group</workgroup> <keyword>RFC 6553</keyword>
<abstract>
<keyword>RPL Option</keyword>
<keyword>6LoWPAN</keyword>
<keyword>RFC 6553</keyword>
<abstract>
<t> <t>
This document looks at different data flows through LLN (Low-Power and L ossy Networks) where RPL This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL
(IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to esta blish routing. (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to esta blish routing.
The document enumerates the cases where RFC6553 (RPI Option Type), RFC65 The document enumerates the cases where RPL Packet Information (RPI) Opt
54 (Routing Header for Source Routes) ion Type (RFC 6553),
and IPv6-in-IPv6 encapsulation is required in data plane. RPL Source Route Header (RFC 6554),
This analysis provides the basis on which to design efficient compressio and IPv6-in-IPv6 encapsulation are required in the data plane.
n of these headers. This analysis provides the basis upon which to design efficient compress
This document updates RFC6553 adding a change to the RPI Option Type. Ad ion of these headers.
ditionally, this document updates This document updates RFC 6553 by adding a change to the RPI Option Type
RFC6550 defining a flag in the DIO Configuration option to indicate abou . Additionally, this document updates
t this change and RFC 6550 by defining a flag in the DODAG Information Object (DIO) Config
updates RFC8138 as well to consider the new Option Type when the RPL Opt uration option to indicate this change and
ion is decompressed. updates RFC 8138 as well to consider the new Option Type when the RPL Op
tion is decompressed.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
<xref target="RFC6550"/> is a routing protocol for <xref target="RFC6550" format="default"/> is a routing protocol f
constrained networks. <xref target="RFC6553"/> or
defines the RPL Option carried within the IPv6 Hop-by-Hop constrained networks. <xref target="RFC6553" format="default"/>
Header to carry the RPLInstanceID and quickly identify inconsist defines the RPL Option carried within the IPv6 Hop-by-Hop Option
encies (loops) in the routing topology. s
header to carry the RPLInstanceID and quickly identify inconsist
encies (loops) in the routing topology.
The RPL Option is commonly referred to as the RPL Packet Informa tion The RPL Option is commonly referred to as the RPL Packet Informa tion
(RPI) though the RPI is the routing information that is defined (RPI), although the RPI is the routing information that is defin
in <xref target="RFC6550"/> and transported in the RPL Option. ed
RFC6554 <xref target="RFC6554"/> defines the "RPL Source Route H in <xref target="RFC6550" format="default"/> and transported in
eader" (RH3), an the RPL Option.
IPv6 Extension Header to deliver datagrams within a RPL RFC 6554 <xref target="RFC6554" format="default"/> defines the "
routing domain, particularly in non-storing mode. RPL Source Route Header" (RH3), an
</t> IPv6 extension header to deliver datagrams within a RPL
<t> routing domain, particularly in Non-Storing mode.
</t>
<t>
These various items are referred to as RPL artifacts, and These various items are referred to as RPL artifacts, and
they are seen on all of the data-plane traffic that occurs in they are seen on all of the data plane traffic that occurs in
RPL routed networks; they do not in general appear on the RPL RPL-routed networks; they do not, in general, appear on the RPL
control plane traffic at all which is mostly Hop-by-Hop control plane at all, which is mostly hop-by-hop
traffic (one exception being DAO messages in non-storing mode). traffic (one exception being Destination Advertisement Object (D
</t> AO) messages in Non-Storing mode).
<t> </t>
<t>
It has become clear from attempts to do multi-vendor It has become clear from attempts to do multi-vendor
interoperability, and from a desire to compress as many of interoperability, and from a desire to compress as many of
the above artifacts as possible that not all implementers the above artifacts as possible, that not all implementers
agree when artifacts are necessary, or when they can be safely agree when artifacts are necessary, or when they can be safely
omitted, or removed. omitted, or removed.
</t> </t>
<t>
<t> The ROLL (Routing Over Low power and Lossy networks) Working Grou
The ROLL WG analyzed how <xref target="RFC2460" /> rules apply to p
storing and analyzed how IPv6 rules <xref target="RFC2460" format="default"/>
non-storing use of RPL. The result was 24 data plane use apply to the Storing and
Non-Storing use of RPL. The result was 24 data-plane use
cases. They are exhaustively outlined here in order to be cases. They are exhaustively outlined here in order to be
completely unambiguous. During the processing of this completely unambiguous. During the processing of this
document, new rules were published as document, new rules were published as
<xref target="RFC8200"/>, and this document was updated <xref target="RFC8200" format="default"/>, and this document was updated
to reflect the normative changes in that document. to reflect the normative changes in that document.
</t> </t>
<t> <t>
This document updates <xref target="RFC6553"/>, changing the valu This document updates <xref target="RFC6553" format="default"/>,
e of the Option Type of the RPL Option changing the value of the Option Type of the RPL Option
to make <xref target="RFC8200"/> routers ignore this option when to make routers compliant with <xref target="RFC8200" format="def
not recognized. ault"/> ignore this option when it is not recognized.
</t> </t>
<t> <t>
A Routing Header Dispatch for 6LoWPAN (6LoRH)(<xref target="RFC81 A Routing Header Dispatch for IPv6 over Low-Power Wireless Person
38" />) al Area Networks (6LoWPAN) (6LoRH) <xref target="RFC8138" format="default"/>
defines a mechanism for compressing RPL Option information and R outing Header type 3 (RH3) defines a mechanism for compressing RPL Option information and R outing Header type 3 (RH3)
<xref target="RFC6554"/>, as well as an efficient IPv6-in-IPv6 t <xref target="RFC6554" format="default"/>, as well as an efficie
echnique. nt IPv6-in-IPv6 technique.
</t><t> </t>
<t>
Most of the use cases described herein require the use of IPv6-i n-IPv6 packet encapsulation. Most of the use cases described herein require the use of IPv6-i n-IPv6 packet encapsulation.
When encapsulating and decapsulating packets, <xref target="RFC6 040"/> MUST be applied to map the When encapsulating and decapsulating packets, <xref target="RFC6 040" format="default"/> <bcp14>MUST</bcp14> be applied to map the
setting of the explicit congestion notification (ECN) field betw een inner and outer headers. setting of the explicit congestion notification (ECN) field betw een inner and outer headers.
Additionally, <xref target="I-D.ietf-intarea-tunnels"/> is recom mended reading to explain Additionally, <xref target="I-D.ietf-intarea-tunnels" format="de fault"/> is recommended reading to explain
the relationship of IP tunnels to existing protocol layers and t he challenges the relationship of IP tunnels to existing protocol layers and t he challenges
in supporting IP tunneling. in supporting IP tunneling.
</t> </t>
<t>
Non-constrained uses of RPL are not in scope of this document, a
nd
applicability statements for those uses may provide different
advice, E.g. <xref target="I-D.ietf-anima-autonomic-control-plan
e" />.
</t>
<section title="Overview">
<t>
The rest of the document is organized as follows: Section 2 descr
ibes the used terminology.
Section 3 provides a RPL Overview.
Section 4 describes the updates to RFC6553, RFC6550 and RFC 8138.
Section 5 provides the reference topology used for the uses cases
.
Section 6 describes the use cases included.
Section 7 describes the storing mode cases and section 8 the non-
storing mode cases.
Section 9 describes the operational considerations of supporting
RPL-unaware-leaves.
Section 10 depicts operational considerations for the proposed ch
ange on RPI Option Type, section 11 the
IANA considerations and then section 12 describes the security
aspects.
</t>
</section>
</section>
<section title="Terminology and Requirements Language">
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL Unconstrained uses of RPL are not in scope of this document, and
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", applicability statements for those uses may provide different
"MAY", and "OPTIONAL" in this document are to be interpreted as advice, e.g., <xref target="I-D.ietf-anima-autonomic-control-pla
described in BCP 14 ne" format="default"/>.
<xref target="RFC2119" />
<xref target="RFC8174" /> when, and only when, they
appear in all capitals, as shown here.
</t> </t>
<section numbered="true" toc="default">
<name>Overview</name>
<t> <t>
Terminology defined in <xref target="RFC7102"/> applies to this document The rest of the document is organized as follows: <xref target="s
: LLN, RPL, RPL domain and ROLL. ec_terms" format="default"/> describes the terminology that is used.
<xref target="sec_rpl_overview" format="default"/> provides a RPL
overview.
<xref target="updateRFCs_section" format="default"/> describes the
updates to RFC 6553, RFC 6550, and RFC 8138.
<xref target="sec_ref_topo" format="default"/> provides the refer
ence topology used for the use cases.
<xref target="sec_use_cases" format="default"/> describes the use
cases included.
<xref target="sec_sm" format="default"/> describes the Storing mo
de cases and <xref target="sec_non-sm" format="default"/> the Non-Storing mode c
ases.
<xref target="notrplaware" format="default"/> describes the opera
tional considerations of supporting RPL-unaware leaves.
<xref target="sec_op_con_0x23" format="default"/> depicts operati
onal considerations for the proposed change on RPI Option Type, <xref target="ia
na" format="default"/> the
IANA considerations, and then <xref target="Security" format="def
ault"/> describes the security
aspects.
</t> </t>
</section>
</section>
<section anchor="sec_terms" numbered="true" toc="default">
<name>Terminology and Requirements Language</name>
<t> <t>
Consumed: A Routing Header is consumed when the Segments Left field is z The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
ero, which indicates that the IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>
The following terminology defined in <xref target="RFC7102" format="defa
ult"/> applies to this document: LLN, RPL, RPL domain, and ROLL.
</t>
<dl>
<dt>
Consumed:</dt><dd>A Routing Header is consumed when the Segments Left fi
eld is zero, which indicates that the
destination in the IPv6 header is the final destination of the packet an d that the hops in the Routing Header destination in the IPv6 header is the final destination of the packet an d that the hops in the Routing Header
have been traversed. have been traversed.
</t> </dd>
<t> <dt>
RPL Leaf: An IPv6 host that is attached to a RPL router and obtains conn RPL Leaf:</dt><dd>An IPv6 host that is attached to a RPL router and obta
ectivity ins connectivity
through a RPL Destination Oriented Directed Acyclic Graph (DODAG). As an through a RPL Destination-Oriented Directed Acyclic Graph (DODAG). As an
IPv6 node, IPv6 node,
a RPL Leaf is expected to ignore a consumed Routing Header and as an IPv a RPL leaf is expected to ignore a consumed Routing Header, and as an IP
6 host, it v6 host, it
is expected to ignore a Hop-by-Hop header. It results that a RPL Leaf ca is expected to ignore a Hop-by-Hop Options header. Thus, a RPL leaf can
n correctly correctly
receive a packet with RPL artifacts. On the other hand, a RPL Leaf is no receive a packet with RPL artifacts. On the other hand, a RPL leaf is no
t expected t expected
to generate RPL artifacts or to support IP-in-IP encapsulation. For simp lification, to generate RPL artifacts or to support IP-in-IP encapsulation. For simp lification,
this document uses the standalone term leaf to mean a RPL leaf. this document uses the standalone term leaf to mean a RPL leaf.
</t> </dd>
<t> <dt>
RPL Packet Information (RPI): RPL Packet Information (RPI):</dt><dd>
The information defined abstractly in <xref target="RFC6550"/> to be pla The information defined abstractly in <xref target="RFC6550" format="def
ced in IP packets. ault"/> to be placed in IP packets.
The term is commonly used, including in this document, to refer to the R The term is commonly used, including in this document, to refer to the R
PL Option <xref target="RFC6553"/> PL Option <xref target="RFC6553" format="default"/>
that transports that abstract information in an IPv6 Hop-by-Hop Header. that transports that abstract information in an IPv6 Hop-by-Hop Options
<xref target="RFC8138"/> provides header. <xref target="RFC8138" format="default"/> provides
an alternate (more compressed) formating for the same abstract informati an alternate (more compressed) formatting for the same abstract informa
on. tion.
</t> </dd>
<t> <dt>
RPL-aware-node (RAN): A device which implements RPL. Please note that th RPL-Aware Node (RAN):</dt><dd>A device that implements RPL. Please note
e device can be found inside the LLN or outside LLN. that the device can be found inside the LLN or outside LLN.
</t> </dd>
<t> <dt>
RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. RPL-Aware Leaf (RAL):</dt><dd>A RPL-aware node that is also a RPL leaf.
</t> </dd>
<t> <dt>
RPL-unaware-node: A device which does not implement RPL, thus the device RPL-Unaware Node:</dt><dd>A device that does not implement RPL, thus the
is not-RPL-aware. device is RPL unaware.
Please note that the device can be found inside the LLN. Please note that the device can be found inside the LLN.
</t> </dd>
<t> <dt>
RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. RPL-Unaware Leaf (RUL):</dt><dd>A RPL-unaware node that is also a RPL le
</t> af.
</dd>
<!-- Note: blockquote could be used here, but it doesn't work in <dd/>:
https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/570
<t> Check status of this before pub.
6LoWPAN Node (6LN): <xref target="RFC6775"/> defines it as: "A 6LoWPA
N node is any host or router participating in a LoWPAN. And since there are three places where it can't be used in the terminology,
it seemed odd to use it in Section 4.2, which is just a fragment of a quote.
-->
<dt>
6LoWPAN Node (6LN):</dt><dd><xref target="RFC6775" format="default"/>
defines it as the following:
"A 6LoWPAN node is any host or router participating in a LoWPAN.
This term is used when referring to situations in which either a This term is used when referring to situations in which either a
host or router can play the role described.". In this document, a 6LN acts host or router can play the role described." In this document, a 6LN acts
as a leaf. as a leaf.
</t> </dd>
<t> <dt>
6LoWPAN Router (6LR): <xref target="RFC6775"/> defines it as:" An intermed 6LoWPAN Router (6LR):</dt><dd><xref target="RFC6775" format="default"/> de
iate router in the LoWPAN that is able to send and fines it as the following:
"An intermediate router in the LoWPAN that is able to send and
receive Router Advertisements (RAs) and Router Solicitations (RSs) receive Router Advertisements (RAs) and Router Solicitations (RSs)
as well as forward and route IPv6 packets. 6LoWPAN routers are as well as forward and route IPv6 packets. 6LoWPAN routers are
present only in route-over topologies." present only in route-over topologies."
</t> </dd>
<t> <dt>
6LoWPAN Border Router (6LBR): <xref target="RFC6775"/> defines it as:"A bo 6LoWPAN Border Router (6LBR):</dt><dd><xref target="RFC6775" format="defau
rder router located at the junction of separate 6LoWPAN lt"/> defines it as the following:
"A border router located at the junction of separate 6LoWPAN
networks or between a 6LoWPAN network and another IP network. networks or between a 6LoWPAN network and another IP network.
There may be one or more 6LBRs at the 6LoWPAN network boundary. A There may be one or more 6LBRs at the 6LoWPAN network boundary. A
6LBR is the responsible authority for IPv6 prefix propagation for 6LBR is the responsible authority for IPv6 prefix propagation for
the 6LoWPAN network it is serving. An isolated LoWPAN also the 6LoWPAN network it is serving. An isolated LoWPAN also
contains a 6LBR in the network, which provides the prefix(es) for contains a 6LBR in the network, which provides the prefix(es) for
the isolated network." the isolated network."
</t> </dd>
<t>
Flag Day: A Flag Day is caused when a network is reconfigured in a way <dt>
that nodes running the older configuration can not communicate with nodes runni Flag Day:</dt><dd>A flag day is caused when a network is reconfigured
ng the new configuration. For instance, when the ARPANET changed from IP versio in a way that nodes running the older configuration cannot communicate with node
n 3 to IP version 4 on January 1, 1983 (<xref target="RFC0801" />). s running the new configuration. An example of a flag day is when the ARPANET c
In the context of this document, a switch from RPI Option Type (0x63) hanged from IP version 3 to IP version 4 on January 1, 1983 <xref target="RFC080
and Option Type (0x23) presents as a disruptive changeover. In order to reduce 1" format="default"/>.
the amount of time for such a changeover, <xref target="update6550" /> provides In the context of this document, a switch from RPI Option Type (0x63)
a mechanism to allow nodes to be incrementally upgraded. to Option Type (0x23) presents as a disruptive changeover. In order to reduce t
</t> he amount of time for such a changeover, <xref target="update6550" format="defau
<t> lt"/> provides a mechanism to allow nodes to be incrementally upgraded.
Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- </dd>
aware-nodes send information to the root about their parents. Thus, the <dt>
root knows the topology. Non-Storing Mode (Non-SM):</dt><dd>A RPL mode of operation in which t
Because the root knows the topology, the intermediate 6LRs do not maintai he RPL-aware
n routing state and nodes send information to the root about their parents. Thus, the root k
nows the topology.
Because the root knows the topology, the intermediate 6LRs do not maintai
n routing state, and
source routing is needed. source routing is needed.
</t> </dd>
<t> <dt>
Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes (6LRs) Storing Mode (SM):</dt><dd>A RPL mode of operation in which RPL-aware no
maintain routing des (6LRs) maintain routing
state (of the children) so that source routing is not needed. state (of the children) so that source routing is not needed.
</t> <t> </dd>
Note: Due to lack of space in some figures (tables) we refer to IPv6-in- </dl>
IPv6 as IP6-IP6. <aside><t>
</t> Note: Due to lack of space in some tables, we refer to IPv6-in-IPv6 as I
</section> P6-IP6.
<section title="RPL Overview"> </t></aside>
<t> </section>
RPL defines the RPL Control messages (control plane), a new <section anchor="sec_rpl_overview" numbered="true" toc="default">
ICMPv6 <xref target="RFC4443"/> message with Type 155. <name>RPL Overview</name>
DIS (DODAG Information Solicitation), DIO (DODAG Information Object) <t>
RPL defines the RPL control message (control plane), which is an
ICMPv6 message <xref target="RFC4443" format="default"/> with a Type of
155.
DIS (DODAG Information Solicitation), DIO (DODAG Information Object),
and DAO (Destination Advertisement Object) messages are and DAO (Destination Advertisement Object) messages are
all RPL Control messages but with different Code values. all RPL control messages but with different Code values.
A RPL Stack is shown in <xref target="fig_RPLStack"/>. A RPL stack is shown in <xref target="fig_RPLStack" format="default"/>.
</t> </t>
<t> <figure anchor="fig_RPLStack">
<figure title="RPL Stack." anchor="fig_RPLStack" align="center"> <name>RPL Stack</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------------+ +--------------+
| Upper Layers | | Upper Layers |
| | | |
+--------------+ +--------------+
| RPL | | RPL |
| | | |
+--------------+ +--------------+
| ICMPv6 | | ICMPv6 |
| | | |
+--------------+ +--------------+
| IPv6 | | IPv6 |
| | | |
+--------------+ +--------------+
| 6LoWPAN | | 6LoWPAN |
| | | |
+--------------+ +--------------+
| PHY-MAC | | PHY-MAC |
| | | |
+--------------+ +--------------+
]]></artwork></figure> ]]></artwork>
</t> </figure>
<t> <t>
RPL supports two modes of Downward internal traffic: in storing mode (SM RPL supports two modes of Downward internal traffic: in Storing mode (SM
), ),
it is fully stateful; in non-storing mode (Non-SM), it is fully source it is fully stateful; in Non-Storing mode (non-SM), it is fully source
routed. A RPL Instance is either fully storing or fully routed. A RPL Instance is either fully Storing or fully
non-storing, i.e. a RPL Instance with a combination of a fully Non-Storing, i.e., a RPL Instance with a combination of fully
storing and non-storing nodes is not supported with the Storing and Non-Storing nodes is not supported with the
current specifications at the time of writing this document. current specifications at the time of writing this document.
External routes are advertised with non-storing-mode messaging External routes are advertised with non-SM messaging
even in a storing mode network, see <xref target="nnstext"/> even in an SM network, see <xref target="nnstext" format="default"/>
</t> </t>
</section>
</section> <section anchor="updateRFCs_section" numbered="true" toc="default">
<name>Updates to RFC 6550, RFC 6553, and RFC 8138</name>
<section anchor="updateRFCs_section" title="Updates to RFC6550, RFC6553 <section anchor="updateRFC_section6550" numbered="true" toc="default">
and RFC8138"> <name>Updates to RFC 6550</name>
<section anchor="nnstext" numbered="true" toc="default">
<section anchor="updateRFC_section6550" title="Updates to RFC6550"> <name>Advertising External Routes with Non-Storing Mode Signaling</nam
e>
<section anchor="nnstext" title="Advertising External Routes with Non
-Storing Mode Signaling.">
<t> <t>
Section 6.7.8. of <xref target="RFC6550"/> introduces the 'E' flag tha t <xref target="RFC6550" section="6.7.8" sectionFormat="of" format="defa ult"/> introduces the 'E' flag that
is set to indicate that the 6LR that generates the DAO redistributes is set to indicate that the 6LR that generates the DAO redistributes
external targets into the RPL network. An external Target is a Target external targets into the RPL network. An external target is a target
that has been learned through an alternate protocol, for instance a 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 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 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 external target cannot be guaranteed to ignore the RPL artifacts and
cannot be expected to process the <xref target="RFC8138"/> compression cannot be expected to process the compression defined in <xref target= "RFC8138" format="default"/>
correctly. This means that the RPL artifacts should be contained in an 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 IP-in-IP encapsulation that is removed by the 6LR, and that any
remaining compression should be expanded by the 6LR before it forwards remaining compression should be expanded by the 6LR before it forwards
a packet outside the RPL domain. a packet outside the RPL domain.
</t><t> </t>
This specification updates <xref target="RFC6550"/> to RECOMMEND that <t>
external targets are advertised using Non-Storing Mode DAO messaging This specification updates <xref target="RFC6550" format="default"/> t
even in a Storing-Mode network. This way, external routes are not o say that advertising external
advertised within the DODAG and all packets to an external target targets using Non-Storing mode DAO messaging even in a Storing mode
reach the Root like normal Non-Storing Mode traffic. The Non-Storing network is <bcp14>RECOMMENDED</bcp14>. This way, external routes are
Mode DAO informs the Root of the address of the 6LR that injects the 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, 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 which terminates the IP-in-IP tunnel and forwards the original packet
outside the RPL domain free of RPL artifacts. outside the RPL domain free of RPL artifacts.
</t><t> </t>
<t>
In the other direction, In the other direction,
for traffic coming from an external target into the LLN, the parent for traffic coming from an external target into the LLN, the parent
(6LR) that injects the traffic always encapsulates to the root. (6LR) that injects the traffic always encapsulates to the root.
This whole operation is This whole operation is
transparent to intermediate routers that only see traffic between the transparent to intermediate routers that only see traffic between the
6LR and the Root, and only the Root and the 6LRs that inject external 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 routes in the network need to be upgraded to add this function to the
network. network.
</t><t> </t>
<t>
A RUL is a special case of external target when the target is actually 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 a host, and it is known to support a consumed Routing Header and to
ignore a Hop-by-Hop header as prescribed by <xref target="RFC8200"/>. ignore a Hop-by-Hop Options header as prescribed by <xref target="RFC8
200" format="default"/>.
The target may have been learned through an external routing protocol or may have The target may have been learned through an external routing protocol or may have
been registered to the 6LR using <xref target="RFC8505"/>. been registered to the 6LR using <xref target="RFC8505" format="defaul
</t><t> t"/>.
</t>
<t>
In order to enable IP-in-IP all the way to a 6LN, it is beneficial In order to enable IP-in-IP all the way to a 6LN, it is beneficial
that the 6LN supports decapsulating IP-in-IP, but that is not assumed that the 6LN supports decapsulating IP-in-IP, but that is not assumed
by <xref target="RFC8504"/>. by <xref target="RFC8504" format="default"/>.
If the 6LN is a RUL, the Root that encapsulates a packet SHOULD If the 6LN is a RUL, the root that encapsulates a packet <bcp14>SHOULD
terminate the tunnel at a parent 6LR unless it is aware that the RUL </bcp14>
supports IP-in-IP decapsulation. terminate the tunnel at a parent 6LR. The root may encapsulate all the
</t><t> way to the RUL if it is aware that the RUL supports IP-in-IP decapsula
tion
and the artifacts in the outer header chain.
</t>
<t>
A node that is reachable over an external route is not expected to A node that is reachable over an external route is not expected to
support <xref target="RFC8138"/>. Whether a decapsulation took place support <xref target="RFC8138" format="default"/>. Whether a decapsula tion took place
or not and even when the 6LR is delivering the packet to a RUL, the 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 6LR that injected an external route <bcp14>MUST</bcp14> undo the <xref target="RFC8138" format="default"/> compression on the packet before
forwarding over that external route. forwarding over that external route.
</t> </t>
</section> </section>
<section anchor="mopchanges" title="Configuration Options and Mode <section anchor="mopchanges" numbered="true" toc="default">
of Operation"> <name>Configuration Options and Mode of Operation</name>
<t> <t>
Section 6.7.6 of RFC6550 describes the DODAG Configuration Option <xref target="RFC6550" section="6.7.6" sectionFormat="of" format="
as default"/> describes the DODAG Configuration option as
containing a series of Flags in the first octet of the payload. containing a series of flags in the first octet of the payload.
</t> </t>
<t> <t>
Anticipating future work to revise RPL relating to how the LLN and DODAG Anticipating future work to revise RPL relating to how the LLN and DODAG
are configured, this document renames the DODAG Configuration Opti are configured, this document renames the IANA "DODAG Configuratio
on n Option
Flags registry so that it applies to Mode of Operation (MOP) value Flags" subregistry so that it applies to Mode of Operation (MOP) v
s zero alues zero
(0) to six (6) only, leaving the flags unassigned for MOP value se (0) through six (6) only, leaving the flags unassigned for MOP val
ven ue seven
(7).The MOP is described in RFC6550 section 6.3.1. (7). The MOP is described in <xref target="RFC6550" section="6.3.1
" sectionFormat="comma" format="default"/>.
</t> </t>
<t> <t>
In addition, this document reserves MOP value 7 for future expansi on. In addition, this document reserves MOP value 7 for future expansi on.
</t> </t>
<t> <t>
See Sections 11.2 and 11.3. See Sections <xref target="sec_op_flags_reg" format="counter"/> and <xref target="sec_mop_val_change" format="counter"/>.
</t> </t>
</section> </section>
<section title="Indicating the new RPI in the <section anchor="update6550" numbered="true" toc="default">
DODAG Configuration option Flag. " anchor="update6550" <name>Indicating the New RPI in the DODAG Configuration Option Flag</n
> ame>
<t> <t>
In order to avoid a Flag Day caused by lack of interoperation In order to avoid a flag day caused by lack of interoperation
between new RPI Option Type (0x23) and old RPI Option Type (0x63) no between nodes of the new RPI Option Type (0x23) and old RPI Option T
des, this section ype (0x63), this section
defines a flag in the DIO Configuration option, to indicate when defines a flag in the DODAG Configuration option, to indicate when
the new RPI Option Type can be safely used. This means, the flag is the new RPI Option Type can be safely used. This means that the flag
going is going
to indicate the value of Option Type that the network will be using for the RPL Option. Thus, when a to indicate the value of Option Type that the network will be using for the RPL Option. Thus, when a
node joins to a network it will know which value to use. node joins to a network, it will know which value to use.
With this, RPL-capable nodes know if it is safe to use 0x23 when cre ating a new RPL Option. With this, RPL-capable nodes know if it is safe to use 0x23 when cre ating a new RPL Option.
A node that forwards a packet with an RPI MUST NOT modify the Option Type of the RPL Option. A node that forwards a packet with an RPI <bcp14>MUST NOT</bcp14> mo dify the Option Type of the RPL Option.
</t> </t>
<t> <t>
This is done using a DODAG Configuration option flag which will This is done using a DODAG Configuration option flag that will
signal "RPI 0x23 enable" and propagate through the network. signal "RPI 0x23 enable" and propagate through the network.
Section 6.3.1. of <xref target="RFC6550"/> defines a 3-bit Mode of <xref target="RFC6550" section="6.3.1" sectionFormat="of" format=" default"/> defines a 3-bit Mode of
Operation (MOP) in the DIO Base Object. The flag is defined only Operation (MOP) in the DIO Base Object. The flag is defined only
for MOP value between 0 to 6. for MOP value between 0 to 6.
</t> </t>
<t> <t>
For a MOP value of 7, a node MUST use the RPI 0x23 option. For a MOP value of 7, a node <bcp14>MUST</bcp14> use the RPI 0x23
</t> option.
<t> </t>
As stated in <xref target="RFC6550"/> the DODAG Configuration opti <t>
on is present in DIO messages. As stated in <xref target="RFC6550" format="default"/>, the DODAG
Configuration option is present in DIO messages.
The DODAG Configuration option distributes configuration The DODAG Configuration option distributes configuration
information. It is generally static, and does not change within information. It is generally static, and it does not change withi n
the DODAG. the DODAG.
This information is configured at the DODAG root and distributed This information is configured at the DODAG root and distributed
throughout the DODAG with the DODAG Configuration option. throughout the DODAG with the DODAG Configuration option.
Nodes other than the DODAG root do not modify this information whe n Nodes other than the DODAG root do not modify this information whe n
propagating the DODAG Configuration option. propagating the DODAG Configuration option.
</t> </t>
<t> <t>
Currently, the DODAG Configuration option in <xref target="RFC6550 Currently, the DODAG Configuration option in <xref target="RFC6550
"/> states: " format="default"/> states
"the unused bits MUST be initialized to zero by the sender that the unused bits "<bcp14>MUST</bcp14> be initialized to zero b
and MUST be ignored by the receiver". If the flag is received wi y the sender
th a and <bcp14>MUST</bcp14> be ignored by the receiver." If the flag i
value zero (which is the default), then new nodes will remain in s received with a
RFC6553 Compatible Mode; originating traffic with the old-RPI Opti value zero, which is the default, then new nodes will remain compati
on Type (0x63) value. ble with
RFC 6553 -- originating traffic with the old RPI Option Type value
(0x63).
If the flag is received with a value of 1, then the value for the If the flag is received with a value of 1, then the value for the
RPL Option MUST be set to 0x23. RPL Option <bcp14>MUST</bcp14> be set to 0x23.
</t> </t>
<t> <t>
Bit number three of the flag field in the DODAG Configuration optio Bit number three of the Flags field in the DODAG Configuration opti
n on
is to be used as shown in <xref target="fig_RPIflagday2"/> (which i is to be used as shown in <xref target="fig_RPIflagday2" format="de
s the same as <xref target="fig_RPIflagdayConfOption"/> fault"/> (which is the same as <xref target="fig_RPIflagdayConfOption" format="d
in <xref target="iana"/> and is shown here for convenience): efault"/>
</t> in <xref target="iana" format="default"/> and is shown here for con
<t> venience):
<figure title="DODAG Configuration option Flag to indicate the RPI-fla </t>
g-day." anchor="fig_RPIflagday2" align="center">
<artwork> <![CDATA[
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
]]></artwork></figure> <table anchor="fig_RPIflagday2">
</t> <name>DODAG Configuration Option Flag to Indicate the RPI Flag Day</name>
<t> <thead>
<tr>
<th align="center">Bit number</th>
<th align="center">Description</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">3</td>
<td align="center">RPI 0x23 enable</td>
<td align="center">This document</td>
</tr>
</tbody>
</table>
<t>
In the case of reboot, the node (6LN or 6LR) does not remember the In the case of reboot, the node (6LN or 6LR) does not remember the
RPI Option Type (i.e., whether or not the flag is set), so the nod e will not trigger DIO RPI Option Type (i.e., whether or not the flag is set), so the nod e will not trigger DIO
messages until a DIO message is received indicating the RPI messages until a DIO message is received that indicates the RPI
value to be used. The node will use the value 0x23 if the network supports this feature. value to be used. The node will use the value 0x23 if the network supports this feature.
</t> </t>
</section> </section>
</section> </section>
<section title="Updates to RFC6553: Indicating the new RPI Option Type <section numbered="true" toc="default">
."> <name>Updates to RFC 6553: Indicating the New RPI Option Type</name>
<t> <t>
This modification is required in order to be able to send, for example , This modification is required in order to be able to send, for example ,
IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node through Inter net (see <xref target="sm-Ral2i" />), IPv6 packets from a RPL-aware leaf to a RPL-unaware node through the I nternet (see <xref target="sm-Ral2i" format="default"/>)
without requiring IPv6-in-IPv6 encapsulation. without requiring IPv6-in-IPv6 encapsulation.
</t> </t>
<t> <t>
<xref target="RFC6553"/> (Section 6, Page 7) states as shown in <xref <xref target="RFC6553" section="6" sectionFormat="of" format="default"
target="fig_RPIOption" />, /> states, as shown in <xref target="fig_RPIOption" format="default"/>,
that in the Option Type field of the RPL Option, that in the Option Type field of the RPL Option,
the two high order bits must be set to '01' and the third bit is equal to '1'. the two high-order 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 The first two bits indicate that the IPv6 node must discard the packet
if it doesn't recognize the Option Type, if it doesn't recognize the Option Type,
and the third bit indicates that the Option Data may change in route. and the third bit indicates that the Option Data may change in route.
The remaining bits serve as the Option Type. The remaining bits serve as the Option Type.
</t> </t>
<t> <table anchor="fig_RPIOption">
<figure title="Option Type in RPL Option." anchor="fig_RPIOption" alig <name>Option Type in RPL Option</name>
n="center"> <thead>
<artwork> <![CDATA[ <tr>
+-------+-------------------+----------------+-----------+ <th rowspan="2" colspan="1" align="center">Hex Value</th>
| Hex | Binary Value | Description | Reference | <th rowspan="1" colspan="3" align="center">Binary Value</th>
+ Value +-------------------+ + + <th rowspan="2" colspan="1" align="center">Description</th>
| | act | chg | rest | | | <th rowspan="2" colspan="1" align="center">Reference</th>
+-------+-----+-----+-------+----------------+-----------+ </tr>
| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | <tr>
+-------+-----+-----+-------+----------------+-----------+ <th align="center">act</th>
]]></artwork></figure> <th align="center">chg</th>
</t> <th align="center">rest</th>
<t> </tr>
This document illustrates that it is not always possible to know for s </thead>
ure at the source that a packet will only travel within the RPL domain or may le <tbody>
ave it. <tr>
<td align="center">0x63</td>
<td align="center">01</td>
<td align="center">1</td>
<td align="center">00011</td>
<td align="center">RPL Option</td>
<td align="center"><xref target="RFC6553" format="default"/></td>
</tr>
</tbody>
</table>
<t>
This document illustrates that it is not always possible to know for s
ure at the source whether a packet will travel only within the RPL domain or whe
ther it will leave it.
</t><t> </t>
At the time <xref target="RFC6553"/> was published, leaking a Hop-by-H <t>
op header in the outer IPv6 header At the time <xref target="RFC6553" format="default"/> was published, l
chain could potentially impact core routers in the internet. So at tha eaking a Hop-by-Hop Options header in the outer IPv6 header
t time, it was decided to encapsulate chain could potentially impact core routers in the Internet. So at tha
t time, it was decided to encapsulate
any packet with a RPL Option using IPv6-in-IPv6 in all cases where it was unclear whether the packet would any packet with a RPL Option using IPv6-in-IPv6 in all cases where it was unclear whether the packet would
remain within the RPL domain. In the exception case where a packet wou ld still leak, the Option Type would remain within the RPL domain. In the exception case where a packet wou ld still leak, the Option Type would
ensure that the first router in the Internet that does not recognize t he option would drop the packet and ensure that the first router in the Internet that does not recognize t he option would drop the packet and
protect the rest of the network. protect the rest of the network.
</t><t> </t>
Even with <xref target="RFC8138"/>, where the IPv6-in-IPv6 header is c <t>
ompressed, this approach yields extra bytes Even with <xref target="RFC8138" format="default"/>, where the IPv6-in
in a packet; this means consuming more energy, more bandwidth, incurri -IPv6 header is compressed, this approach yields extra bytes
ng higher chances of loss and possibly in a packet; this means consuming more energy and more bandwidth, incu
rring higher chances of loss, and possibly
causing a fragmentation at the 6LoWPAN level. This impacts the daily o peration of constrained devices for a case causing a fragmentation at the 6LoWPAN level. This impacts the daily o peration of constrained devices for a case
that generally does not happen and would not heavily impact the core anyway. that generally does not happen and would not heavily impact the core anyway.
</t><t> </t>
<t>
While intention was and remains that the Hop-by-Hop header with a RPL Option should be confined within the While the intention was and remains that the Hop-by-Hop Options header with a RPL Option should be confined within the
RPL domain, this specification modifies this behavior in order to redu ce the dependency on IPv6-in-IPv6 and RPL domain, this specification modifies this behavior in order to redu ce the dependency on IPv6-in-IPv6 and
protect the constrained devices. Section 4 of <xref target="RFC8200"/> clarifies the behaviour of routers in protect the constrained devices. <xref target="RFC8200" section="4" se ctionFormat="of" format="default"/> clarifies the behavior of routers in
the Internet as follows: "it is now expected that nodes along a packet 's delivery path only examine and process the Internet as follows: "it is now expected that nodes along a packet 's delivery path only examine and process
the Hop-by-Hop Options header if explicitly configured to do so". the Hop-by-Hop Options header if explicitly configured to do so."</t>
</t><t> <t>
When unclear about the travel of a packet, it becomes preferable for a source not to encapsulate, accepting When unclear about the travel of a packet, it becomes preferable for a source not to encapsulate, accepting
the fact that the packet may leave the RPL domain on its way to its de stination. In that event, the packet the fact that the packet may leave the RPL domain on its way to its de stination. In that event, the packet
should reach its destination and should not be discarded by the first node that does not recognize the RPL Option. should reach its destination and should not be discarded by the first node that does not recognize the RPL Option.
But with the current value of the Option Type, if a node in the Inter However, with the current value of the Option Type, if a node in the
net is configured to process the Hop-by-Hop Internet is configured to process the Hop-by-Hop Options
header, and if such node encounters an option with the first two bits header, and if such a node encounters an Option Type with the first t
set to 01 and conforms to <xref target="RFC8200"/>, wo bits set to 01 and the node conforms to <xref target="RFC8200" format="defaul
t"/>,
it will drop the packet. Host systems should do the same, irrespecti ve of the configuration. it will drop the packet. Host systems should do the same, irrespecti ve of the configuration.
</t> </t>
<t> <t>
Thus, this document updates the Option Type of the RPL Option <xref t Thus, this document updates the Option Type of the RPL Option <xref t
arget="RFC6553"/>, arget="RFC6553" format="default"/>,
naming it RPI Option Type for simplicity, naming it RPI Option Type for simplicity
to (<xref target="fig_RPIOption_new"/>): (<xref target="fig_RPIOption_new" format="default"/>):
the two high order bits MUST be set to '00' the two high order bits <bcp14>MUST</bcp14> be set to '00',
and the third bit is equal to '1'. and the third bit is equal to '1'.
The first two bits indicate that the IPv6 node MUST The first two bits indicate that the IPv6 node <bcp14>MUST</bcp14>
skip over this option and continue processing the header skip over this option and continue processing the header
(<xref target="RFC8200"/> Section 4.2) (<xref target="RFC8200" section="4.2" sectionFormat="comma" format="d efault"/>)
if it doesn't recognize the Option Type, if it doesn't recognize the Option Type,
and the third bit continues to be set to indicate that the Option and the third bit continues to be set to indicate that the Option
Data may change en route. The rightmost five bits remain at 0x3(00011 ). Data may change en route. The rightmost five bits remain at 0x3(00011 ).
This ensures that a packet that leaves the RPL domain of an LLN (or t hat This ensures that a packet that leaves the RPL domain of an LLN (or t hat
leaves the LLN entirely) will not be discarded when it contains the R PL Option. leaves the LLN entirely) will not be discarded when it contains the R PL Option.
</t> </t>
<t> <t>
With the new Option Type, if an IPv6 (intermediate) node (RPL-not-capa With the new Option Type, if an IPv6 (intermediate) node (RPL unaware)
ble) receives a packet with a receives a packet with a
RPL Option, it should ignore the Hop-by-Hop RPL Option RPL Option, it should ignore the Hop-by-Hop RPL Option
(skip over this option and continue processing the header). This is re levant, as it was mentioned previously, in the case that (skip over this option and continue processing the header). This is re levant, as it was mentioned previously, in the case that
there is a flow from RAL to Internet (see <xref target="sm-Ral2i" />). there is a flow from RAL to Internet (see <xref target="sm-Ral2i" form
</t> at="default"/>).
<t> </t>
This is a significant update to <xref target="RFC6553"/>. <t>
</t> This is a significant update to <xref target="RFC6553" format="defaul
<t> t"/>.
<figure title="Revised Option Type in RPL Option. (*)represents this d </t>
ocument" anchor="fig_RPIOption_new" align="center"> <table anchor="fig_RPIOption_new">
<artwork> <![CDATA[ <name>Revised Option Type in RPL Option</name>
+-------+-------------------+-------------+------------+ <thead>
| Hex | Binary Value | Description | Reference | <tr>
+ Value +-------------------+ + + <th rowspan="2" colspan="1" align="center">Hex Value</th>
| | act | chg | rest | | | <th rowspan="1" colspan="3" align="center">Binary Value</th>
+-------+-----+-----+-------+-------------+------------+ <th rowspan="2" colspan="1" align="center">Description</th>
| 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| <th rowspan="2" colspan="1" align="center">Reference</th>
+-------+-----+-----+-------+-------------+------------+ </tr>
]]></artwork></figure> <tr>
</t> <th align="center">act</th>
<t> <th align="center">chg</th>
Without the signaling described below, this change would otherwise c <th align="center">rest</th>
reate a lack of interoperation (flag day) for existing networks which are </tr>
</thead>
<tbody>
<tr>
<td align="center">0x23</td>
<td align="center">00</td>
<td align="center">1</td>
<td align="center">00011</td>
<td align="center">RPL Option</td>
<td align="center">This document</td>
</tr>
</tbody>
</table>
<t>
Without the signaling described below, this change would otherwise c
reate a lack of interoperation (flag day) for existing networks that are
currently using 0x63 as the RPI Option Type value. A move to 0x23 w ill not currently using 0x63 as the RPI Option Type value. A move to 0x23 w ill not
be understood by those networks. It is suggested that be understood by those networks. It is suggested that
RPL implementations accept both 0x63 and 0x23 when RPL implementations accept both 0x63 and 0x23 when
processing the header. processing the header.
</t> </t>
<t> <t>
When forwarding packets, implementations SHOULD use the same value o When forwarding packets, implementations <bcp14>SHOULD</bcp14> use t
f RPI Type he same value of RPI Type
as was received. This is required because the RPI Option Type does n ot change en route as was received. This is required because the RPI Option Type does n ot change en route
(<xref target="RFC8200"/> - Section 4.2). It allows the network to b e incrementally (<xref target="RFC8200" section="4.2" sectionFormat="comma" format=" default"/>). It allows the network to be incrementally
upgraded and allows the DODAG root to know which parts of the upgraded and allows the DODAG root to know which parts of the
network have been upgraded. network have been upgraded.
</t> </t>
<t> <t>
When originating new packets, When originating new packets,
implementations should have an option to determine which value to implementations should have an option to determine which value to
originate with, this option is controlled by the DIO Configuration o originate with. This option is controlled by the DODAG Configuration
ption (Section <xref target="update6550"/>). option (<xref target="update6550" format="default"/>).
</t> </t>
<!-- <!-- [auth]
A network which is switching from straight 6LoWPAN compression A network which is switching from straight 6LoWPAN compression
mechanism to those described in mechanism to those described in
<xref target="RFC8138" /> <xref target="RFC8138" />
will experience a flag day in the data compression anyway, and if will experience a flag day in the data compression anyway, and if
possible this change can be deployed at the same time. possible this change can be deployed at the same time.
</t--> </t-->
<t> <t>
The change of RPI Option Type from 0x63 to 0x23, makes all The change of RPI Option Type from 0x63 to 0x23 makes all nodes that a
<xref target="RFC8200"/> Section 4.2 compliant nodes tolerant of the R re compliant with
PL artifacts. There <xref target="RFC8200" section="4.2" sectionFormat="of" format="defaul
t"/> tolerant of the RPL artifacts. There
is no longer a need to remove the artifacts when is no longer a need to remove the artifacts when
sending traffic to the Internet. This change clarifies when sending traffic to the Internet. This change clarifies when
to use IPv6-in-IPv6 headers, and how to address them: to use IPv6-in-IPv6 headers and how to address them:
The Hop-by-Hop Options header containing the RPI MUST always the Hop-by-Hop Options header containing the RPI <bcp14>MUST</bcp14> a
lways
be added when 6LRs originate packets (without IPv6-in-IPv6 be added when 6LRs originate packets (without IPv6-in-IPv6
headers), and IPv6-in-IPv6 headers MUST always be added headers), and IPv6-in-IPv6 headers <bcp14>MUST</bcp14> always be added
when a 6LR finds that it needs to insert a Hop-by-Hop Options header when a 6LR finds that it needs to insert a Hop-by-Hop Options header
containing the RPL Option. The IPv6-in-IPv6 header is to containing the RPL Option. The IPv6-in-IPv6 header is to
be addressed to the be addressed to the
RPL root when on the way up, and to the end-host when on the way down. RPL root when on the way up, and to the end host when on the way down.
</t> </t>
<t> <t>
In the non-storing case, dealing with not-RPL aware leaf nodes In the Non-Storing case, dealing with RPL-unaware leaf nodes
is much easier as the 6LBR (DODAG root) has complete knowledge is much easier as the 6LBR (DODAG root) has complete knowledge
about the connectivity of all DODAG nodes, and all traffic flows about the connectivity of all DODAG nodes, and all traffic flows
through the root node. through the root node.
</t> </t>
<t> <t>
The 6LBR can recognize not-RPL aware leaf nodes because it will The 6LBR can recognize RPL-unaware 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. RPL-unaware node.
</t> </t>
<t> <t>
The non-storing mode case does not require the type change from The Non-Storing mode case does not require the Type change from
0x63 to 0x23, as the root can always create the right packet. 0x63 to 0x23, as the root can always create the right packet.
The type change does not adversely affect the non-storing case.(see < xref target="update6550"/>) The Type change does not adversely affect the Non-Storing case (see < xref target="update6550" format="default"/>).
</t> </t>
<!-- [auth] <t>
<!-- <t>
In general, any packet that leaves the RPL domain In general, any packet that leaves the RPL domain
of an LLN (or leaves the LLN entirely) will NOT be discarded, when it has the <xref target="RFC6553" /> RPL Option of an LLN (or leaves the LLN entirely) will NOT be discarded, when it has the <xref target="RFC6553" /> RPL Option
Header known as the RPI or <xref target="RFC6554" /> RH33 Extension He ader (S)RH3. Header known as the RPI or <xref target="RFC6554" /> RH33 Extension He ader (S)RH3.
Because of <xref target="RFC8200"/> the RPI Hop-by-Hop option Because of <xref target="RFC8200"/> the RPI Hop-by-Hop option
MAY be left in place even if the end host does not <bcp14>MAY</bcp14> be left in place even if the end host does not
understand it. understand it.
</t> </t>
--> -->
</section> </section>
<section numbered="true" toc="default">
<section title="Updates to RFC8138: Indicating the way to decompress wit <name>Updates to RFC 8138: Indicating the Way to Decompress with the New
h the new RPI Option Type."> RPI Option Type</name>
<t> <t>
This modification is required in order to be able to decompress the RP L Option This modification is required in order to be able to decompress the RP L Option
with the new Option Type of 0x23. with the new Option Type of 0x23.
</t> </t>
<t> <t>
RPI-6LoRH header provides a compressed form for the RPL RPI; see The RPI-6LoRH header provides a compressed form for the RPL RPI; see
<xref target="RFC8138"/>, Section 6. A node that is decompressing th <xref target="RFC8138" section="6" sectionFormat="comma" format="def
is header ault"/>. A node that is decompressing this header
MUST decompress using the RPI Option Type that is currently active: <bcp14>MUST</bcp14> decompress using the RPI Option Type that is cur
that rently active, that
is, a choice between 0x23 (new) and 0x63 (old).  The node will know is, a choice between 0x23 (new) and 0x63 (old). The node will know w
which to hich to
use based upon the presence of the flag in the DODAG Configuration o ption defined in use based upon the presence of the flag in the DODAG Configuration o ption defined in
<xref target="update6550" />. E.g. If the network is in 0x23 mode (b y DIO option), <xref target="update6550" format="default"/>. For example, if the ne twork is in 0x23 mode (by DIO option),
then it should be decompressed to 0x23. then it should be decompressed to 0x23.
</t> </t>
<t> <t>
<xref target="RFC8138" /> section 7 documents how to compress <xref target="RFC8138" section="7" sectionFormat="of" format="default" /> documents how to compress
the IPv6-in-IPv6 header. the IPv6-in-IPv6 header.
</t> </t>
<t> <t>
There are potential significant advantages to having a single There are potential significant advantages to having a single
code path that always processes IPv6-in-IPv6 headers with no code path that always processes IPv6-in-IPv6 headers with no
conditional branches. conditional branches.
</t> </t>
<t> <t>
In Storing Mode, the scenarios where the flow goes from RAL to RUL a In Storing mode, the scenarios where the flow goes from RAL to RUL a
nd RUL nd RUL
to RUL include compression of the IPv6-in-IPv6 and RPI headers. The to RUL include compression of the IPv6-in-IPv6 and RPI headers. Th
use e
of the IPv6-in-IPv6 header is MANDATORY in this case, and IPv6-in-IPv6 header <bcp14>MUST</bcp14> be used in this case, and
it SHOULD be compressed with <xref target="RFC8138"/> section 7. it <bcp14>SHOULD</bcp14> be compressed as specified in
<xref target="rtghc"/> <xref target="RFC8138" section="7" sectionFormat="comma" format="def
ault"/>.
<xref target="rtghc" format="default"/>
illustrates the case in Storing mode where the packet is received f rom the Internet, then the illustrates the case in Storing mode where the packet is received f rom the Internet, then the
root encapsulates the packet to insert the RPI. In that example, 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 encapsulated to the 6LR that is the parent and last hop to the
final destination. final destination.
</t> </t>
<figure title="RPI Inserted by the Root in Storing Mode" anchor="rtghc"> <figure anchor="rtghc">
<artwork><![CDATA[ <name>RPI Inserted by the Root in Storing Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| 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
]]></artwork></figure> ]]></artwork>
</figure>
<t> <t>
In <xref target="rtghc"/>, the source of the IPv6-in-IPv6 encapsulatio In <xref target="rtghc" format="default"/>, the source of the IPv6-in-
n is IPv6 encapsulation is
the Root, so it is elided in the IP-in-IP 6LoRH. The destination is the root, so it is elided in the IP-in-IP 6LoRH. The destination is
the parent 6LR of the destination of the inner packet so it cannot be the 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 first elided. It is placed as the single entry in a Source Route Header 6LoR
6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In that H (SRH-6LoRH) as the first
example, the type is 1 so the 6LR address is compressed to 2 bytes. 6LoRH. There is a single entry so the SRH-6LoRH Size is zero. In that
It results that the total length of the SRH-6LoRH is 4 bytes. example, the Type is 1 so the 6LR address is compressed to two bytes.
Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the This results in the total length of the SRH-6LoRH being four bytes.
The RPI-6LoRH and then the IP-in-IP 6LoRH follow. When the
IP-in-IP 6LoRH is removed, all the router headers that precede it are IP-in-IP 6LoRH is removed, all the router headers that precede it are
also removed. also removed.
The Paging Dispatch <xref target="RFC8025"/> may also be removed if The Paging Dispatch <xref target="RFC8025" format="default"/> may also be removed if
there was no previous Page change to a Page other than 0 or 1, since there was no previous Page change to a Page other than 0 or 1, since
and in Page 1. The resulting packet to the destination is the inner and in Page 1. The resulting packet to the destination is the inner
packet compressed with <xref target="RFC6282"/>. packet compressed with <xref target="RFC6282" format="default"/>.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec_ref_topo" numbered="true" toc="default">
<name>Reference Topology</name>
<section title="Sample/reference topology"> <t>
<t>
A RPL network in general is composed of a 6LBR, A RPL network in general is composed of a 6LBR,
a Backbone Router (6BBR), a 6LR and a 6LN as a leaf logically or a Backbone Router (6BBR), a 6LR, and a 6LN as a leaf logically o
ganized in a DODAG structure. rganized in a DODAG structure.
</t> </t>
<t> <t>
<xref target="fig_CommonTopology"/> shows the reference RPL Topol <xref target="fig_CommonTopology" format="default"/> shows the re
ogy for this document. The ference RPL topology for this document. The
letters above the nodes are there so that nodes are labeled with letters so that
they may be referenced in subsequent sections. In the figure, they may be referenced in subsequent sections. In the figure,
6LR represents a full router node. 6LR represents a full router node.
The 6LN is a RPL aware router, or host (as a leaf). The 6LN is a RPL-aware router or host (as a leaf).
Additionally, for simplification purposes, Additionally, for simplification purposes,
it is supposed that the 6LBR has direct access to Internet and is the root of the DODAG, thus the 6BBR it is supposed that the 6LBR has direct access to Internet and is the root of the DODAG, thus the 6BBR
is not present in the figure. is not present in the figure.
</t> </t>
<t>
<t> The 6LN leaves marked as RAL (F, H, and I) are RPL nodes with no chi
The 6LN leaves (RAL) ldren hosts.
marked as (F, H and I) are RPL nodes with no children hosts. </t>
</t> <t>
<t>
The leaves marked as RUL (G and J) are The leaves marked as RUL (G and J) are
devices that do not speak RPL at all (not-RPL-aware), devices that do not speak RPL at all (RPL unaware),
but use Router-Advertisements, 6LowPAN DAR/DAC and but use Router Advertisements, 6LoWPAN Duplicate Address Request and
6LoWPAN ND only to participate in the network <xref target="RFC8505" Duplicate Address Confirmation (DAR/DAC), and
/>. 6LoWPAN Neighbor Discovery (ND) only to participate in the network <
In the document these leaves (G and J) are also referred to as xref target="RFC8505" format="default"/>.
In the document, these leaves (G and J) are also referred to as
a RUL. a RUL.
</t> </t>
<t> <t>
The 6LBR ("A") in the figure is the root of the Global DODAG. The 6LBR (A) in the figure is the root of the Global DODAG.
</t> </t>
<t> <figure anchor="fig_CommonTopology">
<figure title="A reference RPL Topology." anchor="fig_CommonTopolog <name>A Reference RPL Topology</name>
y" align="center"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+------------+ +------------+
| INTERNET ----------+ | INTERNET ----------+
| | | | | |
+------------+ | +------------+ |
| |
| |
| |
A | A |
+-------+ +-------+
|6LBR | |6LBR |
skipping to change at line 790 skipping to change at line 792
| | | | | | | | | |
| | +--+ | | | | +--+ | |
| | | | | | | | | |
| | | | | | | | | |
| | | I | J | | | | I | J |
F | | G | H | | F | | G | H | |
+-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+
| RAL | | RUL | | RAL | | RAL | | RUL | | RAL | | RUL | | RAL | | RAL | | RUL |
| 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN |
+-------+ +-------+ +------+ +-------+ +-------+ +-------+ +-------+ +------+ +-------+ +-------+
]]> ]]></artwork>
</artwork></figure> </figure>
</t> </section>
<section anchor="sec_use_cases" numbered="true" toc="default">
</section> <name>Use Cases</name>
<t>
<section title="Use cases"> In the data plane, a combination of RFC 6553, RFC 6554, and
<t>
In the data plane a combination of RFC6553, RFC6554 and
IPv6-in-IPv6 encapsulation are going to be analyzed for a number of IPv6-in-IPv6 encapsulation are going to be analyzed for a number of
representative traffic flows. representative traffic flows.
</t> </t>
<t> <t>
The use cases describe the communication in the following cases: The use cases describe the communication in the following cases:
- Between RPL-aware-nodes with the root (6LBR) </t>
- Between RPL-aware-nodes with the Internet <ul>
- Between RUL nodes within the LLN (e.g. see <xref target="sm-nRal2roo <li>Between RPL-aware nodes with the root (6LBR)</li>
t" />) <li>Between RPL-aware nodes with the Internet</li>
- Inside of the LLN when the final destination address resides outside <li>Between RUL nodes within the LLN (e.g., see <xref target="sm-nRal2
of the LLN (e.g. see <xref target="sm-nRal2i" />). root" format="default"/>)</li>
</t> <li>Inside of the LLN when the final destination address resides outsi
<t> de
of the LLN (e.g., see <xref target="sm-nRal2i" format="default"/>)</
li>
</ul>
<t>
The use cases are as follows: The use cases are as follows:
</t> </t>
<t> <ul empty="true" spacing="normal">
Interaction between Leaf and Root: <li><t>
</t> Interaction between leaf and root:
<t> </t>
<list> <ul empty="true" spacing="normal">
<t> <li>
RAL to root RAL to root
</t> </li>
<t> <li>
root to RAL root to RAL
</t> </li>
<t> <li>
RUL to root RUL to root
</t> </li>
<t> <li>
root to RUL root to RUL
</t> </li>
</list> </ul></li>
</t> <li><t>
<t> Interaction between leaf and Internet:
Interaction between Leaf and Internet: </t>
</t> <ul empty="true" spacing="normal">
<t> <li>
<list>
<t>
RAL to Internet RAL to Internet
</t> </li>
<t> <li>
Internet to RAL Internet to RAL
</t> </li>
<t> <li>
RUL to Internet RUL to Internet
</t> </li>
<t> <li>
Internet to RUL Internet to RUL
</t> </li>
</list> </ul></li>
</t> <li> <t>
<t>
Interaction between leaves: Interaction between leaves:
</t> </t>
<t> <ul empty="true" spacing="normal">
<list> <li>
<t>
RAL to RAL RAL to RAL
</t> </li>
<t> <li>
RAL to RUL RAL to RUL
</t> </li>
<t> <li>
RUL to RAL RUL to RAL
</t> </li>
<t> <li>
RUL to RUL RUL to RUL
</t> </li>
</list> </ul></li>
</t> </ul>
<t> <t>
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 inserted or removed on the fly inside an IPv6 packet that is
being routed. being routed.
This is a fundamental precept of the IPv6 architecture as This is a fundamental precept of the IPv6 architecture as
outlined in <xref target="RFC8200" />. outlined in <xref target="RFC8200" format="default"/>.
</t> </t>
<!-- <!-- [auth]
<t> <t>
However, unlike <xref target="RFC6553" />, the Hop-by-Hop Option However, unlike <xref target="RFC6553" />, the Hop-by-Hop Option
Header used for the RPI artifact has the first two bits set to Header used for the RPI artifact has the first two bits set to
'00'. '00'.
This means that the RPI artifact will be ignored when received by a host This means that the RPI artifact will be ignored when received by a host
or router that does not understand that option or router that does not understand that option
( Section 4.2 <xref target="RFC8200" />). ( Section 4.2 <xref target="RFC8200" />).
</t> </t>
<t> <t>
This means that when the no-drop RPI option code 0x23 is used, a This means that when the no-drop RPI option code 0x23 is used, a
skipping to change at line 903 skipping to change at line 901
</t> </t>
<t> <t>
NOTE: No clear attack has been described when the RPI information is released to the Internet. NOTE: No clear attack has been described when the RPI information is released to the Internet.
At a minimum, it is clear that the RPI option would waste some netwo rk bandwidth when it escapes. At a minimum, it is clear that the RPI option would waste some netwo rk bandwidth when it escapes.
This is traded off against the savings in the LLN by not having to e ncapsulate the packet This is traded off against the savings in the LLN by not having to e ncapsulate the packet
in order to remove the artifact. Please check the Security Considera tions sections in order to remove the artifact. Please check the Security Considera tions sections
<xref target="Security"/> for further details. <xref target="Security"/> for further details.
</t> </t>
--> -->
<t> <t>
As the rank information in the RPI artifact is changed at each As the Rank information in the RPI artifact is changed at each
hop, it will typically be zero when it arrives at the DODAG hop, it will typically be zero when it arrives at the DODAG
root. The DODAG root MUST force it to zero when passing the root. The DODAG root <bcp14>MUST</bcp14> force it to zero when pass ing the
packet out to the Internet. The Internet will therefore not see packet out to the Internet. The Internet will therefore not see
any SenderRank information. any SenderRank information.
</t> </t>
<t> <t>
Despite being legal to leave the RPI artifact in place, Despite being legal to leave the RPI artifact in place,
an intermediate router that needs to add an extension header an intermediate router that needs to add an extension header
(e.g. RH3 or RPL Option) MUST still encapsulate the packet in an (e.g., RH3 or RPL Option) <bcp14>MUST</bcp14> still encapsulate the packet in an
(additional) outer IP header. The new header is placed after (additional) outer IP header. The new header is placed after
this new outer IP header. this new outer IP header.
</t> </t>
<t> <t>
A corollary is that an A corollary is that an
intermediate router can remove an RH3 or RPL Option only intermediate router can remove an RH3 or RPL Option only
if it is placed in an encapsulating IPv6 if it is placed in an encapsulating IPv6
Header that is addressed TO this intermediate router. header that is addressed <em>to</em> this intermediate router.
When doing the above, the whole encapsulating header must be When doing the above, the whole encapsulating header must be
removed. (A replacement may be added). This sometimes can removed. (A replacement may be added.)
result in outer IP headers being addressed to the next hop </t>
router using link-local address. <t>
</t>
<t>
Both the RPL Option and the RH3 headers may be modified in very spec ific ways Both the RPL Option and the RH3 headers may be modified in very spec ific ways
by routers on the path of the packet without the need to add and by routers on the path of the packet without the need to add and
remove an encapsulating header. Both headers were designed with remove an encapsulating header. Both headers were designed with
this modification in this modification in
mind, and both the RPL RH3 and the RPL Option are marked mutable mind, and both the RPL RH3 and the RPL Option are marked mutable
but recoverable: so an IPsec AH security header can be applied but recoverable: so an IPsec Authentication Header (AH) can be appli
across these headers, but it can not secure the values which mutate. ed
</t> across these headers, but it cannot secure the values that mutate.
</t>
<t> <t>
The RPI MUST be present in every single RPL data packet. The RPI <bcp14>MUST</bcp14> be present in every single RPL data pack
</t> et.
</t>
<t> <t>
Prior to <xref target="RFC8138" />, there was significant Prior to <xref target="RFC8138" format="default"/>, there was signif
interest in creating an exception to this rule and removing the RPI icant
for downward flows in non-storing interest in creating an exception to this rule and removing the RPI
for Downward flows in Non-Storing
mode. This exception covered a very small number of cases, and mode. This exception covered a very small number of cases, and
caused significant interoperability challenges while adding caused significant interoperability challenges while adding
significant interest in the code and tests. The ability to compress significant interest in the code and tests. The ability to compress
the RPI down to three bytes or less removes much of the pressure the RPI down to three bytes or less removes much of the pressure
to optimize this any further <xref target="I-D.ietf-anima-autonomic- to optimize this any further.
control-plane" />. </t>
</t> <t>
<t> Throughout the following subsections, the examples are described in
Throughout the following subsections, the examples are described in more detail in the first subsections,
more details in the first subsections,
and more concisely in the later ones. and more concisely in the later ones.
</t> </t>
<t>
<t> The use cases are delineated based on the following IPV6 and RPL m
The uses cases are delineated based on the following IPV6 and RPL andates:
mandates: </t>
</t> <ul empty="true" spacing="normal">
<t> <li>
<list> <t>The RPI has to be in every packet that traverses the LLN.</t>
<t> <ul spacing="normal">
The RPI has to be in every packet that traverses the LLN. <li>
</t> Because of the above requirement, packets from the Internet have
<t> to be encapsulated.
- Because of the above requirement, packets from the Internet h </li>
ave to be encapsulated. <li>
</t> A header cannot be inserted or removed on the fly inside an IPv6
<t> packet that is being routed.
- A Header cannot be inserted or removed on the fly inside an IP </li>
v6 packet that is being routed. <li>
</t> Extension headers may not be added or removed except by the send
<t> er or the receiver.
- Extension headers may not be added or removed except by the se </li>
nder or the receiver. <li>
</t> RPI and RH3 headers may be modified by routers on the path of th
<t> e packet without the need to add and remove an encapsulating header.
- RPI and RH3 headers may be modified by routers on the path of </li>
the packet without the need to add and remove an encapsulating header. <li>
</t> An RH3 or RPL Option can only be removed by an intermediate rout
<t> er if it is placed in an encapsulating IPv6 header, which is addressed to the in
- an RH3 or RPL Option can only be removed by an intermediate ro termediate router.
uter if it is placed in an encapsulating IPv6 Header, which is addressed to the </li>
intermediate router. <li>
</t> The Non-Storing mode requires downstream encapsulation by the ro
<t> ot for RH3.
- Non-storing mode requires downstream encapsulation by root for </li>
RH3. </ul>
</t> </li>
</list> </ul>
</t> <t>
The use cases are delineated based on the following assumptions:
<t> </t>
The uses cases are delineated based on the following assumptions: <ul empty="true" spacing="normal">
</t> <li>
<t> <t>This document assumes that the LLN is using the no-drop RPI Op
<list> tion Type (0x23).</t>
<t> <ul spacing="normal">
This document assumes that the LLN is using the no-drop RPI Optio <li>
n Type (0x23). Each IPv6 node (including Internet routers) obeys <xref target="
</t> RFC8200" format="default"/>, so that the 0x23 RPI Option Type can be safely inse
<t> rted.
- Each IPv6 node (including Internet routers) obeys <xref target </li>
="RFC8200"/>, so that 0x23 RPI Option Type can be safely inserted. <li>
</t> All 6LRs obey <xref target="RFC8200" format="default"/>.
<t> </li>
- All 6LRs obey <xref target="RFC8200"/>. <li>
</t> The RPI is ignored at the IPv6 destination (dst) node (RUL).
<t> </li>
- The RPI is ignored at the IPv6 dst node (RUL). <li>
</t> In the use cases, we assume that the RAL supports IP-in-IP encap
<t> sulation.
- In the uses cases, we assume that the RAL supports IP-in-IP en </li>
capsulation. <li>
</t> In the use cases, we don't assume that the RUL supports IP-in-IP
<t> encapsulation.
- In the uses cases, we don't assume that the RUL supports IP-in </li>
-IP encapsulation. <li>
</t> For traffic leaving a RUL, if the RUL adds an opaque RPI, then t
<t> he 6LR as a RPL Border Router <bcp14>SHOULD</bcp14> rewrite
- For traffic leaving a RUL, if the RUL adds an opaque RPI then
the 6LR as a RPL border router SHOULD rewrite
the RPI to indicate the selected Instance and set the flags. the RPI to indicate the selected Instance and set the flags.
</t> </li>
<t> <li>
- The description for RALs applies to RAN in general. The description for RALs applies to RAN in general.
</t> </li>
<t> <li>
- Non-constrained uses of RPL are not in scope of this document. Unconstrained uses of RPL are not in scope of this document.
</t> </li>
<t> <li>
- Compression is based on <xref target="RFC8138"/>. Compression is based on <xref target="RFC8138" format="default"/>
</t> .
<t> </li>
- The flow label <xref target="RFC6437"/> is not needed in RPL. <li>
</t> The flow label <xref target="RFC6437" format="default"/> is not n
</list> eeded in RPL.
</t> </li>
</section> </ul>
</li>
<section title="Storing mode"> </ul>
</section>
<t> <section anchor="sec_sm" numbered="true" toc="default">
In storing mode (SM) (fully stateful), the sender can determine <name>Storing Mode</name>
if <t>
In Storing mode (SM) (fully stateful), the sender can determine
if
the destination is inside the LLN by the destination is inside the LLN by
looking if the destination address is matched by the DIO's Prefix In formation Option (PIO) option. looking if the destination address is matched by the DIO's Prefix In formation Option (PIO) option.
</t> </t>
<t> <t>
The following table (<xref target="fig_EncStoMode"/>) itemizes which <xref target="fig_EncStoMode" format="default"/> itemizes which head
headers are needed in each of the following scenarios. ers are needed in each of the following scenarios.
It indicates whether an IPv6-in-IPv6 header must be added and what d It indicates whether an IPv6-in-IPv6 header must be added and to whi
estination it must be addressed to: ch destination it must be addressed:
(1) the final destination (the RAL node that is the target (tgt)), </t>
(2) the "root", <ol>
or (3) the 6LR parent of a RUL. <li> the final destination (the RAL node that is the target (tgt)),</
</t> li>
<t> <li> the "root", or </li>
<li>the 6LR parent of a RUL.</li>
</ol>
<t>
In cases where no IPv6-in-IPv6 header is needed, the column states " No", and the destination is N/A (Not Applicable). In cases where no IPv6-in-IPv6 header is needed, the column states " No", and the destination is N/A (Not Applicable).
If the IPv6-in-IPv6 header is needed, the column shows "must". If the IPv6-in-IPv6 header is needed, the column shows "must".
</t> </t>
<t> <t>
In all cases, the RPI is needed, since it identifies In all cases, the RPI is needed, since it identifies
inconsistencies (loops) in the routing topology. inconsistencies (loops) in the routing topology.
In general, the RH3 is not needed because it is not used in storing In general, the RH3 is not needed because it is not used in Storing
mode. However, there is one scenario (from the root to the RUL in SM) mode. However, there is one scenario (from the root to the RUL in SM)
where the RH3 can be used to point at the RUL (<xref target="Storing where the RH3 can be used to point at the RUL (<xref target="Storing
-root2notrplnoIPIP"/>). -root2notrplnoIPIP" format="default"/>).
</t> </t>
<t> <t>
The leaf can be a router 6LR or a host, both indicated as 6LN. The r oot refers to the 6LBR The leaf can be a router 6LR or a host, both indicated as 6LN. The r oot refers to the 6LBR
(see <xref target="fig_CommonTopology" />). (see <xref target="fig_CommonTopology" format="default"/>).
</t> </t>
<t> <table anchor="fig_EncStoMode">
<figure title="Table of IPv6-in-IPv6 encapsulation in Storing mode." anch <name>IPv6-in-IPv6 Encapsulation in Storing Mode</name>
or="fig_EncStoMode" align="center"> <thead>
<artwork><![CDATA[ <tr>
+---------------------+--------------+------------+----------------+ <th align="center">Interaction between</th>
| Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst| <th align="center">Use Case</th>
+---------------------+--------------+------------+----------------+ <th align="center">IPv6-in-IPv6</th>
| | RAL to root | No | N/A | <th align="center">IPv6-in-IPv6 dst</th>
+ +--------------+------------+----------------+ </tr>
| Leaf - Root | root to RAL | No | N/A | </thead>
+ +--------------+------------+----------------+ <tbody>
| | root to RUL | must | 6LR | <tr>
+ +--------------+------------+----------------+ <th align="center" rowspan="4">Leaf - Root</th>
| | RUL to root | must | root | <td align="center">RAL to root</td>
+---------------------+--------------+------------+----------------+ <td align="center">No</td>
| | RAL to Int | may | root | <td align="center">N/A</td>
+ +--------------+------------+----------------+ </tr>
| Leaf - Internet | Int to RAL | must | RAL (tgt) | <tr>
+ +--------------+------------+----------------+ <td align="center">root to RAL</td>
| | RUL to Int | must | root | <td align="center">No</td>
+ +--------------+------------+----------------+ <td align="center">N/A</td>
| | Int to RUL | must | 6LR | </tr>
+---------------------+--------------+------------+----------------+ <tr>
| | RAL to RAL | No | N/A | <td align="center">root to RUL</td>
| Leaf - Leaf +--------------+------------+----------------+ <td align="center">must</td>
| | RAL to RUL | No(up) | N/A | <td align="center">6LR</td>
| + +------------+----------------+ </tr>
| | | must(down) | 6LR | <tr>
| +--------------+------------+----------------+ <td align="center">RUL to root</td>
| | RUL to RAL | must(up) | root | <td align="center">must</td>
| | +------------+----------------+ <td align="center">root</td>
| | | must(down) | RAL | </tr>
| +--------------+------------+----------------+ <tr>
| | RUL to RUL | must(up) | root | <th align="center" rowspan="4">Leaf - Internet</th>
| | +------------+----------------+ <td align="center">RAL to Int</td>
| | | must(down) | 6LR | <td align="center">may</td>
|---------------------+--------------+------------+----------------+ <td align="center">root</td>
]]></artwork></figure> </tr>
</t> <tr>
<section title="Storing Mode: Interaction between Leaf and Root"> <td align="center">Int to RAL</td>
<td align="center">must</td>
<t> <td align="center">RAL (tgt)</td>
In this section is described the communication flow </tr>
in storing mode (SM) between, <tr>
</t> <td align="center">RUL to Int</td>
<t> <td align="center">must</td>
<list> <td align="center">root</td>
<t> </tr>
<tr>
<td align="center">Int to RUL</td>
<td align="center">must</td>
<td align="center">6LR</td>
</tr>
<tr>
<th align="center" rowspan="7">Leaf - Leaf</th>
<td align="center">RAL to RAL</td>
<td align="center">No</td>
<td align="center">N/A</td>
</tr>
<tr>
<td align="center" rowspan="2">RAL to RUL</td>
<td align="center">No(up)</td>
<td align="center">N/A</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">6LR</td>
</tr>
<tr>
<td align="center" rowspan="2">RUL to RAL</td>
<td align="center">must(up)</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">RAL</td>
</tr>
<tr>
<td align="center" rowspan="2">RUL to RUL</td>
<td align="center">must(up)</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">6LR</td>
</tr>
</tbody>
</table>
<section numbered="true" toc="default">
<name>Storing Mode: Interaction between Leaf and Root</name>
<t>
This section describes the communication flow
in Storing mode (SM) between the following:
</t>
<ul empty="true" spacing="normal">
<li>
RAL to root RAL to root
</t> </li>
<t> <li>
root to RAL root to RAL
</t> </li>
<t> <li>
RUL to root RUL to root
</t> </li>
<t> <li>
root to RUL root to RUL
</t> </li>
</list> </ul>
</t> <section numbered="true" toc="default">
<!-- 5.1. Example of Flow from RAL to root !--> <name>SM: Example of Flow from RAL to Root</name>
<section title="SM: Example of Flow from RAL to Root"> <t>
In Storing mode, RPI <xref target="RFC6553" format="defa
<t> ult"/> is used
In storing mode, RFC 6553 (RPI) is used to send the RPLInstanceID and Rank
to send RPL Information instanceID and rank
information. information.
</t> </t>
<t> <t>
In this case the flow comprises: In this case, the flow comprises:
</t> </t>
<t> <t>
RAL (6LN) --> 6LR_i --> root(6LBR) RAL (6LN) --&gt; 6LR_i --&gt; root (6LBR)
</t> </t>
<t> <t>
For example, a communication flow could be: Node F (6LN) For example, a communication flow could be:
--> Node D (6LR_i) --> Node B (6LR_i)--> Node A root(6LBR) Node F (6LN) --&gt; Node D (6LR_i) --&gt; Node B (6LR_i) --&gt; Node A root (6LB
</t> R)
<t> </t>
<t>
The RAL (Node F) inserts the RPI, and sends the The RAL (Node F) inserts the RPI, and sends the
packet to 6LR (Node D) which decrements the rank in t he RPI and packet to the 6LR (Node D), which decrements the Rank in the RPI and
sends the packet up. When the packet arrives at sends the packet up. When the packet arrives at
6LBR (Node A), the RPI is removed and the packet is the 6LBR (Node A), the RPI is removed and the packet is
processed. processed.
</t> </t>
<t> <t>
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
</t> </t>
<t> The RPI can be removed by the 6LBR
<t> The RPI can be removed by the 6LBR
because the packet is addressed to the 6LBR. The because the packet is addressed to the 6LBR. The
RAL must know that it is communicating with the 6LBR RAL must know that it is communicating with the 6LBR
to make use of this scenario. to make use of this scenario.
The RAL can know the address of the 6LBR because it The RAL can know the address of the 6LBR because it
knows the address of the root via the DODAGID in the knows the address of the root via the DODAGID in the
DIO messages. DIO messages.
</t> </t>
<t> <t>
The <xref target="Storing-summary-headers"/> summarizes <xref target="Storing-summary-headers" format="default"
what headers are needed for this use case. /> summarizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-summary-headers">
<figure title="SM: Summary of the use of headers from R <name>SM: Summary of the Use of Headers from RAL to Root</name>
AL to root" anchor="Storing-summary-headers" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+-----+-------+------+ <th align="center">Header</th>
| Header | RAL | 6LR_i | 6LBR | <th align="center">RAL src</th>
| | src | | dst | <th align="center">6LR_i</th>
+-----------+-----+-------+------+ <th align="center">6LBR dst</th>
| Added | RPI | -- | -- | </tr>
| headers | | | | </thead>
+-----------+-----+-------+------+ <tbody>
| Modified | -- | RPI | -- | <tr>
| headers | | | | <th align="center">Added headers</th>
+-----------+-----+-------+------+ <td align="center">RPI</td>
| Removed | -- | -- | RPI | <td align="center">--</td>
| headers | | | | <td align="center">--</td>
+-----------+-----+-------+------+ </tr>
| Untouched | -- | -- | -- | <tr>
| headers | | | | <th align="center">Modified headers</th>
+-----------+-----+-------+------+ <td align="center">--</td>
]]></artwork></figure> <td align="center">RPI</td>
</t> <td align="center">--</td>
</section> </tr>
<tr>
<!-- section 7.2. !--> <th align="center">Removed headers</th>
<td align="center">--</td>
<section title="SM: Example of Flow from Root to RAL" anchor="Sto <td align="center">--</td>
ring-root2ral"> <td align="center">RPI</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<t> <section anchor="Storing-root2ral" numbered="true" toc="default">
In this case the flow comprises: <name>SM: Example of Flow from Root to RAL</name>
</t> <t>
<t> In this case, the flow comprises:
</t>
<t>
root (6LBR) --> 6LR_i --> RAL (6LN) root (6LBR) --&gt; 6LR_i --&gt; RAL (6LN)
</t> </t>
<t> <t>
For example, a communication flow could be: Node A root( For example, a communication flow could be:
6LBR) --> Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN) Node A root (6LBR) --&gt; Node B (6LR_i) --&gt; Node D (6LR_i) --&gt; Node F (6L
</t> N)
<t> </t>
In this case the 6LBR inserts RPI and <t>
sends the packet down, the 6LR is going to In this case, the 6LBR inserts RPI and
increment the rank in RPI (it examines the sends the packet down. The 6LR
increments the Rank in the RPI (it examines the
RPLInstanceID to identify the right forwarding RPLInstanceID to identify the right forwarding
table), table).
the packet The packet
is processed in the RAL and the RPI removed. is processed in the RAL, and the RPI is removed.
</t> </t>
<t> <t>
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
</t> </t>
<t> <t>
The <xref target="Storing-root2leaf"/> summarizes what h <xref target="Storing-root2leaf" format="default"/> summ
eaders are needed for this use case. arizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-root2leaf">
<figure title="SM: Summary of the use of headers from roo <name>SM: Summary of the Use of Headers from Root to RAL</name>
t to RAL" anchor="Storing-root2leaf" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+------+-------+-----+ <th align="center">Header</th>
| Header | 6LBR | 6LR_i | RAL | <th align="center">6LBR src</th>
| | src | | dst | <th align="center">6LR_i</th>
+-----------+------+-------+-----+ <th align="center">RAL dst</th>
| Added | RPI | -- | -- | </tr>
| headers | | | | </thead>
+-----------+------+-------+-----+ <tbody>
| Modified | -- | RPI | -- | <tr>
| headers | | | | <th align="center">Added headers</th>
+-----------+------+-------+-----+ <td align="center">RPI</td>
| Removed | -- | -- | RPI | <td align="center">--</td>
| headers | | | | <td align="center">--</td>
+-----------+------+-------+-----+ </tr>
| Untouched | -- | -- | -- | <tr>
| headers | | | | <th align="center">Modified headers</th>
+-----------+------+-------+-----+ <td align="center">--</td>
]]></artwork></figure> <td align="center">RPI</td>
</t> <td align="center">--</td>
</section> </tr>
<tr>
<!-- section 7.3. !--> <th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section title="SM: Example of Flow from Root to RUL"> <section numbered="true" toc="default">
<t> <name>SM: Example of Flow from Root to RUL</name>
In this case the flow comprises: <t>
</t> In this case, the flow comprises:
<t> </t>
root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) <t>
</t> root (6LBR) --&gt; 6LR_i --&gt; RUL (IPv6 dst no
<t> de)
For example, a communication flow could be: Node A (6LBR </t>
) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL) <t>
</t> For example, a communication flow could be:
<t> Node A (6LBR) --&gt; Node B (6LR_i) --&gt; Node E (6LR_n) --&gt; Node G (RUL)
</t>
<t>
6LR_i (Node B) represents the intermediate routers fro m the source (6LBR) to the destination (RUL), 6LR_i (Node B) represents the intermediate routers fro m the source (6LBR) to the destination (RUL),
1 &lt;= i &lt;= n, where n is the total number of rout and 1 &lt;= i &lt;= n, where n is the total number of
ers (6LR) routers (6LR)
that the packet goes through from the 6LBR (Node A) to that the packet goes through, from the 6LBR (Node A) t
the RUL (Node G). o the RUL (Node G).
</t> </t>
<t> <t>
The 6LBR will encapsulate the packet in an IPv6-in-IPv6 The 6LBR will encapsulate the packet in an IPv6-in-IPv6
header, and prepend an RPI. The IPv6-in-IPv6 header and prepend an RPI. The IPv6-in-IPv6
header is addressed to the 6LR parent of the RUL (6LR_n) . header is addressed to the 6LR parent of the RUL (6LR_n) .
The 6LR parent of the RUL removes the header and sends t he packet to the RUL. The 6LR parent of the RUL removes the header and sends t he packet to the RUL.
</t> </t>
<t> <t>
The <xref target="Storing-root2notrpl"/> summarizes what <xref target="Storing-root2notrpl" format="default"/> su
headers are needed for this use case. mmarizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-root2notrpl">
<figure title="SM: Summary of the use of headers from roo <name>SM: Summary of the Use of Headers from Root to RUL</name>
t to RUL" anchor="Storing-root2notrpl" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+---------+---------+---------+-----+ <th align="center">Header</th>
| Header | 6LBR | 6LR_i | 6LR_n | RUL | <th align="center">6LBR src</th>
| | src | | | dst | <th align="center">6LR_i</th>
+-----------+---------+---------+---------+-----+ <th align="center">6LR_n</th>
| Added | IP6-IP6 | -- | -- | -- | <th align="center">RUL dst</th>
| headers | RPI | | | | </tr>
+-----------+---------+---------+---------+-----+ </thead>
| Modified | -- | | -- | -- | <tbody>
| headers | | RPI | | | <tr>
+-----------+---------+---------+---------+-----+ <th align="center">Added headers</th>
| Removed | -- | -- | IP6-IP6 | -- | <td align="center">IP6-IP6 (RPI)</td>
| headers | | | RPI | | <td align="center">--</td>
+-----------+---------+---------+---------+-----+ <td align="center">--</td>
| Untouched | -- | IP6-IP6 | -- | -- | <td align="center">--</td>
| headers | | | | | </tr>
+-----------+---------+---------+---------+-----+ <tr>
]]></artwork></figure> <th align="center">Modified headers</th>
</t> <td align="center">--</td>
<t> <td align="center">RPI</td>
IP-in-IP encapsulation may be avoided for Root to RUL com <td align="center">--</td>
munication. <td align="center">--</td>
In SM, it can be replaced by a loose RH3 header that indi </tr>
cates the RUL, <tr>
in which case the packet is routed to the 6LR as a normal <th align="center">Removed headers</th>
SM operation, <td align="center">--</td>
then the 6LR forwards to the RUL based on the RH3, and th <td align="center">--</td>
e RUL ignores <td align="center">IP6-IP6 (RPI)</td>
both the consumed RH3 and the RPI, as in Non-Storing Mode <td align="center">--</td>
. </tr>
</t> <tr>
<t> <th align="center">Untouched headers</th>
The <xref target="Storing-root2notrplnoIPIP"/> summarizes <td align="center">--</td>
what headers are needed for this scenario. <td align="center">IP6-IP6</td>
</t> <td align="center">--</td>
<t> <td align="center">--</td>
<figure title="SM: Summary of the use of headers from roo </tr>
t to RUL without encapsulation" anchor="Storing-root2notrplnoIPIP" align="center </tbody>
"> </table>
<artwork><![CDATA[
+-----------+----------+--------------+----------------+----------+
| Header | 6LBR | 6LR_i | 6LR_n | RUL |
| | src | i=(1,..,n-1) | | dst |
| | | | | |
+-----------+----------+--------------+----------------+----------+
| Added | RPI, RH3 | -- | -- | -- |
| headers | | | | |
+-----------+----------+--------------+----------------+----------+
| Modified | -- | RPI | RPI | -- |
| headers | | | RH3(consumed) | |
+-----------+----------+--------------+----------------+----------+
| Removed | -- | -- | -- | -- |
| headers | | | | |
+-----------+----------+--------------+----------------+----------+
| Untouched | -- | RH3 | -- | RPI, RH3 |
| headers | | | | (both |
| | | | | ignored) |
+-----------+----------+--------------+----------------+----------+
]]></artwork></figure>
</t>
</section> <t>
IP-in-IP encapsulation may be avoided for root-to-RUL com
munication.
In SM, it can be replaced by a loose RH3 header that indi
cates the RUL.
In which case, the packet is routed to the 6LR as a norma
l SM operation,
then the 6LR forwards to the RUL based on the RH3, and th
e RUL ignores
both the consumed RH3 and the RPI, as in Non-Storing mode
.
</t>
<t>
<xref target="Storing-root2notrplnoIPIP" format="default"
/> summarizes which headers are needed for this scenario.
</t>
<table anchor="Storing-root2notrplnoIPIP">
<name>SM: Summary of the Use of Headers from Root to RUL without Encapsulatio
n</name>
<thead>
<tr>
<th align="center">Header</th>
<th align="center">6LBR src</th>
<th align="center">6LR_i<br/>i=(1,..,n-1)</th>
<th align="center">6LR_n</th>
<th align="center">RUL dst</th>
</tr>
</thead>
<tbody>
<tr>
<th align="center">Added headers</th>
<td align="center">RPI, RH3</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">RPI</td>
<td align="center">RPI, RH3(consumed)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">RH3</td>
<td align="center">--</td>
<td align="center">RPI, RH3 (both ignored)</td>
</tr>
</tbody>
</table>
<section anchor="sm-nRal2root" title="SM: Example of Flow from RU </section>
L to Root"> <section anchor="sm-nRal2root" numbered="true" toc="default">
<t> <name>SM: Example of Flow from RUL to Root</name>
In this case the flow comprises: <t>
</t> In this case, the flow comprises:
<t> </t>
<t>
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_i --
(6LBR) &gt; root (6LBR)
</t> </t>
<t> <t>
For example, a communication flow could be: Node G (RUL) For example, a communication flow could be:
--> Node E (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) Node G (RUL) --&gt; Node E (6LR_1) --&gt; Node B (6LR_i) --&gt; Node A root (6L
</t> BR)
<t> </t>
<t>
6LR_i represents the intermediate routers from the sou rce (RUL) to the destination (6LBR), 6LR_i represents the intermediate routers from the sou rce (RUL) to the destination (6LBR),
1 &lt;= i &lt;= n, where n is the total number of rout and 1 &lt;= i &lt;= n, where n is the total number of
ers (6LR) routers (6LR)
that the packet goes through from the RUL to the 6LBR. that the packet goes through, from the RUL to the 6LBR
</t> .
<t> </t>
<t>
When the packet arrives from the RUL (Node G) to When the packet arrives from the RUL (Node G) to
6LR_1 (Node E), the 6LR_1 will encapsulate the packet 6LR_1 (Node E), the 6LR_1 will encapsulate the packet
in an IPv6-in-IPv6 header with an RPI. The IPv6-in-IPv6 in an IPv6-in-IPv6 header with an RPI. The IPv6-in-IPv6
header is addressed to the root (Node A). The root remo ves the header and processes header is addressed to the root (Node A). The root remo ves the header and processes
the packet. the packet.
</t> </t>
<t> <t>
The <xref target="Storing-notrpl2root"/> shows the table <xref target="Storing-notrpl2root" format="default"/> su
that summarizes what headers are needed for this use case mmarizes which headers are needed for this use case
where the IPv6-in-IPv6 header is addressed to the root ( Node A). where the IPv6-in-IPv6 header is addressed to the root ( Node A).
</t> </t>
<t> <table anchor="Storing-notrpl2root">
<figure title="SM: Summary of the use of headers from RU <name>SM: Summary of the Use of Headers from RUL to Root</name>
L to root." anchor="Storing-notrpl2root" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+------+--------------+----------------+-----------------+ <th align="center">Header</th>
| Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | <th align="center">RUL src</th>
| | src | | | | <th align="center">6LR_1</th>
| | node | | | | <th align="center">6LR_i</th>
+-----------+------+--------------+----------------+-----------------+ <th align="center">6LBR dst</th>
| Added | -- | IP6-IP6 | | -- | </tr>
| headers | | RPI | -- | | </thead>
+-----------+------+--------------+----------------+-----------------+ <tbody>
| Modified | -- | -- | RPI | -- | <tr>
| headers | | | | | <th align="center">Added headers</th>
+-----------+------+--------------+----------------+-----------------+ <td align="center">--</td>
| Removed | -- | -- | --- | IP6-IP6 | <td align="center">IP6-IP6 (RPI)</td>
| headers | | | | RPI | <td align="center">--</td>
+-----------+------+--------------+----------------+-----------------+ <td align="center">--</td>
| Untouched | -- | -- | IP6-IP6 | -- | </tr>
| headers | | | | | <tr>
+-----------+------+--------------+----------------+-----------------+ <th align="center">Modified headers</th>
]]></artwork></figure> <td align="center">--</td>
</t> <td align="center">--</td>
</section> <td align="center">RPI</td>
</section> <td align="center">--</td>
<section title=" SM: Interaction between Leaf and Internet."> </tr>
<tr>
<t> <th align="center">Removed headers</th>
In this section is described the communication flow <td align="center">--</td>
in storing mode (SM) between, <td align="center">--</td>
</t> <td align="center">--</td>
<t> <td align="center">IP6-IP6 (RPI)</td>
<list> </tr>
<t> <tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
</section>
<section numbered="true" toc="default">
<name>SM: Interaction between Leaf and Internet</name>
<t>
This section describes the communication flow
in Storing mode (SM) between the following:
</t>
<ul empty="true" spacing="normal">
<li>
RAL to Internet RAL to Internet
</t> </li>
<t> <li>
Internet to RAL Internet to RAL
</t> </li>
<t> <li>
RUL to Internet RUL to Internet
</t> </li>
<t> <li>
Internet to RUL Internet to RUL
</t> </li>
</list> </ul>
</t> <section anchor="sm-Ral2i" numbered="true" toc="default">
<name>SM: Example of Flow from RAL to Internet</name>
<section anchor="sm-Ral2i" title="SM: Example of Flow from RAL t <t>
o Internet"> In this case, the flow comprises:
<t> </t>
In this case the flow comprises: <t>
</t>
<t>
RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet RAL (6LN) --&gt; 6LR_i --&gt; root (6LBR) --&gt;
</t> Internet
<t> </t>
For example, the communication flow could be: Node F (RA <t>
L) --> Node D (6LR_i)--> Node B (6LR_i)--> Node A root(6LBR) --> Internet For example, the communication flow could be:
</t> Node F (RAL) --&gt; Node D (6LR_i) --&gt; Node B (6LR_i) --&gt; Node A root (6LB
<t> R) --&gt; Internet
</t>
<t>
6LR_i represents the intermediate routers from the sou rce (RAL) to the root (6LBR), 6LR_i represents the intermediate routers from the sou rce (RAL) to the root (6LBR),
1 &lt;= i &lt;= n, where n is the total number of rout and 1 &lt;= i &lt;= n, where n is the total number of
ers (6LR) routers (6LR)
that the packet goes through from the RAL to the 6LBR. that the packet goes through, from the RAL to the 6LBR
</t> .
<t> </t>
<t>
RPL information from RFC 6553 may go out to RPL information from RFC 6553 may go out to
Internet as it will be ignored by nodes which have Internet as it will be ignored by nodes that have
not been configured to be RPI aware. No IPv6-in-IPv6 head not been configured to be RPL aware. No IPv6-in-IPv6 head
er is required. er is required.
<!-- Beginning of Section 6 says <!-- [auth] Beginning of Section 6 says
"The DODAG root MUST force it to zero when passing "The DODAG root <bcp14>MUST</bcp14> force it to zer
the packet out to the Internet." o when passing the packet out to the Internet."
--> -->
</t> </t>
<t> <t>
On the other hand, the RAL may insert the RPI encapsulate On the other hand, the RAL may insert the RPI encapsulate
d in a IPv6-in-IPv6 header to the root. d in an IPv6-in-IPv6 header to the root.
Thus, the root removes the RPI and send the packet to the Thus, the root removes the RPI and sends the packet to th
Internet. e Internet.
</t> </t>
<t> <aside><t>
Note: In this use case, it is used a node as a leaf, b Note: In this use case, a leaf node is used, but this
ut this use case can be also use case
applicable to any RPL-aware-node type (e.g. 6LR) can also be applicable to any RPL-aware node type (e.g
</t> ., 6LR).
<t> </t> </aside>
The <xref target="Storing-rpl2int"/> summarizes what hea <t>
ders are needed for this use case when there is no encapsulation. <xref target="Storing-rpl2int" format="default"/> summar
Note that the RPI is modified by 6LBR to set the SenderR izes which headers are needed for this use case when there is no encapsulation.
ank to zero in case that it is not already zero. Note that the RPI is modified by 6LBR to set the SenderR
The <xref target="Storing-rpl2intIPIP"/> summarizes what ank to zero in the case that it is not already zero.
headers are needed when encapsulation to the root takes place. <xref target="Storing-rpl2intIPIP" format="default"/> su
</t> mmarizes which headers are needed when encapsulation to the root takes place.
</t>
<t> <table anchor="Storing-rpl2int">
<figure title="SM: Summary of the use of headers from RA <name>SM: Summary of the Use of Headers from RAL to Internet with No Encapsul
L to Internet with no encapsulation" anchor="Storing-rpl2int" align="center"> ation</name>
<artwork><![CDATA[ <thead>
+-----------+-----+-------+------+-----------+ <tr>
| Header | RAL | 6LR_i | 6LBR | Internet | <th align="center">Header</th>
| | src | | | dst | <th align="center">RAL src</th>
+-----------+-----+-------+------+-----------+ <th align="center">6LR_i</th>
| Added | RPI | -- | -- | -- | <th align="center">6LBR</th>
| headers | | | | | <th align="center">Internet dst</th>
+-----------+-----+-------+------+-----------+ </tr>
| Modified | -- | RPI | RPI | -- | </thead>
| headers | | | | | <tbody>
+-----------+-----+-------+------+-----------+ <tr>
| Removed | -- | -- | -- | -- | <th align="center">Added headers</th>
| headers | | | | | <td align="center">RPI</td>
+-----------+-----+-------+------+-----------+ <td align="center">--</td>
| Untouched | -- | -- | -- | RPI | <td align="center">--</td>
| headers | | | | (Ignored) | <td align="center">--</td>
+-----------+-----+-------+------+-----------+ </tr>
]]></artwork></figure> <tr>
<!-- RPI touched by 6LBR? set DagRank to 0? --> <th align="center">Modified headers</th>
</t> <td align="center">--</td>
<t> <td align="center">RPI</td>
<figure title="SM: Summary of the use of headers from RA <td align="center">RPI</td>
L to Internet with encapsulation to the root (6LBR)." <td align="center">--</td>
anchor="Storing-rpl2intIPIP" align="center"> </tr>
<artwork><![CDATA[ <tr>
+-----------+----------+--------------+--------------+--------------+ <th align="center">Removed headers</th>
| Header | RAL | 6LR_i | 6LBR | Internet dst | <td align="center">--</td>
| | src | | | | <td align="center">--</td>
+-----------+----------+--------------+--------------+--------------+ <td align="center">--</td>
| Added | IP6-IP6 | -- | -- | -- | <td align="center">--</td>
| headers | RPI | | | | </tr>
+-----------+----------+--------------+--------------+--------------+ <tr>
| Modified | -- | RPI | -- | -- | <th align="center">Untouched headers</th>
| headers | | | | | <td align="center">--</td>
+-----------+----------+--------------+--------------+--------------+ <td align="center">--</td>
| Removed | -- | -- | IP6-IP6 | -- | <td align="center">--</td>
| headers | | | RPI | | <td align="center">RPI (Ignored)</td>
+-----------+----------+--------------+--------------+--------------+ </tr>
| Untouched | -- | IP6-IP6 | -- | -- | </tbody>
| headers | | | | | </table>
+-----------+----------+--------------+--------------+--------------+
]]></artwork></figure>
</t>
</section>
<!-- section 7.6 --> <t>
<section title="SM: Example of Flow from Internet to RAL"> <!-- [auth] RPI touched by 6LBR? set DagRank to 0? -->
<t> </t>
In this case the flow comprises: <table anchor="Storing-rpl2intIPIP">
</t> <name>SM: Summary of the Use of Headers from RAL to Internet with Encapsulati
<t> on to the Root (6LBR)</name>
<thead>
<tr>
<th align="center">Header</th>
<th align="center">RAL src</th>
<th align="center">6LR_i</th>
<th align="center">6LBR</th>
<th align="center">Internet dst</th>
</tr>
</thead>
<tbody>
<tr>
<th align="center">Added headers</th>
<td align="center">IP6-IP6 (RPI)</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">RPI</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">IP6-IP6</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>SM: Example of Flow from Internet to RAL</name>
<t>
In this case, the flow comprises:
</t>
<t>
Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) Internet --&gt; root (6LBR) --&gt; 6LR_i --&gt;
</t> RAL (6LN)
<t> </t>
For example, a communication flow could be: Internet --> <t>
Node A root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) For example, a communication flow could be:
</t> Internet --&gt; Node A root (6LBR) --&gt; Node B (6LR_1) --&gt; Node D (6LR_n) -
<t> -&gt; Node F (RAL)
</t>
<t>
When the packet arrives from Internet to 6LBR When the packet arrives from Internet to 6LBR,
the RPI is added in a outer the RPI is added in a outer
IPv6-in-IPv6 header (with the IPv6-in-IPv6 desti IPv6-in-IPv6 header (with the IPv6-in-IPv6 desti
nation address set to the RAL) and sent to 6LR, which nation address set to the RAL) and sent to the 6LR, which
modifies the rank in the RPI. When the packet modifies the Rank in the RPI. When the packet
arrives at the RAL, the packet is decapsulated, which removes the RPI before the arrives at the RAL, the packet is decapsulated, which removes the RPI before the
packet is processed. packet is processed.
</t> </t>
<t> <t>
The <xref target="Storing-int2rpl"/> shows the table tha <xref target="Storing-int2rpl" format="default"/> summar
t summarizes what headers are needed for this use case. izes which headers are needed for this use case.
</t>
<t>
<figure title="SM: Summary of the use of headers from In
ternet to RAL."
anchor="Storing-int2rpl" align="center">
<artwork><![CDATA[
+-----------+----------+--------------+--------------+--------------+
| Header | Internet | 6LBR | 6LR_i | RAL dst |
| | src | | | |
+-----------+----------+--------------+--------------+--------------+
| Added | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | | |
+-----------+----------+--------------+--------------+--------------+
| Modified | -- | -- | RPI | -- |
| headers | | | | |
+-----------+----------+--------------+--------------+--------------+
| Removed | -- | -- | -- | IP6-IP6(RPI) |
| headers | | | | |
+-----------+----------+--------------+--------------+--------------+
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+-----------+----------+--------------+--------------+--------------+
]]></artwork></figure>
</t>
</section>
<!-- section 7.6 --> </t>
<section anchor="sm-nRal2i" title="SM: Example of Flow from RUL t <table anchor="Storing-int2rpl">
o Internet"> <name>SM: Summary of the Use of Headers from Internet to RAL</name>
<t> <thead>
In this case the flow comprises: <tr>
</t> <th align="center">Header</th>
<t> <th align="center">Internet src</th>
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> In <th align="center">6LBR</th>
ternet <th align="center">6LR_i</th>
</t> <th align="center"> RAL dst</th>
<t> </tr>
For example, a communication flow could be: Node G (RUL)--> Nod </thead>
e E (6LR_1)--> Node B (6lR_i) --> Node A root(6LBR) --> Internet <tbody>
</t> <tr>
<t> <th align="center">Added headers</th>
The node 6LR_1 (i=1) will add an IPv6-in-IPv6(RPI) header add <td align="center">--</td>
ressed to the root such that the root can remove <td align="center">IP6-IP6 (RPI)</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI)</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sm-nRal2i" numbered="true" toc="default">
<name>SM: Example of Flow from RUL to Internet</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_i --&gt; root (6L
BR) --&gt; Internet
</t>
<t>
For example, a communication flow could be:
Node G (RUL) --&gt; Node E (6LR_1) --&gt; Node B (6lR_i) --&gt; Node A root (6LB
R) --&gt; Internet
</t>
<t>
The node 6LR_1 (i=1) will add an IPv6-in-IPv6 (RPI) header ad
dressed to the root such that the root can remove
the RPI before passing upwards. the RPI before passing upwards.
In the intermediate 6LR, the rank in the RPI is modified. In the intermediate 6LR, the Rank in the RPI is modified.
</t> </t>
<t> <t>
The originating node will ideally leave the IPv6 flow The originating node will ideally leave the IPv6 flow
label as zero so that the packet can be better compressed thr ough label as zero so that the packet can be better compressed thr ough
the LLN. The 6LBR will set the flow label of the packet to a the LLN. The 6LBR will set the flow label of the packet to a
non-zero value when sending to the Internet, for details chec non-zero value when sending to the Internet. For details, che
k <xref target="RFC6437"/>. ck <xref target="RFC6437" format="default"/>.
</t> </t>
<t> <t>
The <xref target="Storing-notrpl2int"/> shows the table that su <xref target="Storing-notrpl2int" format="default"/> summarizes
mmarizes what headers are needed for this use case. which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-notrpl2int">
<figure title="SM: Summary of the use of headers from RUL to In <name>SM: Summary of the Use of Headers from RUL to Internet</name>
ternet." anchor="Storing-notrpl2int" align="center"> <thead>
<artwork><![CDATA[ <tr>
+---------+-------+------------+-------------+-------------+--------+ <th align="center">Header</th>
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| <th align="center">IPv6 src (RUL)</th>
| | src | | [i=2,...,n] | | dst | <th align="center">6LR_1</th>
| | node | | | | | <th align="center">6LR_i i=(2,..,n)</th>
| | (RUL) | | | | | <th align="center">6LBR</th>
+---------+-------+------------+-------------+-------------+--------+ <th align="center">Internet dst</th>
| Added | -- |IP6-IP6(RPI)| -- | -- | -- | </tr>
| headers | | | | | | </thead>
+---------+-------+------------+-------------+-------------+--------+ <tbody>
| Modified| -- | -- | RPI | -- | -- | <tr>
| headers | | | | | | <th align="center">Added headers</th>
+---------+-------+------------+-------------+-------------+--------+ <td align="center">--</td>
| Removed | -- | -- | -- | IP6-IP6(RPI)| -- | <td align="center">IP6-IP6 (RPI)</td>
| headers | | | | | | <td align="center">--</td>
+---------+-------+------------+-------------+-------------+--------+ <td align="center">--</td>
|Untouched| -- | -- | -- | -- | -- | <td align="center">--</td>
| headers | | | | | | </tr>
+---------+-------+------------+-------------+-------------+--------+ <tr>
]]></artwork></figure> <th align="center">Modified headers</th>
</t> <td align="center">--</td>
</section> <td align="center">--</td>
<td align="center">RPI</td>
<section title="SM: Example of Flow from Internet to RUL. <td align="center">--</td>
"> <td align="center">--</td>
<t> </tr>
In this case the flow comprises: <tr>
</t> <th align="center">Removed headers</th>
<t> <td align="center">--</td>
Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 <td align="center">--</td>
dst node) <td align="center">--</td>
</t> <td align="center">IP6-IP6 (RPI)</td>
<t> <td align="center">--</td>
For example, a communication flow could be: Internet --> </tr>
Node A root(6LBR) --> Node B (6LR_i)--> Node E (6LR_n) --> Node G (RUL) <tr>
</t> <th align="center">Untouched headers</th>
<t> <td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>SM: Example of Flow from Internet to RUL</name>
<t>
In this case, the flow comprises:
</t>
<t>
Internet --&gt; root (6LBR) --&gt; 6LR_i --&gt;
RUL (IPv6 dst node)
</t>
<t>
For example, a communication flow could be:
Internet --&gt; Node A root (6LBR) --&gt; Node B (6LR_i) --&gt; Node E (6LR_n) -
-&gt; Node G (RUL)
</t>
<t>
The 6LBR will have to add an RPI within an The 6LBR will have to add an RPI within an
IPv6-in-IPv6 header. The IPv6-in-IPv6 is addressed IPv6-in-IPv6 header. The IPv6-in-IPv6 encapsulating he ader is addressed
to the 6LR parent of the RUL. to the 6LR parent of the RUL.
</t> </t>
<t> <t>
Further details about this are mentioned in <xref targ Further details about this are mentioned in <xref targ
et="I-D.ietf-roll-unaware-leaves"/>, et="RFC9010" format="default"/>,
which specifies RPL routing for a 6LN acting as a plai which specifies RPL routing for a 6LN acting as a plai
n host and not being aware of RPL. n host and being unaware of RPL.
</t> </t>
<t> <t>
The 6LBR may set the flow label on the inner IPv6-in-I Pv6 The 6LBR may set the flow label on the inner IPv6-in-I Pv6
header to zero in order to aid in compression <xref ta header to zero in order to aid in compression <xref ta
rget="RFC8138"/><xref target="RFC6437"/>. rget="RFC8138" format="default"/> <xref target="RFC6437" format="default"/>.
</t> </t>
<t> <t>
The <xref target="Storing-int2notrpl"/> shows the table t <xref target="Storing-int2notrpl" format="default"/> summ
hat summarizes what headers are needed for this use case. arizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-int2notrpl">
<figure title=" SM: Summary of the use of headers from In <name>SM: Summary of the Use of Headers from Internet to RUL</name>
ternet to RUL." <thead>
anchor="Storing-int2notrpl" align="center"> <tr>
<artwork><![CDATA[ <th align="center">Header</th>
+---------+-------+------------+--------------+-------------+-------+ <th align="center">Internet src</th>
| Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL | <th align="center">6LBR</th>
| | net | |[i=1,..,n-1] | | dst | <th align="center">6LR_i i=(1,..,n-1)</th>
| | src | | | | | <th align="center">6LR_n</th>
| | | | | | | <th align="center">RUL dst</th>
+---------+-------+------------+--------------+-------------+-------+ </tr>
| Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | </thead>
| headers | | | | | | <tbody>
+---------+-------+------------+--------------+-------------+-------+ <tr>
| Modified| -- | -- | RPI | -- | -- | <th align="center">Added headers</th>
| headers | | | | | | <td align="center">--</td>
+---------+-------+------------+--------------+-------------+-------+ <td align="center">IP6-IP6 (RPI)</td>
| Removed | -- | -- | -- | IP6-IP6(RPI)| -- | <td align="center">--</td>
| headers | | | | | | <td align="center">--</td>
+---------+-------+------------+--------------+-------------+-------+ <td align="center">--</td>
|Untouched| -- | -- | -- | -- | -- | </tr>
| headers | | | | | | <tr>
+---------+-------+------------+--------------+-------------+-------+ <th align="center">Modified headers</th>
]]></artwork></figure> <td align="center">--</td>
</t> <td align="center">--</td>
</section> <td align="center">RPI</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
<section title="SM: Interaction between Leaf and Leaf"> <section numbered="true" toc="default">
<name>SM: Interaction between Leaf and Leaf</name>
<t> <t>
In this section is described the communication flow This section describes the communication flow
in storing mode (SM) between, in Storing mode (SM) between the following:
</t> </t>
<t> <ul empty="true" spacing="normal">
<list> <li>
<t>
RAL to RAL RAL to RAL
</t> </li>
<t> <li>
RAL to RUL RAL to RUL
</t> </li>
<t> <li>
RUL to RAL RUL to RAL
</t> </li>
<t> <li>
RUL to RUL RUL to RUL
</t> </li>
</list> </ul>
</t> <section anchor="storingRALtoRAL" numbered="true" toc="default">
<!-- section 7.9 --> <name>SM: Example of Flow from RAL to RAL</name>
<section anchor="storingRALtoRAL" title="SM: Example of Flow from <t>
RAL to RAL"> In <xref target="RFC6550" format="default"/>, RPL allows a si
<t> mple, one-hop
In <xref target="RFC6550"/> RPL allows a simple one-hop optimization for both Storing and Non-Storing
optimization for both storing and non-storing
networks. networks.
A node may send a packet destined to a one-hop A node may send a packet destined to a one-hop
neighbor directly to that node. See section 9 in <xref neighbor directly to that node. See <xref target="RFC6550" se
target="RFC6550"/>. ction="9" sectionFormat="of" format="default"/>.
</t> </t>
<t> <t>
When the nodes are not directly connected, then in storing When the nodes are not directly connected, then
mode, the flow comprises: the flow comprises the following in the Storing mode:
</t> </t>
<t> <t>
RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id RAL src (6LN) --&gt; 6LR_ia --&gt; common parent (6LR_x) --&g
--> RAL dst (6LN) t; 6LR_id --&gt; RAL dst (6LN)
</t> </t>
<t> <t>
For example, a communication flow could be: Node F (RAL src)--> For example, a communication flow could be:
Node D (6LR_ia)--> Node B (6LR_x) --> Node E (6LR_id) --> Node H (RAL dst) Node F (RAL src) --&gt; Node D (6LR_ia) --&gt; Node B (6LR_x) --&gt; Node E (6LR
</t> _id) --&gt; Node H (RAL dst)
<t> </t>
6LR_ia (Node D) represents the intermediate routers from sour <t>
ce to the common parent (6LR_x) (Node B), 6LR_ia (Node D) represents the intermediate routers from the
1 &lt;= ia &lt;= n, where n is the total number of routers (6 source to the common parent 6LR_x (Node B),
LR) and 1 &lt;= ia &lt;= n, where n is the total number of router
that the packet goes through from RAL (Node F) to the common s (6LR)
parent 6LR_x (Node B). that the packet goes through, from the RAL (Node F) to the co
</t> mmon parent 6LR_x (Node B).
<t> </t>
6LR_id (Node E) represents the intermediate routers from the <t>
common parent (6LR_x) (Node B) to destination RAL (Node H), 6LR_id (Node E) represents the intermediate routers from the
1 &lt;= id &lt;= m, where m is the total number of routers ( common parent 6LR_x (Node B) to the destination RAL (Node H),
6LR) and 1 &lt;= id &lt;= m, where m is the total number of route
that the packet goes through from the common parent (6LR_x) t rs (6LR)
o destination RAL (Node H). that the packet goes through, from the common parent (6LR_x)
</t> to the destination RAL (Node H).
<t> </t>
<t>
It is assumed that the two nodes are in the same RPL domain It is assumed that the two nodes are in the same RPL domain
(that they share the same DODAG root). At the (that they share the same DODAG root). At the
common parent (Node B), the direction flag ('O' flag) of the RPI is changed (from decreasing ranks to increasing ranks). common parent (Node B), the direction flag ('O' flag) of the RPI is changed (from decreasing ranks to increasing ranks).
</t> </t>
<t> <t>
While the 6LR nodes will update the RPI, no node needs to While the 6LR nodes will update the RPI, no node needs to
add or remove the RPI, so no IPv6-in-IPv6 headers are add or remove the RPI, so no IPv6-in-IPv6 headers are
necessary. necessary.
</t> </t>
<t> <t>
The <xref target="Storing-rpl2rpl"/> summarizes what headers are <xref target="Storing-rpl2rpl" format="default"/> summarizes whi
needed for this use case. ch headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-rpl2rpl">
<figure title="SM: Summary of the Use of Headers from RAL to RAL <name>SM: Summary of the Use of Headers from RAL to RAL</name>
" anchor="Storing-rpl2rpl" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+-----+--------+---------+--------+-----+ <th align="center">Header</th>
| Header | RAL | 6LR_ia | 6LR_x | 6LR_id | RAL | <th align="center">RAL src</th>
| | src | | (common | | dst | <th align="center">6LR_ia</th>
| | | | parent) | | | <th align="center">6LR_x (common parent)</th>
+-----------+-----+--------+---------+--------+-----+ <th align="center">6LR_id</th>
| Added | RPI | -- | -- | -- | -- | <th align="center">RAL dst</th>
| headers | | | | | | </tr>
+-----------+-----+--------+---------+--------+-----+ </thead>
| Modified | -- | RPI | RPI | RPI | -- | <tbody>
| headers | | | | | | <tr>
+-----------+-----+--------+---------+--------+-----+ <th align="center">Added headers</th>
| Removed | -- | -- | -- | -- | RPI | <td align="center">RPI</td>
| headers | | | | | | <td align="center">--</td>
+-----------+-----+--------+---------+--------+-----+ <td align="center">--</td>
| Untouched | -- | -- | -- | -- | -- | <td align="center">--</td>
| headers | | | | | | <td align="center">--</td>
+-----------+-----+--------+---------+--------+-----+ </tr>
]]></artwork></figure> <tr>
</t> <th align="center">Modified headers</th>
</section> <td align="center">--</td>
<td align="center">RPI</td>
<!-- section 7.10 --> <td align="center">RPI</td>
<section anchor="storingRALtononRAL" title="SM: Example of Flow f <td align="center">RPI</td>
rom RAL to RUL"> <td align="center">--</td>
<t> </tr>
In this case the flow comprises: <tr>
</t> <th align="center">Removed headers</th>
<t> <td align="center">--</td>
RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The <td align="center">--</td>
root-) --> 6LR_id --> RUL (IPv6 dst node) <td align="center">--</td>
</t> <td align="center">--</td>
<t> <td align="center">RPI</td>
For example, a communication flow could be: Node F (RAL) </tr>
--> Node D --> Node B--> Node A -->Node B --> Node E --> Node G (RUL) <tr>
</t> <th align="center">Untouched headers</th>
<t> <td align="center">--</td>
6LR_ia represents the intermediate routers from source <td align="center">--</td>
(RAL) to the <td align="center">--</td>
common parent (the Root), 1 &lt;= ia &lt;= n, where n <td align="center">--</td>
is the total number of <td align="center">--</td>
routers (6LR) that the packet goes through from RAL to </tr>
the Root. </tbody>
</t> </table>
<t> </section>
6LR_id (Node E) represents the intermediate routers fr <section anchor="storingRALtononRAL" numbered="true" toc="default
om the Root ">
(Node B) to destination RUL (Node G). In this case, 1 <name>SM: Example of Flow from RAL to RUL</name>
&lt;= id &lt;= m, <t>
In this case, the flow comprises:
</t>
<t>
RAL src (6LN) --&gt; 6LR_ia --&gt; common parent (6LBR,
the root) --&gt; 6LR_id --&gt; RUL (IPv6 dst node)
</t>
<t>
For example, a communication flow could be:
Node F (RAL) --&gt; Node D --&gt; Node B --&gt; Node A --&gt; Node B --&gt; Node
E --&gt; Node G (RUL)
</t>
<t>
6LR_ia represents the intermediate routers from the so
urce (RAL) to the
common parent (the root), and 1 &lt;= ia &lt;= n, wher
e n is the total number of
routers (6LR) that the packet goes through, from the R
AL to the root.
</t>
<t>
6LR_id (Node E) represents the intermediate routers fr
om the root
(Node B) to the destination RUL (Node G). In this cas
e, 1 &lt;= id &lt;= m,
where m is the total number of routers (6LR) that the packet goes where m is the total number of routers (6LR) that the packet goes
through from the Root down to the destination RUL. through, from the root down to the destination RUL.
</t> </t>
<t> <t>
In this case, the packet from the RAL goes to 6LBR bec In this case, the packet from the RAL goes to the 6LBR
ause the route to the RUL is not injected into the RPL-SM. because the route to the RUL is not injected into the RPL SM.
Thus, the RAL inserts an RPI (RPI1) addressed to the r Thus, the RAL inserts an RPI (RPI1) addressed to the r
oot(6LBR). The root does not remove the RPI1 oot (6LBR). The root does not remove the RPI1
(the root cannot remove an RPI if there is no encapsul (the root cannot remove an RPI if there is no encapsul
ation). The root inserts an IPv6-IPv6 encapsulation with an RPI2 ation). The root inserts an IPv6-in-IPv6 encapsulation with an RPI2
and sends it to the 6LR parent of the RUL, which remov es the encapsulation and RPI2 before passing the packet to the RUL. and sends it to the 6LR parent of the RUL, which remov es the encapsulation and RPI2 before passing the packet to the RUL.
</t> </t>
<!-- section 7.10 <!-- [auth] section 7.10
This situation is identical to the previous situation This situation is identical to the previous situation
<xref target="storingRALtoRAL" /> <xref target="storingRALtoRAL" />
</t> --> </t> -->
<t> <t>
The <xref target="Storing-rpl2nrpl"/> summarizes what he <xref target="Storing-rpl2nrpl" format="default"/> summa
aders are needed for this use case. rizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-rpl2nrpl">
<figure title="SM: Summary of the Use of Headers from R <name>SM: Summary of the Use of Headers from RAL to RUL</name>
AL to RUL" anchor="Storing-rpl2nrpl" align="center"> <thead>
<artwork><![CDATA[ <tr>
+----------+-------+-------+---------+---------+---------+---------+ <th align="center">Header</th>
| Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | <th align="center">RAL src</th>
| | src | | | | | dst | <th align="center">6LR_ia</th>
| | node | | | | | node | <th align="center">6LBR</th>
+----------+-------+-------+---------+---------+---------+---------+ <th align="center">6LR_id</th>
| Added | | | IP6-IP6 | -- | -- | -- | <th align="center">6LR_m</th>
| headers | RPI1 | -- | (RPI2) | | | | <th align="center">RUL dst</th>
| | | | | | | | </tr>
+----------+-------+-------+---------+---------+---------+---------+ </thead>
| Modified | -- | | -- | | | -- | <tbody>
| headers | | RPI1 | | RPI2 | -- | | <tr>
| | | | | | | | <th align="center">Added headers</th>
+----------+-------+-------+---------+---------+---------+---------+ <td align="center">RPI1</td>
| Removed | -- | -- | | -- | IP6-IP6 | -- | <td align="center">--</td>
| headers | | | -- | | (RPI2) | | <td align="center">IP6-IP6 (RPI2)</td>
| | | | | | | | <td align="center">--</td>
+----------+-------+-------+---------+---------+---------+---------+ <td align="center">--</td>
|Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | <td align="center">--</td>
| headers | | | | | |(Ignored)| </tr>
| | | | | | | | <tr>
+----------+-------+-------+---------+---------+---------+---------+ <th align="center">Modified headers</th>
]]></artwork></figure> <td align="center">--</td>
</t> <td align="center">RPI1</td>
</section> <td align="center">--</td>
<td align="center">RPI2</td>
<section anchor="storingnotRALtoRAL" title="SM: Example of Flow f <td align="center">--</td>
rom RUL to RAL"> <td align="center">--</td>
<t> </tr>
In this case the flow comprises: <tr>
</t> <th align="center">Removed headers</th>
<t> <td align="center">--</td>
RUL (IPv6 src node) --> 6LR_ia --> 6LBR --> 6LR_id --> RAL d <td align="center">--</td>
st (6LN) <td align="center">--</td>
</t> <td align="center">--</td>
<t> <td align="center">IP6-IP6 (RPI2)</td>
For example, a communication flow could be: Node G (RUL)--> Nod <td align="center">--</td>
e E --> Node B --> Node A --> Node B --> Node D --> Node F (RAL) </tr>
</t> <tr>
<t> <th align="center">Untouched headers</th>
6LR_ia (Node E) represents the intermediate routers from sour <td align="center">--</td>
ce (RUL) (Node G) to the root (Node A). <td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">RPI1</td>
<td align="center">RPI1</td>
<td align="center">RPI1 (ignored)</td>
</tr>
</tbody>
</table>
</section>
<section anchor="storingnotRALtoRAL" numbered="true" toc="default">
<name>SM: Example of Flow from RUL to RAL</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --&gt; 6LR_ia --&gt; 6LBR --&gt; 6LR_id -
-&gt; RAL dst (6LN)
</t>
<t>
For example, a communication flow could be:
Node G (RUL) --&gt; Node E --&gt; Node B --&gt; Node A --&gt; Node B --&gt; Node
D --&gt; Node F (RAL)
</t>
<t>
6LR_ia (Node E) represents the intermediate routers from the
source (RUL) (Node G) to the root (Node A).
In this case, 1 &lt;= ia &lt;= n, where n is the total number of routers (6LR) In this case, 1 &lt;= ia &lt;= n, where n is the total number of routers (6LR)
that the packet goes through from source to the root. that the packet goes through, from the source to the root.
</t> </t>
<t> <t>
6LR_id represents the intermediate routers from the root (Nod 6LR_id represents the intermediate routers from the root (Nod
e A) to destination RAL (Node F). e A) to the destination RAL (Node F).
In this case, 1 &lt;= id &lt;= m, where m is the total number of routers (6LR) In this case, 1 &lt;= id &lt;= m, where m is the total number of routers (6LR)
that the packet goes through from the root to the destination that the packet goes through, from the root to the destinatio
RAL. n RAL.
</t> </t>
<t> <t>
The 6LR_1 (Node E) receives the packet from the RUL (Node G) and The 6LR_1 (Node E) receives the packet from the RUL (Node G) and
inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to the root. inserts the RPI (RPI1) encapsulated in an IPv6-in-IPv6 header to the root.
The root removes the outer header including the RPI (RPI1) an d The root removes the outer header including the RPI (RPI1) an d
inserts a new RPI (RPI2) addressed to the destination RAL (No de F). inserts a new RPI (RPI2) addressed to the destination RAL (No de F).
</t> </t>
<t> <t>
The <xref target="Storing-notrpl2rpl"/> shows the table that su <xref target="Storing-notrpl2rpl" format="default"/> summarizes
mmarizes what headers are needed for this use case. which headers are needed for this use case.
</t> </t>
<t> <table anchor="Storing-notrpl2rpl">
<figure title="SM: Summary of the use of headers from RUL to RA <name>SM: Summary of the Use of Headers from RUL to RAL</name>
L." anchor="Storing-notrpl2rpl" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+------+---------+---------+---------+---------+---------+ <th align="center">Header</th>
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | <th align="center">RUL src</th>
| | src | | | | | dst | <th align="center">6LR_1</th>
| | node | | | | | node | <th align="center">6LR_ia</th>
+-----------+------+---------+---------+---------+---------+---------+ <th align="center">6LBR</th>
| Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | <th align="center">6LR_id</th>
| headers | | (RPI1) | | (RPI2) | | | <th align="center">RAL dst</th>
| | | | | | | | </tr>
+-----------+------+---------+---------+---------+---------+---------+ </thead>
| Modified | -- | | | -- | | -- | <tbody>
| headers | | -- | RPI1 | | RPI2 | | <tr>
| | | | | | | | <th align="center">Added headers</th>
+-----------+------+---------+---------+---------+---------+---------+ <td align="center">--</td>
| Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | <td align="center">IP6-IP6 (RPI1)</td>
| headers | | -- | | (RPI1) | | (RPI2) | <td align="center">--</td>
| | | | | | | | <td align="center">IP6-IP6 (RPI2)</td>
+-----------+------+---------+---------+---------+---------+---------+ <td align="center">--</td>
| Untouched | -- | -- | -- | -- | -- | -- | <td align="center">--</td>
| headers | | | | | | | </tr>
+-----------+------+---------+---------+---------+---------+---------+ <tr>
]]></artwork></figure> <th align="center">Modified headers</th>
</t> <td align="center">--</td>
</section> <td align="center">--</td>
<td align="center">RPI1</td>
<section title="SM: Example of Flow from RUL to RUL"> <td align="center">--</td>
<t> <td align="center">RPI2</td>
In this case the flow comprises: <td align="center">--</td>
</t> </tr>
<t> <tr>
RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id -- <th align="center">Removed headers</th>
> RUL (IPv6 dst node) <td align="center">--</td>
</t> <td align="center">--</td>
<t> <td align="center">--</td>
For example, a communication flow could be: Node G (RUL src)--> <td align="center">IP6-IP6 (RPI1)</td>
Node E --> Node B --> Node A (root) --> Node C --> Node J (RUL dst) <td align="center">--</td>
</t> <td align="center">IP6-IP6 (RPI2)</td>
<t> </tr>
Internal nodes 6LR_ia (e.g: Node E or Node B) is the <tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>SM: Example of Flow from RUL to RUL</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_ia --&gt; 6LBR --
&gt; 6LR_id --&gt; RUL (IPv6 dst node)
</t>
<t>
For example, a communication flow could be:
Node G (RUL src) --&gt; Node E --&gt; Node B --&gt; Node A (root) --&gt; Node C
--&gt; Node J (RUL dst)
</t>
<t>
Internal nodes 6LR_ia (e.g., Node E or Node B) is the
intermediate router from the RUL source (Node G) intermediate router from the RUL source (Node G)
to the root (6LBR) (Node A). to the root (6LBR) (Node A).
In this case, 1 &lt;= ia &lt;= n, where n is the total number of routers (6LR) In this case, 1 &lt;= ia &lt;= n, where n is the total number of routers (6LR)
that the packet goes through from the RUL to the root. 6LR_1 that the packet goes through, from the RUL to the root. 6LR_1
refers when ia=1. applies when ia=1.
</t> </t>
<t> <t>
6LR_id (Node C) represents the intermediate routers from the root 6LR_id (Node C) represents the intermediate routers from the root
(Node A) to the destination RUL dst node (Node J). (Node A) to the destination RUL (Node J).
In this case, 1 &lt;= id &lt;= m, where m is the total number of routers (6LR) In this case, 1 &lt;= id &lt;= m, where m is the total number of routers (6LR)
that the packet goes through from the root to destination RU L. that the packet goes through, from the root to the destinatio n RUL.
</t> </t>
<t> <t>
The 6LR_1 (Node E) receives the packet from the The 6LR_1 (Node E) receives the packet from the
RUL (Node G) and inserts the RPI (RPI), RUL (Node G) and adds the RPI (RPI1)
encapsulated in an IPv6-in-IPv6 header directed to the root. in an IPv6-in-IPv6 encapsulation directed to the root.
The root removes the outer header including the RPI (RPI1) an d The root removes the outer header including the RPI (RPI1) an d
inserts a new RPI (RPI2) addressed to the 6LR father of the R inserts a new RPI (RPI2) addressed to the 6LR parent of the R
UL. UL.
</t> </t>
<t> <t>
The <xref target="Storing-notrpl2notrpl"/> shows the table that <xref target="Storing-notrpl2notrpl" format="default"/> summari
summarizes what headers are needed for this use case. zes which headers are needed for this use case.
</t>
<t>
<figure title="SM: Summary of the use of headers from RUL to R
UL" anchor="Storing-notrpl2notrpl" align="center">
<artwork><![CDATA[
+---------+----+-------------+--------+---------+--------+-------+---+
| Header |RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id |6LR_n |RUL|
| |src | | | | | |dst|
| | | | | | | | |
+---------+----+-------------+--------+---------+--------+-------+---+
| Added | -- |IP6-IP6(RPI1)| -- | IP6-IP6 | -- | -- | --|
| Headers | | | | (RPI2) | | | |
+---------+----+-------------+--------+---------+--------+-------+---+
|Modified | -- | -- | | -- | | -- | --|
|headers | | | RPI1 | | RPI2 | | |
+---------+----+-------------+--------+---------+--------+-------+---+
| Removed | -- | -- | -- | IP6-IP6 | -- |IP6-IP6| --|
| headers | | | | (RPI1) | | (RPI2)| |
+---------+----+-------------+--------+---------+--------+-------+---+
|Untouched| -- | -- | -- | -- | -- | -- | --|
| headers | | | | | | | |
+---------+----+-------------+--------+---------+--------+-------+---+
]]></artwork></figure>
</t>
</section>
</section>
</section>
<section title="Non Storing mode">
<t> </t>
In Non Storing Mode (Non-SM) (fully source routed), <table anchor="Storing-notrpl2notrpl">
<name>SM: Summary of the Use of Headers from RUL to RUL</name>
<thead>
<tr>
<th align="center">Header</th>
<th align="center">RUL src</th>
<th align="center">6LR_1</th>
<th align="center">6LR_ia</th>
<th align="center">6LBR</th>
<th align="center">6LR_id</th>
<th align="center">6LR_n</th>
<th align="center">RUL dst</th>
</tr>
</thead>
<tbody>
<tr>
<th align="center">Added headers</th>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">--</td>
<td align="center">RPI2</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI2)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<section anchor="sec_non-sm" numbered="true" toc="default">
<name>Non-Storing Mode</name>
<t>
In Non-Storing mode (Non-SM) (fully source routed),
the 6LBR (DODAG root) has complete knowledge about the the 6LBR (DODAG root) has complete knowledge about the
connectivity of all DODAG nodes, and all traffic flows connectivity of all DODAG nodes and all traffic flows
through the root node. Thus, there is no need for all nodes to through the root node. Thus, there is no need for all nodes to
know about the existence of RPL-unaware nodes. know about the existence of RPL-unaware nodes.
Only the 6LBR needs to act if compensation is necessary for not-RPL Only the 6LBR needs to act if compensation is necessary for
aware receivers. RPL-unaware receivers.
</t> </t>
<t> <t>
The table (<xref target="fig_table_non-storing" />) summarizes what h <xref target="fig_table_non-storing" format="default"/> summarizes wh
eaders are needed in the following ich headers are needed in the following
scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 header scenarios and indicates when the RPI, RH3, and IPv6-in-IPv6 header
are to be inserted. The last column depicts the are to be inserted. The last column depicts the
target destination of the IPv6-in-IPv6 header: 6LN (indicated by "RAL "), 6LR (parent of a RUL) or the root. target destination of the IPv6-in-IPv6 header: 6LN (indicated by "RAL "), 6LR (parent of a RUL), or the root.
In cases where no IPv6-in-IPv6 header is needed, the column indicates "No". In cases where no IPv6-in-IPv6 header is needed, the column indicates "No".
There is no expectation on RPL that RPI can be omitted, because it is needed for routing, quality of service and compression. There is no expectation on RPL that RPI can be omitted because it is needed for routing, quality of service, and compression.
This specification expects that an RPI is always present. This specification expects that an RPI is always present.
The term "may(up)" means that the IPv6-in-IPv6 header may be necessar The term "may(up)" means that the IPv6-in-IPv6 header may be necessar
y in the upwards direction. y in the Upward direction.
The term "must(up)" means that the IPv6-in-IPv6 header must be presen The term "must(up)" means that the IPv6-in-IPv6 header must be presen
t in the upwards direction. t in the Upward direction.
The term "must(down)" means that the IPv6-in-IPv6 header must be pres The term "must(down)" means that the IPv6-in-IPv6 header must be pres
ent in the downward direction. ent in the Downward direction.
</t> </t>
<t> <t>
The leaf can be a router 6LR or a host, both indicated as 6LN (<xref The leaf can be a router 6LR or a host, both indicated as 6LN (<xref
target="fig_CommonTopology"/>). In the table (<xref target="fig_table_non-storin target="fig_CommonTopology" format="default"/>). In <xref target="fig_table_non-
g" />) the storing" format="default"/>, the
(1) indicates a 6tisch case <xref target="RFC8180"/>, where the RPI m (1) indicates a 6TiSCH case <xref target="RFC8180" format="default"/>
ay still be needed , where the RPI may still be needed
for the RPLInstanceID to be available for priority/channel selection a t each hop. for the RPLInstanceID to be available for priority/channel selection a t each hop.
</t> </t>
<t> <table anchor="fig_table_non-storing">
<name>Headers Needed in Non-Storing Mode: RPI, RH3, IPv6-in-IPv6 Encapsulatio
<figure title="Table that shows headers needed in Non-Storing mode: RP n</name>
I, RH3, IPv6-in-IPv6 encapsulation." anchor="fig_table_non-storing" align="cente <thead>
r"> <tr>
<artwork><![CDATA[ <th align="center">Interaction between</th>
+--- ------------+-------------+-----+-----+--------------+----------+ <th align="center">Use Case</th>
| Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP | <th align="center">RPI</th>
| between | | | | | dst | <th align="center">RH3</th>
+----------------+-------------+-----+-----+--------------+----------+ <th align="center">IPv6-in-IPv6</th>
| | RAL to root | Yes | No | No | No | <th align="center">IP-in-IP dst</th>
| +-------------+-----+-----+--------------+----------+ </tr>
| Leaf - Root | root to RAL | Yes | Yes | No | No | </thead>
| +-------------+-----+-----+--------------+----------+ <tbody>
| | root to RUL | Yes | Yes | No | 6LR | <tr>
| | | (1) | | | | <th align="center" rowspan="4">Leaf - Root</th>
| +-------------+-----+-----+--------------+----------+ <td align="center">RAL to root</td>
| | RUL to root | Yes | No | must | root | <td align="center">Yes</td>
+----------------+-------------+-----+-----+--------------+----------+ <td align="center">No</td>
| | RAL to Int | Yes | No | may(up) | root | <td align="center">No</td>
| +-------------+-----+-----+--------------+----------+ <td align="center">No</td>
|Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | </tr>
| +-------------+-----+-----+--------------+----------+ <tr>
| | RUL to Int | Yes | No | must | root | <td align="center">root to RAL</td>
| +-------------+-----+-----+--------------+----------+ <td align="center">Yes</td>
| | Int to RUL | Yes | Yes | must | 6LR | <td align="center">Yes</td>
+----------------+-------------+-----+-----+--------------+----------+ <td align="center">No</td>
| | RAL to RAL | Yes | Yes | may(up) | root | <td align="center">No</td>
| | | | +--------------+----------+ </tr>
| | | | | must(down) | RAL | <tr>
| Leaf - Leaf +-------------+-----+-----+--------------+----------+ <td align="center">root to RUL</td>
| | RAL to RUL | Yes | Yes | may(up) | root | <td align="center">Yes (1)</td>
| | | | +--------------+----------+ <td align="center">Yes</td>
| | | | | must(down) | 6LR | <td align="center">No</td>
| +-------------+-----+-----+--------------+----------+ <td align="center">6LR</td>
| | RUL to RAL | Yes | Yes | must(up) | root | </tr>
| | | | +--------------+----------+ <tr>
| | | | | must(down) | RAL | <td align="center">RUL to root</td>
| +-------------+-----+-----+--------------+----------+ <td align="center">Yes</td>
| | RUL to RUL | Yes | Yes | must(up) | root | <td align="center">No</td>
| | | | +--------------+----------+ <td align="center">must</td>
| | | | | must(down) | 6LR | <td align="center">root</td>
+----------------+-------------+-----+-----+--------------+----------+ </tr>
]]></artwork></figure> <tr>
</t> <th align="center" rowspan="4">Leaf - Internet</th>
<td align="center">RAL to Int</td>
<section title="Non-Storing Mode: Interaction between Leaf and Root"> <td align="center">Yes</td>
<td align="center">No</td>
<t> <td align="center">may(up)</td>
In this section is described the communication flow <td align="center">root</td>
in Non Storing Mode (Non-SM) between, </tr>
</t> <tr>
<t> <td align="center">Int to RAL</td>
<list> <td align="center">Yes</td>
<t> <td align="center">Yes</td>
<td align="center">must</td>
<td align="center">RAL</td>
</tr>
<tr>
<td align="center">RUL to Int</td>
<td align="center">Yes</td>
<td align="center">No</td>
<td align="center">must</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">Int to RUL</td>
<td align="center">Yes</td>
<td align="center">Yes</td>
<td align="center">must</td>
<td align="center">6LR</td>
</tr>
<tr>
<th align="center" rowspan="8">Leaf - Leaf</th>
<td align="center" rowspan="2">RAL to RAL</td>
<td align="center" rowspan="2">Yes</td>
<td align="center" rowspan="2">Yes</td>
<td align="center">may(up)</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">RAL</td>
</tr>
<tr>
<td align="center" rowspan="2">RAL to RUL</td>
<td align="center" rowspan="2">Yes</td>
<td align="center" rowspan="2">Yes</td>
<td align="center">may(up)</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">6LR</td>
</tr>
<tr>
<td align="center" rowspan="2">RUL to RAL</td>
<td align="center" rowspan="2">Yes</td>
<td align="center" rowspan="2">Yes</td>
<td align="center">must(up)</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">RAL</td>
</tr>
<tr>
<td align="center" rowspan="2">RUL to RUL</td>
<td align="center" rowspan="2">Yes</td>
<td align="center" rowspan="2">Yes</td>
<td align="center">must(up)</td>
<td align="center">root</td>
</tr>
<tr>
<td align="center">must(down)</td>
<td align="center">6LR</td>
</tr>
</tbody>
</table>
<section numbered="true" toc="default">
<name>Non-Storing Mode: Interaction between Leaf and Root</name>
<t>
This section describes the communication flow
in Non-Storing mode (Non-SM) between the following:
</t>
<ul empty="true" spacing="normal">
<li>
RAL to root RAL to root
</t> </li>
<t> <li>
root to RAL root to RAL
</t> </li>
<t> <li>
RUL to root RUL to root
</t> </li>
<t> <li>
root to RUL root to RUL
</t> </li>
</list> </ul>
</t> <section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RAL to Root</name>
<section title="Non-SM: Example of Flow from RAL to root"> <t>
<t> In Non-Storing mode, the leaf node uses default
In non-storing mode the leaf node uses default
routing to send traffic to the root. The RPI must be included routing to send traffic to the root. The RPI must be included
since it contains the rank information, which is used to since it contains the Rank information, which is used to
avoid/detect loops. avoid and/or detect loops.
</t> </t>
<t>
<t> RAL (6LN) --&gt; 6LR_i --&gt; root(6LBR)
RAL (6LN) --> 6LR_i --> root(6LBR) </t>
</t> <t>
<t> For example, a communication flow could be:
For example, a communication flow could be: Node F --> Node D Node F --&gt; Node D --&gt; Node B --&gt; Node A (root)
--> Node B --> Node A (root) </t>
</t> <t>
<t> 6LR_i represents the intermediate routers from the source to
6LR_i represents the intermediate routers from source to dest the destination.
ination.
In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR) In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR)
that the packet goes through from source (RAL) to destination that the packet goes through, from the source (RAL) to the de
(6LBR). stination (6LBR).
</t> </t>
<t> <t>
This situation is the same case as storing mode. This situation is the same case as Storing mode.
</t> </t>
<t> <t>
The <xref target="NonStoring-summary-headers"/> summarizes what <xref target="NonStoring-summary-headers" format="default"/> su
headers are needed for this use case. mmarizes which headers are needed for this use case.
</t> </t>
<table anchor="NonStoring-summary-headers">
<t> <name>Non-SM: Summary of the Use of Headers from RAL to Root</name>
<figure title="Non-SM: Summary of the use of headers from RAL t <thead>
o root" anchor="NonStoring-summary-headers" align="center"> <tr>
<artwork><![CDATA[ <th align="center">Header</th>
+-----------+-----+-------+------+ <th align="center">RAL src</th>
| Header | RAL | 6LR_i | 6LBR | <th align="center">6LR_i</th>
| | src | | dst | <th align="center">6LBR dst</th>
+-----------+-----+-------+------+ </tr>
| Added | RPI | -- | -- | </thead>
| headers | | | | <tbody>
+-----------+-----+-------+------+ <tr>
| Modified | -- | RPI | -- | <th align="center">Added headers</th>
| headers | | | | <td align="center">RPI</td>
+-----------+-----+-------+------+ <td align="center">--</td>
| Removed | -- | -- | RPI | <td align="center">--</td>
| headers | | | | </tr>
+-----------+-----+-------+------+ <tr>
| Untouched | -- | -- | -- | <th align="center">Modified headers</th>
| headers | | | | <td align="center">--</td>
+-----------+-----+-------+------+ <td align="center">RPI</td>
]]></artwork></figure> <td align="center">--</td>
</t> </tr>
</section> <tr>
<th align="center">Removed headers</th>
<section anchor="nsroottoRAL" title=" Non-SM: Example of Flow fro <td align="center">--</td>
m root to RAL"> <td align="center">--</td>
<t> <td align="center">RPI</td>
In this case the flow comprises: </tr>
</t> <tr>
<t> <th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section anchor="nsroottoRAL" numbered="true" toc="default">
<name>Non-SM: Example of Flow from Root to RAL</name>
<t>
In this case, the flow comprises:
</t>
<t>
root (6LBR) --> 6LR_i --> RAL (6LN) root (6LBR) --&gt; 6LR_i --&gt; RAL (6LN)
</t> </t>
<t> <t>
For example, a communication flow could be: Node A (root) --> N For example, a communication flow could be:
ode B --> Node D --> Node F Node A (root) --&gt; Node B --&gt; Node D --&gt; Node F
</t> </t>
<t> <t>
6LR_i represents the intermediate routers from source to dest 6LR_i represents the intermediate routers from the source to
ination. the destination.
In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR) In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR)
that the packet goes through from source (6LBR) to destinatio that the packet goes through, from the source (6LBR) to the d
n (RAL). estination (RAL).
</t> </t>
<t> <t>
The 6LBR inserts an RH3, and an RPI. The 6LBR inserts an RH3 and an RPI.
No IPv6-in-IPv6 header is necessary as the traffic No IPv6-in-IPv6 header is necessary as the traffic
originates with a RPL aware node, the 6LBR. originates with a RPL-aware node, the 6LBR.
The destination is known to be RPL-aware because the root The destination is known to be RPL aware because the root
knows the whole topology in non-storing mode. knows the whole topology in Non-Storing mode.
</t> </t>
<t> <t>
The <xref target="NonStoring-root2rpl"/> summarizes what header <xref target="NonStoring-root2rpl" format="default"/> summarize
s are needed for this use case. s which headers are needed for this use case.
</t> </t>
<table anchor="NonStoring-root2rpl">
<t> <name>Non-SM: Summary of the Use of Headers from Root to RAL</name>
<figure title="Non-SM: Summary of the use of headers from root <thead>
to RAL" anchor="NonStoring-root2rpl" align="center"> <tr>
<artwork><![CDATA[ <th align="center">Header</th>
+-----------+----------+----------+----------+ <th align="center">6LBR src</th>
| Header | 6LBR | 6LR_i | RAL | <th align="center">6LR_i</th>
| | src | | dst | <th align="center">RAL dst</th>
+-----------+----------+----------+----------+ </tr>
| Added | RPI, RH3 | -- | -- | </thead>
| headers | | | | <tbody>
+-----------+----------+----------+----------+ <tr>
| Modified | -- | RPI, RH3 | -- | <th align="center">Added headers</th>
| headers | | | | <td align="center">RPI, RH3</td>
+-----------+----------+----------+----------+ <td align="center">--</td>
| Removed | -- | -- | RPI, RH3 | <td align="center">--</td>
| headers | | | | </tr>
+-----------+----------+----------+----------+ <tr>
| Untouched | -- | -- | -- | <th align="center">Modified headers</th>
| headers | | | | <td align="center">--</td>
+-----------+----------+----------+----------+ <td align="center">RPI, RH3</td>
]]></artwork></figure> <td align="center">--</td>
</t> </tr>
</section> <tr>
<th align="center">Removed headers</th>
<section title=" Non-SM: Example of Flow from root to RUL"> <td align="center">--</td>
<t> <td align="center">--</td>
In this case the flow comprises: <td align="center">RPI, RH3</td>
</t> </tr>
<t> <tr>
root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) <th align="center">Untouched headers</th>
</t> <td align="center">--</td>
<t> <td align="center">--</td>
For example, a communication flow could be: Node A (root <td align="center">--</td>
) --> Node B --> Node E --> Node G (RUL) </tr>
</t> </tbody>
<t> </table>
6LR_i represents the intermediate routers from source </section>
to destination. <section numbered="true" toc="default">
<name>Non-SM: Example of Flow from Root to RUL</name>
<t>
In this case, the flow comprises:
</t>
<t>
root (6LBR) --&gt; 6LR_i --&gt; RUL (IPv6 dst no
de)
</t>
<t>
For example, a communication flow could be:
Node A (root) --&gt; Node B --&gt; Node E --&gt; Node G (RUL)
</t>
<t>
6LR_i represents the intermediate routers from the sou
rce to the destination.
In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR) In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR)
that the packet goes through from source (6LBR) to des that the packet goes through, from the source (6LBR) t
tination (RUL). o the destination (RUL).
</t> </t>
<t> <t>
In the 6LBR, the RH3 is added; it is then modified at each In the 6LBR, the RH3 is added; it is then modified at each
intermediate 6LR (6LR_1 and so on), and it is fully co nsumed in the intermediate 6LR (6LR_1 and so on), and it is fully co nsumed in the
last 6LR (6LR_n) but is left in place. When the RPI i s added, the last 6LR (6LR_n) but is left in place. When the RPI i s added, the
RUL, which does not understand the RPI, will ignore it (per RUL, which does not understand the RPI, will ignore it (per
<xref target="RFC8200"/>); thus, encapsulation is not <xref target="RFC8200" format="default"/>); thus, enca
necessary. psulation is not necessary.
</t> </t>
<t> <t>
The <xref target="NonStoring-root2notrpl"/> depicts the <xref target="NonStoring-root2notrpl" format="default"/>
table that summarizes what headers are needed for this use case. summarizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="NonStoring-root2notrpl">
<figure title=" Non-SM: Summary of the use of headers fr <name>Non-SM: Summary of the Use of Headers from Root to RUL</name>
om root to RUL" anchor="NonStoring-root2notrpl" align="center"> <thead>
<artwork><![CDATA[ <tr>
+-----------+----------+--------------+----------------+----------+ <th align="center">Header</th>
| Header | 6LBR | 6LR_i | 6LR_n | RUL | <th align="center">6LBR src</th>
| | src | i=(1,..,n-1) | | dst | <th align="center">6LR_i i=(1,..,n-1)</th>
| | | | | | <th align="center">6LR_n</th>
+-----------+----------+--------------+----------------+----------+ <th align="center">RUL dst</th>
| Added | RPI, RH3 | -- | -- | -- | </tr>
| headers | | | | | </thead>
+-----------+----------+--------------+----------------+----------+ <tbody>
| Modified | -- | RPI, RH3 | RPI, | -- | <tr>
| headers | | | RH3(consumed) | | <th align="center">Added headers</th>
+-----------+----------+--------------+----------------+----------+ <td align="center">RPI, RH3</td>
| Removed | -- | -- | -- | -- | <td align="center">--</td>
| headers | | | | | <td align="center">--</td>
+-----------+----------+--------------+----------------+----------+ <td align="center">--</td>
| Untouched | -- | -- | -- | RPI, RH3 | </tr>
| headers | | | | (both | <tr>
| | | | | ignored) | <th align="center">Modified headers</th>
+-----------+----------+--------------+----------------+----------+ <td align="center">--</td>
]]></artwork></figure> <td align="center">RPI, RH3</td>
</t> <td align="center">RPI, RH3(consumed)</td>
</section> <td align="center">--</td>
</tr>
<section title="Non-SM: Example of Flow from RUL to root"> <tr>
<t> <th align="center">Removed headers</th>
In this case the flow comprises: <td align="center">--</td>
</t> <td align="center">--</td>
<t> <td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI, RH3 (both ignored)</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RUL to Root</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_i --
(6LBR) dst &gt; root (6LBR) dst
</t> </t>
<t> <t>
For example, a communication flow could be: Node G --> N For example, a communication flow could be:
ode E --> Node B --> Node A (root) Node G --&gt; Node E --&gt; Node B --&gt; Node A (root)
</t> </t>
<t> <t>
6LR_i represents the intermediate routers from source 6LR_i represents the intermediate routers from the sou
to destination. rce to the destination.
In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR) In this case, 1 &lt;= i &lt;= n, where n is the total number of routers (6LR)
that the packet goes through from source (RUL) to dest ination (6LBR). that the packet goes through, from the source (RUL) to the destination (6LBR).
For example, 6LR_1 (i=1) is the router that receives t he packets from the For example, 6LR_1 (i=1) is the router that receives t he packets from the
RUL. RUL.
</t> </t>
<t> <t>
In this case, the RPI is added by the first 6LR (6LR_1 ) (Node E), In this case, the RPI is added by the first 6LR (6LR_1 ) (Node E),
encapsulated in an IPv6-in-IPv6 header, and modified i n the encapsulated in an IPv6-in-IPv6 header, and modified i n the
subsequent 6LRs in the flow. The RPI and the subsequent 6LRs in the flow. The RPI and the
entire packet are consumed by the root. entire packet are consumed by the root.
</t> </t>
<t> <t>
The <xref target="NonStoring-notrpl2root"/> shows the ta <xref target="NonStoring-notrpl2root" format="default"/>
ble that summarizes what headers are needed for this use case. summarizes which headers are needed for this use case.
</t> </t>
<t> <table anchor="NonStoring-notrpl2root">
<figure title="Non-SM: Summary of the use of headers fro <name>Non-SM: Summary of the Use of Headers from RUL to Root</name>
m RUL to root" anchor="NonStoring-notrpl2root" align="center"> <thead>
<artwork><![CDATA[ <tr>
+---------+----+-----------------+-----------------+-----------------+ <th align="center">Header</th>
| |RUL | | | | <th align="center">RUL src</th>
| Header |src | 6LR_1 | 6LR_i | 6LBR dst | <th align="center">6LR_1</th>
| |node| | | | <th align="center">6LR_i</th>
+---------+----+-----------------+-----------------+-----------------+ <th align="center">6LBR dst</th>
| Added | -- |IPv6-in-IPv6(RPI)| -- | -- | </tr>
| headers | | | | | </thead>
+---------+----+-----------------+-----------------+-----------------+ <tbody>
| Modified| -- | -- | RPI | -- | <tr>
| headers | | | | | <th align="center">Added headers</th>
+---------+----+-----------------+-----------------+-----------------+ <td align="center">--</td>
| Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| <td align="center">IPv6-in-IPv6 (RPI)</td>
| headers | | | | | <td align="center">--</td>
+---------+----+-----------------+-----------------+-----------------+ <td align="center">--</td>
|Untouched| -- | -- | -- | -- | </tr>
| headers | | | | | <tr>
+---------+----+-----------------+-----------------+-----------------+ <th align="center">Modified headers</th>
]]></artwork></figure> <td align="center">--</td>
</t> <td align="center">--</td>
</section> <td align="center">RPI</td>
</section> <td align="center">--</td>
</tr>
<section title="Non-Storing Mode: Interaction between Leaf and In <tr>
ternet"> <th align="center">Removed headers</th>
<td align="center">--</td>
<t> <td align="center">--</td>
This section will describe the communication flow in Non Stor <td align="center">--</td>
ing Mode (Non-SM) between: <td align="center">IPv6-in-IPv6 (RPI)</td>
</t> </tr>
<t> <tr>
<list> <th align="center">Untouched headers</th>
<t> <td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
</section>
<section numbered="true" toc="default">
<name>Non-Storing Mode: Interaction between Leaf and Internet</name>
<t>
This section describes the communication flow in Non-Storing
mode (Non-SM) between the following:
</t>
<ul empty="true" spacing="normal">
<li>
RAL to Internet RAL to Internet
</t> </li>
<t> <li>
Internet to RAL Internet to RAL
</t> </li>
<t> <li>
RUL to Internet RUL to Internet
</t> </li>
<t> <li>
Internet to RUL Internet to RUL
</t> </li>
</list> </ul>
</t> <section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RAL to Internet</name>
<section title="Non-SM: Example of Flow from RAL to Internet"> <t>
<t> In this case, the flow comprises:
In this case the flow comprises: </t>
</t> <t>
<t> RAL (6LN) src --&gt; 6LR_i --&gt; root (6LBR) --
RAL (6LN) src --> 6LR_i --> root (6LBR) --> Inte &gt; Internet dst
rnet dst </t>
</t> <t>
<t> For example, a communication flow could be:
For example, a communication flow could be: Node F (RAL) Node F (RAL) --&gt; Node D --&gt; Node B --&gt; Node A --&gt; Internet.
--> Node D --> Node B --> Node A --> Internet.
Having the RAL information about the RPL domain, the pac ket may be encapsulated to the root when the destination is not in the RPL domai n of the RAL. Having the RAL information about the RPL domain, the pac ket may be encapsulated to the root when the destination is not in the RPL domai n of the RAL.
</t> </t>
<t> <t>
6LR_i represents the intermediate routers from source 6LR_i represents the intermediate routers from the sou
to destination, rce to the destination,
1 &lt;= i &lt;= n, where n is the total number of rout and 1 &lt;= i &lt;= n, where n is the total number of
ers (6LR) routers (6LR)
that the packet goes through from source (RAL) to 6LBR that the packet goes through, from the source (RAL) to
. the 6LBR.
</t> </t>
<t> <t>
In this case, the encapsulation from the RAL to th e root is optional. In this case, the encapsulation from the RAL to th e root is optional.
The simplest case is when the RPI gets to the Inte rnet (as the <xref target="NonStoring-rpl2int"/> shows it), knowing that the Int ernet is The simplest case is when the RPI gets to the Inte rnet (as the <xref target="NonStoring-rpl2int" format="default"/> shows it), kno wing that the Internet is
going to ignore it. going to ignore it.
</t> </t>
<t> <t>
The IPv6 flow label should be set to zero to aid The IPv6 flow label should be set to zero to aid
in compression <xref target="RFC8138"/>, and the 6LBR in compression <xref target="RFC8138" format="default"
will set it to a />, and the 6LBR will set it to a
non-zero value when sending towards the Internet <xre non-zero value when sending towards the Internet <xre
f target="RFC6437"/>. f target="RFC6437" format="default"/>.
</t> </t>
<t> <t>
The <xref target="NonStoring-rpl2int"/> summarizes what <xref target="NonStoring-rpl2int" format="default"/> sum
headers are needed for this use case marizes which headers are needed for this use case
when no encapsulation is used. when no encapsulation is used.
The <xref target="NonStoring-rpl2intwithIPIP"/> summariz es what headers are needed <xref target="NonStoring-rpl2intwithIPIP" format="defaul t"/> summarizes which headers are needed
for this use case when encapsulation to the root is used . for this use case when encapsulation to the root is used .
</t> </t>
<t> <table anchor="NonStoring-rpl2int">
<figure title="Non-SM: Summary of the use of headers fro <name>Non-SM: Summary of the Use of Headers from RAL to Internet with No Enca
m RAL to Internet with no encapsulation" anchor="NonStoring-rpl2int" align="cent psulation</name>
er"> <thead>
<artwork><![CDATA[ <tr>
+-----------+-----+-------+------+-----------+ <th align="center">Header</th>
| Header | RAL | 6LR_i | 6LBR | Internet | <th align="center">RAL src</th>
| | src | | | dst | <th align="center">6LR_i</th>
+-----------+-----+-------+------+-----------+ <th align="center">6LBR</th>
| Added | RPI | -- | -- | -- | <th align="center">Internet dst</th>
| headers | | | | | </tr>
+-----------+-----+-------+------+-----------+ </thead>
| Modified | -- | RPI | RPI | -- | <tbody>
| headers | | | | | <tr>
+-----------+-----+-------+------+-----------+ <th align="center">Added headers</th>
| Removed | -- | -- | -- | -- | <td align="center">RPI</td>
| headers | | | | | <td align="center">--</td>
+-----------+-----+-------+------+-----------+ <td align="center">--</td>
| Untouched | -- | -- | -- | RPI | <td align="center">--</td>
| headers | | | | (Ignored) | </tr>
+-----------+-----+-------+------+-----------+ <tr>
]]></artwork></figure> <th align="center">Modified headers</th>
</t> <td align="center">--</td>
<td align="center">RPI</td>
<t> <td align="center">RPI</td>
<figure title="Non-SM: Summary of the use of headers fro <td align="center">--</td>
m RAL to Internet with encapsulation to the root" anchor="NonStoring-rpl2intwith </tr>
IPIP" align="center"> <tr>
<artwork><![CDATA[ <th align="center">Removed headers</th>
+-----------+--------------+--------------+--------------+----------+ <td align="center">--</td>
| Header | RAL | 6LR_i | 6LBR | Internet | <td align="center">--</td>
| | src | | | dst | <td align="center">--</td>
+-----------+--------------+--------------+--------------+----------+ <td align="center">--</td>
| Added | IPv6-in-IPv6 | -- | -- | -- | </tr>
| headers | (RPI) | | | | <tr>
+-----------+--------------+--------------+--------------+----------+ <th align="center">Untouched headers</th>
| Modified | -- | | -- | -- | <td align="center">--</td>
| headers | | RPI | | | <td align="center">--</td>
+-----------+--------------+--------------+--------------+----------+ <td align="center">--</td>
| Removed | -- | -- | IPv6-in-IPv6 | -- | <td align="center">RPI (Ignored)</td>
| headers | | | (RPI) | | </tr>
+-----------+--------------+--------------+--------------+----------+ </tbody>
| Untouched | -- | -- | -- | -- | </table>
| headers | | | | |
+-----------+--------------+--------------+--------------+----------+
]]></artwork></figure>
</t>
</section>
<section title="Non-SM: Example of Flow from Internet to RAL"> <table anchor="NonStoring-rpl2intwithIPIP">
<t> <name>Non-SM: Summary of the Use of Headers from RAL to Internet with Encapsu
In this case the flow comprises: lation to the Root</name>
</t> <thead>
<t> <tr>
<th align="center">Header</th>
<th align="center">RAL src</th>
<th align="center">6LR_i</th>
<th align="center">6LBR</th>
<th align="center">Internet dst</th>
</tr>
</thead>
<tbody>
<tr>
<th align="center">Added headers</th>
<td align="center">IP6v6-in-IPv6 (RPI)</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">RPI</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IPv6-in-IPv6 (RPI)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Example of Flow from Internet to RAL</name>
<t>
In this case, the flow comprises:
</t>
<t>
Internet --> root (6LBR) --> 6LR_i --> RAL dst ( Internet --&gt; root (6LBR) --&gt; 6LR_i --&gt;
6LN) RAL dst (6LN)
</t> </t>
<t> <t>
For example, a communication flow could be: Internet --> For example, a communication flow could be:
Node A (root) --> Node B --> Node D --> Node F (RAL) Internet --&gt; Node A (root) --&gt; Node B --&gt; Node D --&gt; Node F (RAL)
</t> </t>
<t> <t>
6LR_i represents the intermediate routers from source to destination, 6LR_i represents the intermediate routers from source to destination,
1 &lt;= i &lt;= n, where n is the total number of rout and 1 &lt;= i &lt;= n, where n is the total number of
ers (6LR) routers (6LR)
that the packet goes through from 6LBR to destination that the packet goes through, from the 6LBR to the des
(RAL). tination (RAL).
</t> </t>
<t> <t>
The 6LBR must add an RH3 header. As the 6LBR will The 6LBR must add an RH3 header. As the 6LBR will
know the path and address of the target node, it can know the path and address of the target node, it can
address the IPv6-in-IPv6 header to that node. address the IPv6-in-IPv6 header to that node.
The 6LBR will zero the flow label upon entry in The 6LBR will zero the flow label upon entry in
order to aid compression <xref target="RFC8138"/>. order to aid compression <xref target="RFC8138" format
</t> ="default"/>.
<t> </t>
The <xref target="NonStoring-int2rpl"/> summarizes what <t>
headers are needed for this use case. <xref target="NonStoring-int2rpl" format="default"/> sum
</t> marizes which headers are needed for this use case.
<t> </t>
<figure title="Non-SM: Summary of the use of headers fro <table anchor="NonStoring-int2rpl">
m Internet to RAL" anchor="NonStoring-int2rpl" align="center"> <name>Non-SM: Summary of the Use of Headers from Internet to RAL</name>
<artwork><![CDATA[ <thead>
+-----------+----------+--------------+--------------+--------------+ <tr>
| Header | Internet | 6LBR | 6LR_i | RAL | <th align="center">Header</th>
| | src | | | dst | <th align="center">Internet src</th>
+-----------+----------+--------------+--------------+--------------+ <th align="center">6LBR</th>
| Added | -- | IPv6-in-IPv6 | -- | -- | <th align="center">6LR_i</th>
| headers | | (RH3, RPI) | | | <th align="center">RAL dst</th>
+-----------+----------+--------------+--------------+--------------+ </tr>
| Modified | -- | -- | IPv6-in-IPv6 | -- | </thead>
| headers | | | (RH3, RPI) | | <tbody>
+-----------+----------+--------------+--------------+--------------+ <tr>
| Removed | -- | -- | -- | IPv6-in-IPv6 | <th align="center">Added headers</th>
| headers | | | | (RH3, RPI) | <td align="center">--</td>
+-----------+----------+--------------+--------------+--------------+ <td align="center">IPv6-in-IPv6 (RH3, RPI)</td>
| Untouched | -- | -- | -- | -- | <td align="center">--</td>
| headers | | | | | <td align="center">--</td>
+-----------+----------+--------------+--------------+--------------+ </tr>
]]></artwork></figure> <tr>
</t> <th align="center">Modified headers</th>
</section> <td align="center">--</td>
<td align="center">--</td>
<section title="Non-SM: Example of Flow from RUL to Internet"> <td align="center">IPv6-in-IPv6 (RH3, RPI)</td>
<t> <td align="center">--</td>
In this case the flow comprises: </tr>
</t> <tr>
<t> <th align="center">Removed headers</th>
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) <td align="center">--</td>
--> Internet dst <td align="center">--</td>
</t> <td align="center">--</td>
<t> <td align="center">IPv6-in-IPv6 (RH3, RPI)</td>
For example, a communication flow could be: Node G --> N </tr>
ode E --> Node B --> Node A --> Internet <tr>
</t> <th align="center">Untouched headers</th>
<t> <td align="center">--</td>
6LR_i represents the intermediate routers from source <td align="center">--</td>
to destination, <td align="center">--</td>
1 &lt;= i &lt;= n, where n is the total number of rout <td align="center">--</td>
ers (6LRs) that the </tr>
packet goes through from the source (RUL) to the 6LBR, </tbody>
e.g., 6LR_1 (i=1). </table>
</t> </section>
<t> <section numbered="true" toc="default">
In this case the flow label is recommended to <name>Non-SM: Example of Flow from RUL to Internet</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_i --&gt; r
oot (6LBR) --&gt; Internet dst
</t>
<t>
For example, a communication flow could be:
Node G --&gt; Node E --&gt; Node B --&gt; Node A --&gt; Internet
</t>
<t>
6LR_i represents the intermediate routers from the sou
rce to the destination,
and 1 &lt;= i &lt;= n, where n is the total number of
routers (6LRs) that the
packet goes through, from the source (RUL) to the 6LBR
, e.g., 6LR_1 (i=1).
</t>
<t>
In this case, the flow label is recommended to
be zero in the RUL. As the RUL parent adds RPL headers in the RUL packet, be zero in the RUL. As the RUL parent adds RPL headers in the RUL packet,
the first 6LR (6LR_1) will add an RPI inside a n ew IPv6-in-IPv6 header. the first 6LR (6LR_1) will add an RPI inside a n ew IPv6-in-IPv6 header.
The IPv6-in-IPv6 header will be addressed to the The IPv6-in-IPv6 header will be addressed to the
root. This case is identical to the root. This case is identical to the
storing-mode case (see <xref target="sm-nRal2i" Storing mode case (see <xref target="sm-nRal2i"
/>). format="default"/>).
</t> </t>
<t> <t>
The <xref target="NonStoring-notrpl2int"/> shows the tab <xref target="NonStoring-notrpl2int" format="default"/>
le that summarizes what headers are needed for this use case. summarizes which headers are needed for this use case.
</t>
<t>
<figure title="Non-SM: Summary of the use of headers fro
m RUL to Internet" anchor="NonStoring-notrpl2int" align="center">
<artwork><![CDATA[
+---------+----+-------------+--------------+--------------+--------+
| Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet|
| |src | | [i=2,..,n] | | dst |
| |node| | | | |
+---------+----+-------------+--------------+--------------+--------+
| Added | -- |IP6-IP6(RPI) | -- | -- | -- |
| headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+
| Modified| -- | -- | RPI | -- | -- |
| headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+
| Removed | -- | -- | -- | IP6-IP6(RPI) | -- |
| headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+
|Untouched| -- | -- | -- | -- | -- |
| headers | | | | | |
+---------+----+-------------+--------------+--------------+--------+
]]></artwork></figure>
</t>
</section>
<section title="Non-SM: Example of Flow from Internet to RUL">
<t>
In this case the flow comprises:
</t>
<t>
Internet src --> root (6LBR) --> 6LR_i --> RUL ( </t>
IPv6 dst node) <table anchor="NonStoring-notrpl2int">
</t> <name>Non-SM: Summary of the Use of Headers from RUL to Internet</name>
<t> <thead>
For example, a communication flow could be: Internet --> <tr>
Node A (root) --> Node B --> Node E --> Node G <th align="center">Header</th>
</t> <th align="center">RUL src</th>
<t> <th align="center">6LR_1</th>
6LR_i represents the intermediate routers from source <th align="center">6LR_i i=(2,..,n)</th>
to destination, <th align="center">6LBR</th>
1 &lt;= i &lt;= n, where n is the total number of rout <th align="center">Internet dst</th>
ers (6LR) </tr>
that the packet goes through from 6LBR to RUL. </thead>
</t> <tbody>
<tr>
<th align="center">Added headers</th>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI)</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Example of Flow from Internet to RUL</name>
<t>
In this case, the flow comprises:
</t>
<t>
<t> Internet src --&gt; root (6LBR) --&gt; 6LR_i --&
gt; RUL (IPv6 dst node)
</t>
<t>
For example, a communication flow could be:
Internet --&gt; Node A (root) --&gt; Node B --&gt; Node E --&gt; Node G
</t>
<t>
6LR_i represents the intermediate routers from the sou
rce to the destination,
and 1 &lt;= i &lt;= n, where n is the total number of
routers (6LR)
that the packet goes through, from the 6LBR to the RUL
.
</t>
<t>
The 6LBR must add an RH3 header inside an IPv6-in-IPv6 The 6LBR must add an RH3 header inside an IPv6-in-IPv6
header. header.
The 6LBR will know the path, and will recognize The 6LBR will know the path and will recognize
that the final node is not a RPL capable node as that the final node is not a RPL-capable node as
it will have received the connectivity DAO from the it will have received the connectivity DAO from the
nearest 6LR. The 6LBR can therefore make the IPv6-in- IPv6 nearest 6LR. The 6LBR can therefore make the IPv6-in- IPv6
header destination be the last 6LR. header destination be the last 6LR.
The 6LBR will set to zero the flow label upon entry in The 6LBR will set to zero the flow label upon entry in
order to aid compression <xref target="RFC8138"/>. order to aid compression <xref target="RFC8138" format
</t> ="default"/>.
<t> </t>
The <xref target="NonStoring-int2notrpl"/> shows the tab <t>
le that summarizes what headers are needed for this use case. <xref target="NonStoring-int2notrpl" format="default"/>
</t> summarizes which headers are needed for this use case.
<t> </t>
<figure title="Non-SM: Summary of the use of headers fro <table anchor="NonStoring-int2notrpl">
m Internet to RUL." anchor="NonStoring-int2notrpl" align="center"> <name>Non-SM: Summary of the Use of Headers from Internet to RUL</name>
<artwork><![CDATA[ <thead>
+----------+--------+------------------+-----------+-----------+-----+ <tr>
| Header |Internet| 6LBR | 6LR_i | 6LR_n | RUL | <th align="center">Header</th>
| | src | | | | dst | <th align="center">Internet src</th>
+----------+--------+------------------+-----------+-----------+-----+ <th align="center">6LBR</th>
| Added | -- | IP6-IP6(RH3,RPI) | -- | -- | -- | <th align="center">6LR_i</th>
| headers | | | | | | <th align="center">6LR_n</th>
+----------+--------+------------------+-----------+-----------+-----+ <th align="center">RUL dst</th>
| Modified | -- | -- | IP6-IP6 | -- | -- | </tr>
| headers | | | (RH3,RPI) | | | </thead>
+----------+--------+------------------+-----------+-----------+-----+ <tbody>
| Removed | -- | -- | -- | IP6-IP6 | -- | <tr>
| headers | | | | (RH3,RPI) | | <th align="center">Added headers</th>
+----------+--------+------------------+-----------+-----------+-----+ <td align="center">--</td>
|Untouched | -- | -- | -- | -- | -- | <td align="center">IP6-IP6 (RH3, RPI)</td>
| headers | | | | | | <td align="center">--</td>
+----------+--------+------------------+-----------+-----------+-----+ <td align="center">--</td>
]]></artwork></figure> <td align="center">--</td>
</t> </tr>
</section> <tr>
<th align="center">Modified headers</th>
</section> <td align="center">--</td>
<td align="center">--</td>
<section title="Non-SM: Interaction between leaves"> <td align="center">IP6-IP6 (RH3, RPI)</td>
<td align="center">--</td>
<t> <td align="center">--</td>
In this section is described the communication flow </tr>
in Non Storing Mode (Non-SM) between, <tr>
</t> <th align="center">Removed headers</th>
<t> <td align="center">--</td>
<list> <td align="center">--</td>
<t> <td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Interaction between Leaves</name>
<t>
This section describes the communication flow
in Non-Storing mode (Non-SM) between the following:
</t>
<ul empty="true" spacing="normal">
<li>
RAL to RAL RAL to RAL
</t> </li>
<t> <li>
RAL to RUL RAL to RUL
</t> </li>
<t> <li>
RUL to RAL RUL to RAL
</t> </li>
<t> <li>
RUL to RUL RUL to RUL
</t> </li>
</list> </ul>
</t> <section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RAL to RAL</name>
<section title="Non-SM: Example of Flow from RAL to RAL"> <t>
<t> In this case, the flow comprises:
In this case the flow comprises: </t>
</t> <t>
<t> RAL src --&gt; 6LR_ia --&gt; root (6LBR) --&gt; 6LR_id
RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL --&gt; RAL dst
dst </t>
</t> <t>
<t> For example, a communication flow could be:
For example, a communication flow could be: Node F (RAL Node F (RAL src) --&gt; Node D --&gt; Node B --&gt; Node A (root) --&gt; Node B
src)--> Node D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RA --&gt; Node E --&gt; Node H (RAL dst)
L dst) </t>
</t> <t>
<t> 6LR_ia represents the intermediate routers from the so
6LR_ia represents the intermediate routers from source urce to the root,
to the root, and 1 &lt;= ia &lt;= n, where n is the total number of
1 &lt;= ia &lt;= n, where n is the total number of rou routers (6LR)
ters (6LR) that the packet goes through, from the RAL to the root
that the packet goes through from RAL to the root. .
</t> </t>
<t> <t>
6LR_id represents the intermediate routers from the ro ot to the destination, 6LR_id represents the intermediate routers from the ro ot to the destination,
1 &lt;= id &lt;= m, where m is the total number of the and 1 &lt;= id &lt;= m, where m is the total number of the
intermediate routers (6LR). intermediate routers (6LR).
</t> </t>
<t> <t>
This case involves only nodes in same RPL domain. This case involves only nodes in same RPL domain.
The originating node will add an RPI to the The originating node will add an RPI to the
original packet, and send the packet upwards. original packet and send the packet Upward.
</t> </t>
<t> <t>
The originating node may put the RPI (RPI1) into an IP v6-in-IPv6 The originating node may put the RPI (RPI1) into an IP v6-in-IPv6
header addressed to the root, so that the 6LBR can rem ove that header addressed to the root so that the 6LBR can remo ve that
header. If it does not, then the RPI1 is forwarded do wn from the header. If it does not, then the RPI1 is forwarded do wn from the
root in the inner header to no avail. root in the inner header to no avail.
</t> </t>
<t> <t>
The 6LBR will need to insert an RH3 header, which The 6LBR will need to insert an RH3 header, which
requires that it add an IPv6-in-IPv6 header. requires that it add an IPv6-in-IPv6 header.
It removes the RPI(RPI1), as it was contained in an It removes the RPI (RPI1), as it was contained in an
IPv6-in-IPv6 header addressed to it. Otherwise, there may IPv6-in-IPv6 header addressed to it. Otherwise, there may
be an RPI buried inside the inner IP header, be an RPI buried inside the inner IP header,
which should get ignored. The root inserts an RPI (RPI which should be ignored. The root inserts an RPI (RPI2
2) alongside the RH3. ) alongside the RH3.
</t> </t>
<t>
<t> Networks that use the RPL point-to-point extension <xref targ
Networks that use the RPL P2P extension <xref target="RFC6997 et="RFC6997" format="default"/>
" /> are essentially Non-Storing DODAGs and fall into this
are essentially non-storing DODAGs and fall into this scenario or the scenario given in <xref target="nsroottoRAL"
scenario or scenario <xref target="nsroottoRAL"/>, with format="default"/>, with
the originating node acting as 6LBR. the originating node acting as a 6LBR.
</t> </t>
<t> <t>
The <xref target="NonStoring-rpl2rpl"/> shows the table that su <xref target="NonStoring-rpl2rpl" format="default"/> summarizes
mmarizes what headers which headers
are needed for this use case when encapsulation to the root tak es place. are needed for this use case when encapsulation to the root tak es place.
</t> </t>
<t> <t>
The <xref target="NonStoring-rpl2rplnoIPIP"/> shows the table t <xref target="NonStoring-rpl2rplnoIPIP" format="default"/> summ
hat summarizes what headers arizes which headers
are needed for this use case when there is no encapsulation to the root. are needed for this use case when there is no encapsulation to the root.
Note that in the Modified headers row, going up in each 6LR_ia only the RPI1 is changed. Note that in the Modified headers row, going up in each 6LR_ia only the RPI1 is changed.
Going down, in each 6LR_id the IPv6 header is swapped with the Going down, in each 6LR_id the IPv6 header is swapped with the
RH3 so both are changed alongside with the RPI2.  RH3 so both are changed alongside with the RPI2.
</t> </t>
<t> <table anchor="NonStoring-rpl2rpl">
<figure title="Non-SM: Summary of the Use of Headers from RAL t <name>Non-SM: Summary of the Use of Headers from RAL to RAL with Encapsulatio
o RAL with encapsulation to the root." anchor="NonStoring-rpl2rpl" align="center n to the Root</name>
"> <thead>
<artwork><![CDATA[ <tr>
+---------+-------+----------+------------+----------+------------+ <th align="center">Header</th>
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | <th align="center">RAL src</th>
| | src | | | | dst | <th align="center">6LR_ia</th>
+---------+-------+----------+------------+----------+------------+ <th align="center">6LBR</th>
| Added |IP6-IP6| | IP6-IP6 | -- | -- | <th align="center">6LR_id</th>
| headers |(RPI1) | -- |(RH3-> RAL, | | | <th align="center">RAL dst</th>
| | | | RPI2) | | | </tr>
+---------+-------+----------+------------+----------+------------+ </thead>
| Modified| -- | | -- | IP6-IP6 | -- | <tbody>
| headers | | RPI1 | |(RH3,RPI2)| | <tr>
+---------+-------+----------+------------+----------+------------+ <th align="center">Added headers</th>
| Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | <td align="center">IP6-IP6 (RPI1)</td>
| headers | | | (RPI1) | | (RH3, | <td align="center">--</td>
| | | | | | RPI2) | <td align="center">IP6-IP6 (RH3 -&gt; RAL, RPI2)</td>
+---------+-------+----------+------------+----------+------------+ <td align="center">--</td>
|Untouched| -- | -- | -- | -- | -- | <td align="center">--</td>
| headers | | | | | | </tr>
+---------+-------+----------+------------+----------+------------+ <tr>
]]></artwork></figure> <th align="center">Modified headers</th>
</t> <td align="center">--</td>
<t> <td align="center">RPI1</td>
<figure title="Non-SM: Summary of the Use of Headers from RAL t <td align="center">--</td>
o RAL without encapsulation <td align="center">IP6-IP6 (RH3, RPI2)</td>
to the root." anchor="NonStoring-rpl2rplnoIPIP" align="cente <td align="center">--</td>
r"> </tr>
<artwork><![CDATA[ <tr>
+-----------+------+--------+---------+---------+---------+ <th align="center">Removed headers</th>
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | <td align="center">--</td>
+-----------+------+--------+---------+---------+---------+ <td align="center">--</td>
| Inserted | RPI1 | -- | IP6-IP6 | -- | -- | <td align="center">IP6-IP6 (RPI1)</td>
| headers | | | (RH3, | | | <td align="center">--</td>
| | | | RPI2) | | | <td align="center">IP6-IP6 (RH3, RPI2)</td>
+-----------+------+--------+---------+---------+---------+ </tr>
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | <tr>
| headers | | | | (RH3, | | <th align="center">Untouched headers</th>
| | | | | RPI2) | | <td align="center">--</td>
+-----------+------+--------+---------+---------+---------+ <td align="center">--</td>
| Removed | -- | -- | -- | -- | IP6-IP6 | <td align="center">--</td>
| headers | | | | | (RH3, | <td align="center">--</td>
| | | | | | RPI2) | <td align="center">--</td>
| | | | | | | </tr>
+-----------+------+--------+---------+---------+---------+ </tbody>
| Untouched | -- | -- | RPI1 | RPI1 | RPI1 | </table>
| headers | | | | |(Ignored)| <table anchor="NonStoring-rpl2rplnoIPIP">
+-----------+------+--------+---------+---------+---------+ <name>Non-SM: Summary of the Use of Headers from RAL to RAL without Encapsula
]]></artwork></figure> tion to the Root</name>
</t> <thead>
</section> <tr>
<th align="center">Header</th>
<section title="Non-SM: Example of Flow from RAL to RUL"> <th align="center">RAL src</th>
<t> <th align="center">6LR_ia</th>
In this case the flow comprises: <th align="center">6LBR</th>
</t> <th align="center">6LR_id</th>
<t> <th align="center">RAL dst</th>
RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv </tr>
6 dst node) </thead>
</t> <tbody>
<t> <tr>
For example, a communication flow could be: Node F (RAL) <th align="center">Added headers</th>
--> Node D --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL) <td align="center">RPI1</td>
</t> <td align="center">--</td>
<t> <td align="center">IP6-IP6 (RH3, RPI2)</td>
6LR_ia represents the intermediate routers from source <td align="center">--</td>
to the root, <td align="center">--</td>
1 &lt;= ia &lt;= n, where n is the total number of int </tr>
ermediate routers (6LR) <tr>
</t> <th align="center">Modified headers</th>
<t> <td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">RPI1</td>
<td align="center">RPI1 (Ignored)</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RAL to RUL</name>
<t>
In this case, the flow comprises:
</t>
<t>
RAL --&gt; 6LR_ia --&gt; root (6LBR) --&gt; 6LR_id --&g
t; RUL (IPv6 dst node)
</t>
<t>
For example, a communication flow could be:
Node F (RAL) --&gt; Node D --&gt; Node B --&gt; Node A (root) --&gt; Node B --&g
t; Node E --&gt; Node G (RUL)
</t>
<t>
6LR_ia represents the intermediate routers from the so
urce to the root,
and 1 &lt;= ia &lt;= n, where n is the total number of
intermediate routers (6LR).
</t>
<t>
6LR_id represents the intermediate routers from the ro ot to the destination, 6LR_id represents the intermediate routers from the ro ot to the destination,
1 &lt;= id &lt;= m, where m is the total number of th e and 1 &lt;= id &lt;= m, where m is the total number o f the
intermediate routers (6LRs). intermediate routers (6LRs).
</t> </t>
<t> <t>
As in the previous case, the RAL (6LN) may insert an R PI (RPI1) As in the previous case, the RAL (6LN) may insert an R PI (RPI1)
header which must be in an IPv6-in-IPv6 header address ed to header, which must be in an IPv6-in-IPv6 header addres sed to
the root so that the 6LBR can remove this RPI. the root so that the 6LBR can remove this RPI.
The 6LBR will then insert an RH3 inside a new IPv6-in- IPv6 The 6LBR will then insert an RH3 inside a new IPv6-in- IPv6
header addressed to the last 6LR_id (6LR_id = m) along side the insertion of RPI2. header addressed to the last 6LR_id (6LR_id = m) along side the insertion of RPI2.
</t> </t>
<t> <t>
If the originating node does not put the RPI (RPI1) in to an IPv6-in-IPv6 If the originating node does not put the RPI (RPI1) in to an IPv6-in-IPv6
header addressed to the root. Then, the RPI1 is forwar ded down from the header addressed to the root, then the RPI1 is forward ed down from the
root in the inner header to no avail. root in the inner header to no avail.
</t> </t>
<t> <t>
The <xref target="NonStoring-rpl2notrpl"/> shows the tab <xref target="NonStoring-rpl2notrpl" format="default"/>
le that summarizes what headers summarizes which headers
are needed for this use case when encapsulation to the r oot takes place. are needed for this use case when encapsulation to the r oot takes place.
The <xref target="NonStoring-rpl2notrplnoIPIP"/> shows t he table that summarizes what headers <xref target="NonStoring-rpl2notrplnoIPIP" format="defau lt"/> summarizes which headers
are needed for this use case when no encapsulation to th e root takes place. are needed for this use case when no encapsulation to th e root takes place.
</t> </t>
<t> <table anchor="NonStoring-rpl2notrpl">
<figure title="Non-SM: Summary of the use of headers fr <name>Non-SM: Summary of the Use of Headers from RAL to RUL with Encapsulatio
om RAL n to the Root</name>
to RUL with encapsulation to the root." anchor="NonStori <thead>
ng-rpl2notrpl" align="center"> <tr>
<artwork><![CDATA[ <th align="center">Header</th>
+-----------+---------+---------+---------+---------+---------+------+ <th align="center">RAL src</th>
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | <th align="center">6LR_ia</th>
| | src | | | | | dst | <th align="center">6LBR</th>
| | node | | | | | node | <th align="center">6LR_id</th>
+-----------+---------+---------+---------+---------+---------+------+ <th align="center">6LR_m</th>
| Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- | <th align="center">RUL dst</th>
| headers | (RPI1) | -- | (RH3, | | | | </tr>
| | | | RPI2) | | | | </thead>
+-----------+---------+---------+---------+---------+---------+------+ <tbody>
| Modified | -- | | -- | IP6-IP6 | | -- | <tr>
| headers | | RPI1 | | (RH3, | -- | | <th align="center">Added headers</th>
| | | | | RPI2) | | | <td align="center">IP6-IP6 (RPI1)</td>
+-----------+---------+---------+---------+---------+---------+------+ <td align="center">--</td>
| Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | <td align="center">IP6-IP6 (RH3, RPI2)</td>
| headers | | | (RPI1) | | (RH3, | | <td align="center">--</td>
| | | | | | RPI2) | | <td align="center">--</td>
+-----------+---------+---------+---------+---------+---------+------+ <td align="center">--</td>
| Untouched | -- | -- | -- | -- | -- | -- | </tr>
| headers | | | | | | | <tr>
+-----------+---------+---------+---------+---------+---------+------+ <th align="center">Modified headers</th>
]]></artwork></figure> <td align="center">--</td>
</t> <td align="center">RPI1</td>
<t> <td align="center">--</td>
<figure title="Non-SM: Summary of the use of headers fr <td align="center">IP6-IP6 (RH3, RPI2)</td>
om RAL <td align="center">--</td>
to RUL without encapsulation to the root." anchor="NonSt <td align="center">--</td>
oring-rpl2notrplnoIPIP" align="center"> </tr>
<artwork><![CDATA[ <tr>
+-----------+------+--------+---------+---------+---------+---------+ <th align="center">Removed headers</th>
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL | <td align="center">--</td>
| | src | | | | | dst | <td align="center">--</td>
| | node | | | | | node | <td align="center">IP6-IP6 (RPI1)</td>
+-----------+------+--------+---------+---------+---------+---------+ <td align="center">--</td>
| Inserted | RPI1 | -- | IP6-IP6 | -- | -- | -- | <td align="center">IP6-IP6 (RH3, RPI2)</td>
| headers | | | (RH3, | | | | <td align="center">--</td>
| | | | RPI2) | | | | </tr>
+-----------+------+--------+---------+---------+---------+---------+ <tr>
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- | <th align="center">Untouched headers</th>
| headers | | | | (RH3, | | | <td align="center">--</td>
| | | | | RPI2) | | | <td align="center">--</td>
+-----------+------+--------+---------+---------+---------+---------+ <td align="center">--</td>
| Removed | -- | -- | -- | -- | IP6-IP6 | -- | <td align="center">--</td>
| headers | | | | | (RH3, | | <td align="center">--</td>
| | | | | | RPI2) | | <td align="center">--</td>
+-----------+------+--------+---------+---------+---------+---------+ </tr>
| Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | </tbody>
| headers | | | | | |(Ignored)| </table>
+-----------+------+--------+---------+---------+---------+---------+ <table anchor="NonStoring-rpl2notrplnoIPIP">
<name>Non-SM: Summary of the Use of Headers from RAL to RUL without Encapsula
]]></artwork></figure> tion to the Root</name>
</t> <thead>
<tr>
</section> <th align="center">Header</th>
<th align="center">RAL src</th>
<section title="Non-SM: Example of Flow from RUL to RAL"> <th align="center">6LR_ia</th>
<th align="center">6LBR</th>
<t> <th align="center">6LR_id</th>
In this case the flow comprises: <th align="center">6LR_n</th>
</t> <th align="center">RUL dst</th>
<t> </tr>
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR </thead>
) --> 6LR_id --> RAL dst (6LN) <tbody>
</t> <tr>
<t> <th align="center">Added headers</th>
For example, a communication flow could be: Node G (RUL) <td align="center">RPI1</td>
--> Node E --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL) <td align="center">--</td>
</t> <td align="center">IP6-IP6 (RH3, RPI2)</td>
<t> <td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">RPI1</td>
<td align="center">RPI1</td>
<td align="center">RPI1 (ignored)</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RUL to RAL</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_ia --&gt; r
oot (6LBR) --&gt; 6LR_id --&gt; RAL dst (6LN)
</t>
<t>
For example, a communication flow could be:
Node G (RUL) --&gt; Node E --&gt; Node B --&gt; Node A (root) --&gt; Node B --&g
t; Node E --&gt; Node H (RAL)
</t>
<t>
6LR_ia represents the intermediate routers from source to the root, 6LR_ia represents the intermediate routers from source to the root,
1 &lt;= ia &lt;= n, where n is the total number of int and 1 &lt;= ia &lt;= n, where n is the total number of
ermediate routers (6LR) intermediate routers (6LR).
</t> </t>
<t> <t>
6LR_id represents the intermediate routers from the ro ot to the destination, 6LR_id represents the intermediate routers from the ro ot to the destination,
1 &lt;= id &lt;= m, where m is the total number of the and 1 &lt;= id &lt;= m, where m is the total number of the
intermediate routers (6LR). intermediate routers (6LR).
</t> </t>
<t> <t>
In this scenario the RPI (RPI1) is added by the first In this scenario, the RPI (RPI1) is added by the first
6LR (6LR_1) inside an 6LR (6LR_1) inside an
IPv6-in-IPv6 header addressed to the root. The 6LBR w ill IPv6-in-IPv6 header addressed to the root. The 6LBR w ill
remove this RPI, and add its own IPv6-in-IPv6 header remove this RPI and add its own IPv6-in-IPv6 header
containing an RH3 header and an RPI (RPI2). containing an RH3 header and an RPI (RPI2).
</t> </t>
<t> <t>
The <xref target="NonStoring-notrpl2rpl"/> shows the tab <xref target="NonStoring-notrpl2rpl" format="default"/>
le that summarizes what headers are needed for this use case. summarizes which headers are needed for this use case.
</t>
<t>
<figure title="Non-SM: Summary of the use of headers fro
m RUL to RAL." anchor="NonStoring-notrpl2rpl" align="center">
<artwork><![CDATA[
+----------+------+---------+---------+---------+---------+---------+
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL |
| | src | | | | | dst |
| | node | | | | | node |
+----------+------+---------+---------+---------+---------+---------+
| Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- |
| headers | | (RPI1) | | (RH3, | | |
| | | | | RPI2) | | |
+----------+------+---------+---------+---------+---------+---------+
| Modified | -- | | | -- | IP6-IP6 | -- |
| headers | | -- | RPI1 | | (RH3, | |
| | | | | | RPI2) | |
+----------+------+---------+---------+---------+---------+---------+
| Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 |
| headers | | -- | | (RPI1) | | (RH3, |
| | | | | | | RPI2) |
+----------+------+---------+---------+---------+---------+---------+
|Untouched | -- | -- | -- | -- | -- | -- |
| headers | | | | | | |
+----------+------+---------+---------+---------+---------+---------+
]]></artwork></figure>
</t>
</section>
<section title="Non-SM: Example of Flow from RUL to RUL">
<t> </t>
In this case the flow comprises: <table anchor="NonStoring-notrpl2rpl">
</t> <name>Non-SM: Summary of the Use of Headers from RUL to RAL</name>
<t> <thead>
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR <tr>
) --> 6LR_id --> RUL (IPv6 dst node) <th align="center">Header</th>
</t> <th align="center">RUL src</th>
<t> <th align="center">6LR_1</th>
For example, a communication flow could be: Node G --> N <th align="center">6LR_ia</th>
ode E --> Node B --> Node A (root) --> Node C --> Node J <th align="center">6LBR</th>
</t> <th align="center">6LR_id</th>
<t> <th align="center">RAL dst</th>
6LR_ia represents the intermediate routers from source </tr>
to the root, </thead>
1 &lt;= ia &lt;= n, where n is the total number of int <tbody>
ermediate routers (6LR) <tr>
</t> <th align="center">Added headers</th>
<t> <td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Non-SM: Example of Flow from RUL to RUL</name>
<t>
In this case, the flow comprises:
</t>
<t>
RUL (IPv6 src node) --&gt; 6LR_1 --&gt; 6LR_ia --&gt; r
oot (6LBR) --&gt; 6LR_id --&gt; RUL (IPv6 dst node)
</t>
<t>
For example, a communication flow could be:
Node G --&gt; Node E --&gt; Node B --&gt; Node A (root) --&gt; Node C --&gt; Nod
e J
</t>
<t>
6LR_ia represents the intermediate routers from the so
urce to the root,
and 1 &lt;= ia &lt;= n, where n is the total number of
intermediate routers (6LR).
</t>
<t>
6LR_id represents the intermediate routers from the ro ot to the destination, 6LR_id represents the intermediate routers from the ro ot to the destination,
1 &lt;= id &lt;= m, where m is the total number of the and 1 &lt;= id &lt;= m, where m is the total number of the
intermediate routers (6LR). intermediate routers (6LR).
</t> </t>
<t> <t>
This scenario is the combination of the previous two c ases. This scenario is the combination of the previous two c ases.
</t> </t>
<t> <t>
The <xref target="NonStoring-notrpl2notrpl"/> shows the <xref target="NonStoring-notrpl2notrpl" format="default"
table that summarizes what headers are needed for this use case. /> summarizes which headers are needed for this use case.
</t>
<t>
<figure title="Non-SM: Summary of the use of headers fro
m RUL to RUL" anchor="NonStoring-notrpl2notrpl" align="center">
<artwork><![CDATA[
+---------+------+-------+-------+---------+-------+---------+------+
| Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL |
| | src | | | | | | dst |
| | node | | | | | | node |
+---------+------+-------+-------+---------+-------+---------+------+
| Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI1)| | (RH3, | | | |
| | | | | RPI2) | | | |
+---------+------+-------+-------+---------+-------+---------+------+
| Modified| -- | -- | | -- |IP6-IP6| -- | -- |
| headers | | | RPI1 | | (RH3, | | |
| | | | | | RPI2)| | |
+---------+------+-------+-------+---------+-------+---------+------+
| Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- |
| headers | | | | (RPI1) | | (RH3, | |
| | | | | | | RPI2) | |
+---------+------+-------+-------+---------+-------+---------+------+
|Untouched| -- | -- | -- | -- | -- | -- | -- |
| headers | | | | | | | |
+---------+------+-------+-------+---------+-------+---------+------+
]]></artwork></figure>
</t>
</section>
</section>
</section>
<section title="Operational Considerations of supporting </t>
RUL-leaves" anchor="notrplaware"> <table anchor="NonStoring-notrpl2notrpl">
<t> <name>Non-SM: Summary of the Use of Headers from RUL to RUL</name>
<thead>
<tr>
<th align="center">Header</th>
<th align="center">RUL src</th>
<th align="center">6LR_1</th>
<th align="center">6LR_ia</th>
<th align="center">6LBR</th>
<th align="center">6LR_id</th>
<th align="center">6LR_m</th>
<th align="center">RUL dst</th>
</tr>
</thead>
<tbody>
<tr>
<th align="center">Added headers</th>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Modified headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">RPI1</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Removed headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RPI1)</td>
<td align="center">--</td>
<td align="center">IP6-IP6 (RH3, RPI2)</td>
<td align="center">--</td>
</tr>
<tr>
<th align="center">Untouched headers</th>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
<td align="center">--</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<section anchor="notrplaware" numbered="true" toc="default">
<name>Operational Considerations of Supporting RULs</name>
<t>
Roughly half of the situations described in this document Roughly half of the situations described in this document
involve leaf ("host") nodes that do not speak RPL. These nodes involve leaf ("host") nodes that do not speak RPL. These nodes
fall into two further categories: ones that drop a packet fall into two further categories: ones that drop a packet
that have RPI or RH3 headers, and ones that continue to that have RPI or RH3 headers, and ones that continue to
process a packet that has RPI and/or RH3 headers. process a packet that has RPI and/or RH3 headers.
</t> </t>
<t> <t>
<xref target="RFC8200" /> provides for new rules that suggest <xref target="RFC8200" format="default"/> provides for new rules t
hat suggest
that nodes that have not been configured (explicitly) to that nodes that have not been configured (explicitly) to
examine Hop-by-Hop headers, should ignore those headers, and examine Hop-by-Hop Options headers should ignore those headers and
continue processing the packet. Despite this, and despite the continue processing the packet. Despite this, and despite the
switch from 0x63 to 0x23, there may be nodes that are pre-RFC8200, switch from 0x63 to 0x23, there may be nodes that predate RFC 8200
or simply intolerant. Those nodes will drop packets that or are simply intolerant. Those nodes will drop packets that
continue to have RPL artifacts in them. In general, such continue to have RPL artifacts in them. In general, such
nodes can not be easily supported in RPL LLNs. nodes cannot be easily supported in RPL LLNs.
</t> </t>
<t> <t>
There are some specific cases where it is possible to remove There are some specific cases where it is possible to remove
the RPL artifacts prior to forwarding the packet to the leaf the RPL artifacts prior to forwarding the packet to the leaf
host. The critical thing is that the artifacts have been host. The critical thing is that the artifacts have been
inserted by the RPL root inside an IPv6-in-IPv6 header, and inserted by the RPL root inside an IPv6-in-IPv6 header, and
that the header has been addressed to the 6LR immediately prior that the header has been addressed to the 6LR immediately prior
to the leaf node. In that case, in the process of removing the to the leaf node. In that case, in the process of removing the
IPv6-in-IPv6 header, the artifacts can also be removed. IPv6-in-IPv6 header, the artifacts can also be removed.
</t> </t>
<t> <t>
The above case occurs whenever traffic originates from the The above case occurs whenever traffic originates from the
outside the LLN (the "Internet" cases above), and non-storing outside the LLN (the "Internet" cases above), and Non-Storing
mode is used. In non-storing mode, the RPL root knows the exact t mode is used. In Non-Storing mode, the RPL root knows the exact t
opology opology
(as it must create the RH3 header) and therefore knows which 6LR i s prior to the (as it must create the RH3 header) and therefore knows which 6LR i s prior to the
leaf. For example, in <xref target="fig_CommonTopology"/>, Node E is the 6LR prior to leaf leaf. For example, in <xref target="fig_CommonTopology" format="d efault"/>, Node E is the 6LR prior to leaf
Node G, or Node C is the 6LR prior to leaf Node J. Node G, or Node C is the 6LR prior to leaf Node J.
</t> </t>
<t> <t>
Traffic originating from the RPL root (such as when the data Traffic originating from the RPL root (such as when the data
collection system is co-located on the RPL root), does not collection system is co-located on the RPL root), does not
require an IPv6-in-IPv6 header (in storing or non-storing mode), a s the packet require an IPv6-in-IPv6 header (in Storing or Non-Storing mode), a s the packet
is originating at the root, and the root can insert the RPI is originating at the root, and the root can insert the RPI
and RH3 headers directly into the packet, as it is formed. and RH3 headers directly into the packet as it is formed.
Such a packet is slightly smaller, but only can be sent to Such a packet is slightly smaller, but can only be sent to
nodes (whether RPL aware or not), that will tolerate the nodes (whether RPL aware or not) that will tolerate the
RPL artifacts. RPL artifacts.
</t> </t>
<t> <t>
An operator that finds itself with a high amount of traffic from t he An operator that finds itself with a high amount of traffic from t he
RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 RPL root to RPL-unaware leaves will have to do IPv6-in-IPv6
encapsulation if the leaf is not tolerant of the RPL artifacts. encapsulation if the leaf is not tolerant of the RPL artifacts.
Such an operator could otherwise omit this unnecessary header Such an operator could otherwise omit this unnecessary header
if it was certain of the properties of the leaf. if it was certain of the properties of the leaf.
</t> </t>
<t> <t>
As storing mode can not know the final path of the traffic, As the Storing mode cannot know the final path of the traffic,
intolerant (that drop packets with RPL artifacts) leaf nodes intolerant leaf nodes, which drop packets with RPL artifacts,
can not be supported. cannot be supported.
</t> </t>
</section> </section>
<section anchor="sec_op_con_0x23" numbered="true" toc="default">
<section title="Operational considerations of introducing 0x23"> <name>Operational Considerations of Introducing 0x23</name>
<t> <t>
This section describes the operational considerations of introducing the new RPI Option Type of 0x23. This section describes the operational considerations of introducing the new RPI Option Type of 0x23.
</t> </t>
<t>
<t> During bootstrapping, the node receives the DIO with the informatio
During bootstrapping the node gets the DIO with the information of n of RPI Option Type, indicating
RPI Option Type, indicating the new RPI in the DODAG Configuration option flag.
the new RPI in the DODAG Configuration option Flag. The DODAG root is in charge of configuring the current network with
The DODAG root is in charge to configure the current network to the the new value, through DIO
new value, through DIO messages, and determining when all the nodes have been set with the
messages and when all the nodes are set with the new value. The DOD new value. The DODAG should change to a new DODAG version.
AG should change to a new DODAG version.
In case of rebooting, the node does not remember the RPI Option Typ e. In case of rebooting, the node does not remember the RPI Option Typ e.
Thus, the DIO is sent with a flag indicating the new RPI Option Typ e. Thus, the DIO is sent with a flag indicating the new RPI Option Typ e.
</t> </t>
<t> <t>
The DODAG Configuration option is contained in a RPL DIO message, whi The DODAG Configuration option is contained in a RPL DIO message, whi
ch contains a unique DTSN counter. ch contains a unique Destination Advertisement Trigger Sequence Number (DTSN) co
unter.
The leaf nodes respond to this message with DAO messages containing t he same DTSN. The leaf nodes respond to this message with DAO messages containing t he same DTSN.
This is a normal part of RPL routing; the RPL root therefore knows wh en the updated This is a normal part of RPL routing; the RPL root therefore knows wh en the updated
DODAG Configuration option has been seen by all nodes. DODAG Configuration option has been seen by all nodes.
</t> </t>
<t> <t>
Before the migration happens, all the RPL-aware nodes should suppor Before the migration happens, all the RPL-aware nodes should suppor
t both values . t both values.
The migration procedure is triggered when the DIO is sent with the flag The migration procedure is triggered when the DIO is sent with the flag
indicating the new RPI Option Type. indicating the new RPI Option Type.
Namely, it remains at 0x63 until it is sure that the network is cap able of 0x23, then it abruptly changes to 0x23. Namely, it remains at 0x63 until it is sure that the network is cap able of 0x23, then it abruptly changes to 0x23.
The 0x23 RPI Option allows to send packets to not-RPL nodes. The no The 0x23 RPI Option allows the sending of packets to non-RPL nodes.
t-RPL nodes should ignore the option and continue processing the packets. The non-RPL nodes should ignore the option and continue processing the packets.
</t> </t>
<t> <t>
As mentioned previously, indicating the new RPI in the DODAG Config uration option flag is a way to avoid the flag day As mentioned previously, indicating the new RPI in the DODAG Config uration option flag is a way to avoid the flag day
(abrupt changeover) in a network using 0x63 as the RPI Option Type value. It is suggested that RPL implementations (abrupt changeover) in a network using 0x63 as the RPI Option Type value. It is suggested that RPL implementations
accept both 0x63 and 0x23 RPI Option type values when processing th accept both 0x63 and 0x23 RPI Option Type values when processing th
e header to enable interoperability. e header to enable interoperability.
</t> </t>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<section numbered="true" toc="default">
<name>Option Type in RPL Option</name>
<t>
This document updates the registration made in the
"Destination Options and Hop-by-Hop Options" subregistry <xref targe
t="RFC6553" format="default"/> from 0x63 to 0x23
as shown in <xref target="fig_IanaRPIOption" format="default"/>.
</t>
<table anchor="fig_IanaRPIOption">
<name>Option Type in RPL Option</name>
<thead>
<tr>
<th rowspan="2" colspan="1" align="center">Hex Value</th>
<th rowspan="1" colspan="3" align="center">Binary Value</th>
<th rowspan="2" colspan="1" align="center">Description</th>
<th rowspan="2" colspan="1" align="center">Reference</th>
</tr>
<tr>
<th align="center">act</th>
<th align="center">chg</th>
<th align="center">rest</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0x23</td>
<td align="center">00</td>
<td align="center">1</td>
<td align="center">00011</td>
<td align="center">RPL Option</td>
<td align="center">This document</td>
</tr>
<tr>
<td align="center">0x63</td>
<td align="center">01</td>
<td align="center">1</td>
<td align="center">00011</td>
<td align="center">RPL Option (DEPRECATED)</td>
<td align="center"><xref target="RFC6553" format="default"/>, this docu
ment</td>
</tr>
</tbody>
</table>
<t> The "DODAG Configuration
Option Flags for MOP 0..6" subregistry is updated as follows (<xref ta
rget="fig_RPIflagdayConfOption" format="default"/>):
</t>
<table anchor="fig_RPIflagdayConfOption">
<name>DODAG Configuration Option Flag to Indicate the RPI Flag Day</name>
<thead>
<tr>
<th align="center">Bit Number</th>
<th align="center">Capability Description</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">3</td>
<td align="center">RPI 0x23 enable</td>
<td align="center">This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec_op_flags_reg" numbered="true" toc="default">
<section title="IANA Considerations" anchor="iana"> <name>Change to the "DODAG Configuration Option Flags" Subregistry</name
<section title="Option Type in RPL Option"> >
<t> <t>
This document updates the registration made in <xref target="RFC6553 IANA has changed the name of the "DODAG
"/> Configuration Option Flags" subregistry to "DODAG Configuration Opti
Destination Options and Hop-by-Hop Options registry from 0x63 to 0x2 on Flags
3
as shown in <xref target="fig_IanaRPIOption"/>.
</t>
<t>
<figure title="Option Type in RPL Option.(*)represents this document
" anchor="fig_IanaRPIOption" align="center">
<artwork> <![CDATA[
+-------+-------------------+------------------------+---------- -+
| Hex | Binary Value | Description | Reference |
+ Value +-------------------+ + +
| | act | chg | rest | | |
+-------+-----+-----+-------+------------------------+------------+
| 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)|
+-------+-----+-----+-------+------------------------+------------+
| 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] |
| | | | | |[RFCXXXX](*)|
+-------+-----+-----+-------+------------------------+------------+
]]></artwork></figure>
</t>
<t> DODAG Configuration
option is updated as follows (<xref target="fig_RPIflagdayConfOption"/
>):
</t>
<t>
<figure title="DODAG Configuration option Flag to indicate the RPI-f
lag-day." anchor="fig_RPIflagdayConfOption" align="center">
<artwork> <![CDATA[
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
]]></artwork></figure>
</t>
</section>
<section title="Change to the DODAG Configuration Options Flags registry
">
<t>
This document requests IANA to change the name of the "DODAG
Configuration Option Flags" registry to "DODAG Configuration Option
Flags
for MOP 0..6". for MOP 0..6".
</t> </t>
<t>The subregistry references this document for this change.</t>
<t>This document requests to be mentioned as a reference for this chan
ge.</t>
</section>
<section title="Change MOP value 7 to Reserved">
<t>
This document requests the changing the registration status of value
7 in
the Mode of Operation registry from Unassigned to Reserved. This ch
ange
is in support of future work.
</t>
<t>
This document requests to be mentioned as a reference for this entry
in
the registry.
</t>
</section>
</section> </section>
<section anchor="sec_mop_val_change" numbered="true" toc="default">
<name>Change MOP Value 7 to Reserved</name>
<t>
IANA has changed the registration status of value 7 in
the "Mode of Operation" subregistry from Unassigned to Reserved. Th
is change
is in support of future work.
</t>
<section anchor="Security" title="Security Considerations"> <t>
<t> This document is listed as a reference for this entry in
The security considerations covered in <xref target="RFC6553"/> and the subregistry.
<xref target="RFC6554"/> apply when the packets are in the RPL </t>
</section>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The security considerations covered in <xref target="RFC6553" forma
t="default"/> and
<xref target="RFC6554" format="default"/> apply when the packets ar
e in the RPL
Domain. Domain.
</t> </t>
<t> <t>
The IPv6-in-IPv6 mechanism described in this document is much more The IPv6-in-IPv6 mechanism described in this document is much more
limited than the general mechanism described in <xref limited than the general mechanism described in <xref target="RFC247
target="RFC2473"/>. The willingness of each node in the LLN to 3" format="default"/>. The willingness of each node in the LLN to
decapsulate packets and forward them could be exploited by nodes to decapsulate packets and forward them could be exploited by nodes to
disguise the origin of an attack. disguise the origin of an attack.
</t> </t>
<t>
<t>
While a typical LLN may be a very poor origin for attack traffic While a typical LLN may be a very poor origin for attack traffic
(as the networks tend to be very slow, (as the networks tend to be very slow,
and the nodes often have very low duty cycles), given enough and the nodes often have very low duty cycles), given enough
nodes, LLNs could still have a nodes, LLNs could still have a
significant impact, particularly if the attack is targeting another LLN. significant impact, particularly if the attack is targeting another LLN.
Additionally, some uses of RPL involve large backbone ISP scale Additionally, some uses of RPL involve large-backbone, ISP-scale
equipment <xref target="I-D.ietf-anima-autonomic-control-plane"/>, equipment <xref target="I-D.ietf-anima-autonomic-control-plane" form
which may be equipped with multiple 100Gb/s interfaces. at="default"/>,
</t> which may be equipped with multiple 100 Gb/s interfaces.
<t> </t>
<t>
Blocking or careful filtering of IPv6-in-IPv6 traffic entering the L LN as Blocking or careful filtering of IPv6-in-IPv6 traffic entering the L LN as
described above will make sure that any attack that is mounted described above will make sure that any attack that is mounted
must originate from compromised nodes within the LLN. must originate from compromised nodes within the LLN.
The use of BCP38 <xref target="BCP38"/> filtering at the RPL root on The use of network ingress filtering <xref target="BCP38" format="de
egress traffic will fault"/> on egress traffic at
both alert the operator to the existence of the attack, as well the RPL root will alert the operator to the existence of the attack
as drop the attack traffic. As the RPL network is typically as well as drop the attack traffic. As the RPL network is typically
numbered from a single prefix, which is itself assigned by RPL, numbered from a single prefix, which is itself assigned by RPL,
BCP38 filtering involves a single prefix comparison and should be network ingress filtering <xref target="BCP38" format="default"/> in volves a single prefix comparison and should be
trivial to automatically configure. trivial to automatically configure.
</t> </t>
<t> <t>
There are some scenarios where IPv6-in-IPv6 traffic should be allowe d to There are some scenarios where IPv6-in-IPv6 traffic should be allowe d to
pass through the RPL root, such as the IPv6-in-IPv6 mediated pass through the RPL root, such as the IPv6-in-IPv6 mediated
communications between a new Pledge and the Join communications between a new pledge and the Join
Registrar/Coordinator (JRC) when Registrar/Coordinator (JRC) when
using <xref target="I-D.ietf-anima-bootstrapping-keyinfra" /> and using <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="d
<xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" />. This is efault"/> and
<xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" format="def
ault"/>. This is
the case for the RPL root to do careful filtering: it occurs only the case for the RPL root to do careful filtering: it occurs only
when the Join Coordinator is not co-located inside the RPL root. when the Join Coordinator is not co-located inside the RPL root.
</t> </t>
<t>
<t>
With the above precautions, an attack using IPv6-in-IPv6 tunnels can only be With the above precautions, an attack using IPv6-in-IPv6 tunnels can only be
by a node within the LLN on another node within the LLN. Such an by a node within the LLN on another node within the LLN. Such an
attack could, of course, be done directly. An attack of this attack could, of course, be done directly. An attack of this
kind is meaningful only if the source addresses are either fake kind is meaningful only if the source addresses are either fake
or if the point is to amplify return traffic. or if the point is to amplify return traffic.
Such an attack, could also be done without the use of IPv6-in-IPv6 Such an attack could also be done without the use of IPv6-in-IPv6
headers using forged source addresses. headers, by using forged source addresses instead.
If the attack requires bi-directional communication, then IPv6-in-IP If the attack requires bidirectional communication, then IPv6-in-IPv
v6 6
provides no advantages. provides no advantages.
</t> </t>
<t> <t>
Whenever IPv6-in-IPv6 headers are being proposed, there is a concern Whenever IPv6-in-IPv6 headers are being proposed, there is a concern
about creating security issues. In the Security Considerations about creating security issues. In the Security Considerations
section of <xref target="RFC2473"/>, it was suggested that tunnel en try and exit section of <xref target="RFC2473" format="default"/> (Section <xref target="RFC2473" section="9" sectionFormat="bare" format="default"/>), it was su ggested that tunnel entry and exit
points can be secured by securing the IPv6 path between them. This points can be secured by securing the IPv6 path between them. This
recommendation is not practical for RPL networks. <xref target="RFC recommendation is not practical for RPL networks.
5406" /> goes <xref target="RFC5406" format="default"/> provides guidance on what
into some detail on what additional details would be needed in order on what additional details are needed in order to "Use IPsec".
to "Use IPsec". Use of ESP would While the use of Encapsulating Security Payload (ESP) would prevent
prevent <xref target="RFC8138"/> compression (compression must occur source address
before forgeries, in order to use it with <xref target="RFC8138" format="de
encryption), and <xref target="RFC8138"/> compression is lossy in a fault"/>, compression would have to occur
way that prevents before encryption, as the <xref target="RFC8138" format="default"/>
use of AH. These are minor issues. The major issue is how to compression is lossy. Once encrypted,
establish trust enough such that IKEv2 could be used. This would there would be no further redundancy to compress. These are minor i
ssues. The major issue is how to
establish trust enough such that Internet Key Exchange Protocol Vers
ion 2 (IKEv2) could be used. This would
require a system of certificates to be present in every single node, require a system of certificates to be present in every single node,
including any Internet nodes that might need to communicate with the including any Internet nodes that might need to communicate with the
LLN. Thus, using IPsec requires a global PKI in the general case. LLN. Thus, using IPsec requires a global PKI in the general case.
</t> </t>
<t> <t>
More significantly, the use of IPsec tunnels to protect the IPv6-in- IPv6 More significantly, the use of IPsec tunnels to protect the IPv6-in- IPv6
headers would in the general case scale with the square of the headers would, in the general case, scale with the square of the
number of nodes. This is a lot of resource for a constrained number of nodes. This is a lot of resources for a constrained
nodes on a constrained network. In the end, the IPsec tunnels nodes on a constrained network. In the end, the IPsec tunnels
would be providing only BCP38-like origin authentication! would be providing only BCP38-like origin authentication!
That is, IPsec provides a transitive guarantee to the tunnel exit po int That is, IPsec provides a transitive guarantee to the tunnel exit po int
that the tunnel entry point did BCP38 on traffic going in. that the tunnel entry point did network ingress filtering <xref targ et="BCP38" format="default"/> on traffic going in.
Just doing origin filtering per BCP 38 at the entry and Just doing origin filtering per BCP 38 at the entry and
exit of the LLN provides a similar level of security without all the exit of the LLN provides a similar level of security without all the
scaling and trust problems related to IPv6 tunnels as discussed in scaling and trust problems related to IPv6 tunnels as discussed in
RFC 2473. IPsec is not recommended. <xref target="RFC2473" format="default"/>. IPsec is not recommended.
</t> </t>
<t> <t>
An LLN with hostile nodes within it would not be protected against An LLN with hostile nodes within it would not be protected against
impersonation with the LLN by entry/exit filtering. impersonation within the LLN by entry/exit filtering.
</t> </t>
<t>
<t>
The RH3 header usage described here can be abused in equivalent The RH3 header usage described here can be abused in equivalent
ways. An external attacker may form a packet with an RH3 that is ways. An external attacker may form a packet with an RH3 that is
not fully consumed and encapsulate it to hide the RH3 from not fully consumed and encapsulate it to hide the RH3 from
intermediate nodes and disguise the origin of intermediate nodes and disguise the origin of
traffic. As such, the attacker's RH3 header will not be seen by traffic. As such, the attacker's RH3 header will not be seen by
the network until it reaches the destination, which will decapsulate the network until it reaches the destination, which will decapsulate
it. As indicated in section 4.2 of <xref target="RFC6554"/>, RPL it. As indicated in <xref target="RFC6554" section="4.2" sectionForm at="of" format="default"/>, RPL
routers are responsible for ensuring that an SRH is only used routers are responsible for ensuring that an SRH is only used
between RPL routers. As such, if there is an RH3 that is not fully between RPL routers. As such, if there is an RH3 that is not fully
consumed in the encapsulated packet, the node that decapsulates it consumed in the encapsulated packet, the node that decapsulates it
MUST ensure that the outer packet was originated in the RPL domain <bcp14>MUST</bcp14> ensure that the outer packet was originated in t he RPL domain
and drop the packet otherwise. and drop the packet otherwise.
</t> </t>
<t> <t>
Also, as indicated by section 2 of Also, as indicated by
<xref target="RFC6554"/>, RPL Border Routers "do not allow datagrams <xref target="RFC6554" section="2" sectionFormat="of" format="defaul
carrying an SRH header to enter or exit a RPL routing domain". This t"/>, RPL Border Routers
"do not allow datagrams
carrying an SRH header to enter or exit a RPL routing domain."
This
sentence must be understood as concerning non-fully-consumed packets . sentence must be understood as concerning non-fully-consumed packets .
A consumed (inert) A consumed (inert)
RH3 header could be present in a packet that flows from one LLN, RH3 header could be present in a packet that flows from one LLN,
crosses the Internet, and enters another LLN. As per the crosses the Internet, and enters another LLN. Per the
discussion in this document, such headers do not need to be discussion in this document, such headers do not need to be
removed. However, there is no case described in this document removed. However, there is no case described in this document
where an RH3 is inserted in a non-storing network on traffic that where an RH3 is inserted in a Non-Storing network on traffic that
is leaving the LLN, but this document should not preclude such a is leaving the LLN, but this document should not preclude such a
future innovation. future innovation.
</t> </t>
<t> <t>
In short, a packet that crosses the border of the RPL domain MAY In short, a packet that crosses the border of the RPL domain <bcp14>
carry and RH3, and if so, that RH3 MUST be fully consumed. MAY</bcp14>
</t> carry an RH3, and if so, that RH3 <bcp14>MUST</bcp14> be fully consu
<t> med.
</t>
<t>
The RPI, if permitted to enter the LLN, could be used by The RPI, if permitted to enter the LLN, could be used by
an attacker to change the priority of a packet by selecting a an attacker to change the priority of a packet by selecting a
different RPLInstanceID, perhaps one with a higher energy cost, different RPLInstanceID, perhaps one with a higher energy cost,
for instance. It could also be that not all nodes are reachable for instance. It could also be that not all nodes are reachable
in an LLN using the default RPLInstanceID, but a change of in an LLN using the default RPLInstanceID, but a change of
RPLInstanceID would permit an attacker to bypass such filtering. RPLInstanceID would permit an attacker to bypass such filtering.
Like the RH3, an RPI is to be inserted by the RPL root on Like the RH3, an RPI is to be inserted by the RPL root on
traffic entering the LLN by first inserting an IPv6-in-IPv6 header. The traffic entering the LLN by first inserting an IPv6-in-IPv6 header. The
attacker's RPI therefore will not be seen by the network. attacker's RPI therefore will not be seen by the network.
Upon reaching the destination node the RPI has no further Upon reaching the destination node, the RPI has no further
meaning and is just skipped; the presence of a second RPI meaning and is just skipped; the presence of a second RPI
will have no meaning to the end node as the packet has already will have no meaning to the end node as the packet has already
been identified as being at it's final destination. been identified as being at its final destination.
</t> </t>
<t> <t>
For traffic leaving a RUL, if the RUL adds an opaque RPI then the 6L For traffic leaving a RUL, if the RUL adds an uninitialized RPI (e.g
R as a RPL border ., with a value of zero), then the 6LR as a RPL Border
router SHOULD rewrite the RPI to indicate the selected Instance and Router <bcp14>SHOULD</bcp14> rewrite the RPI to indicate the selecte
set the flags. d Instance and set the flags.
This is done in order to avoid: 1) The leaf is an external router th This is done in order to avoid the following scenarios: 1) The leaf
at is an external router that
passes a packet that it did not generate and that carries an unrelat passes a packet that it did not generate and that carries an unrelat
ed RPI ed RPI,
and 2) The leaf is an attacker or presents misconfiguration and and 2) The leaf is an attacker or presents misconfiguration and
tries to inject traffic in a protected instance. tries to inject traffic in a protected Instance.
Also, this applies in the case where the leaf is aware of the RPL in Also, this applies to the case where the leaf is aware of the RPL In
stance and passes a correct RPI; stance and passes a correct RPI;
the 6LR needs a configuration that allows that leaf to inject in tha t instance. the 6LR needs a configuration that allows that leaf to inject in tha t instance.
</t> </t>
<t> <t>
The RH3 and RPIs could be abused by an attacker inside of The RH3 and RPIs could be abused by an attacker inside of
the network to route packets on non-obvious ways, perhaps eluding the network to route packets in nonobvious ways, perhaps eluding
observation. This usage appears consistent with a normal operation of observation. This usage appears consistent with a normal operation of
<xref target="RFC6997" /> and can not be restricted at all. This <xref target="RFC6997" format="default"/> and cannot be restricted a t all. This
is a feature, not a bug. is a feature, not a bug.
</t> </t>
<t> <t>
<xref target="RFC7416"/> deals with many other threats to LLNs <xref target="RFC7416" format="default"/> deals with many other thre
ats to LLNs
not directly related to the use of IPv6-in-IPv6 headers, and this not directly related to the use of IPv6-in-IPv6 headers, and this
document does not change that analysis. document does not change that analysis.
</t> </t>
<t> <t>
Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an
attack on another part of the LLN, while disguising the origin of attack on another part of the LLN, while disguising the origin of
the attack. The mechanism can even be abused to make it appear the attack. The mechanism can even be abused to make it appear
that the attack is coming from outside the LLN, and unless that the attack is coming from outside the LLN, and unless
countered, this could be used to mount a Distributed Denial Of countered, this could be used to mount a DDOS
Service attack upon nodes elsewhere in the Internet. See <xref attack upon nodes elsewhere in the Internet. See <xref target="DDOS-
target="DDOS-KREBS" /> for an example of such attacks already KREBS" format="default"/> for an example of such attacks already
seen in the real world. seen in the real world.
</t> </t>
<t> <t>
If an attack comes from inside of LLN, it can be alleviated with SAV I If an attack comes from inside of LLN, it can be alleviated with SAV I
(Source Address Validation Improvement) using <xref target="RFC8505" (Source Address Validation Improvement) using <xref target="RFC8505"
/> with format="default"/> with
<xref target="I-D.ietf-6lo-ap-nd"/>. The attacker will not <xref target="RFC8928" format="default"/>. The attacker will not
be able to source traffic with an address that is not registered, an d the registration process be able to source traffic with an address that is not registered, an d the registration process
checks for topological correctness. Notice that there is an L2 authe checks for topological correctness. Notice that there is Layer 2 aut
ntication hentication
in most of the cases. If an attack comes from outside LLN IPv6-in- in most of the cases. If an attack comes from outside LLN, IPv6-in-
IPv6 can be used to hide inner routing headers, but by construction, IPv6
the RH3 can typically only address nodes within the can be used to hide inner routing headers, but by construction, the
LLN. That is, an RH3 with a CmprI less than 8 , should be considere RH3 can typically only address nodes within the
d an attack (see RFC6554, section 3). LLN. That is, an RH3 with a CmprI less than 8 should be considered
</t> an attack (see <xref target="RFC6554" section="3" sectionFormat="of" format="def
<t> ault"/>).
</t>
<t>
Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic
through the RPL root to perform this attack. To counter, the RPL through the RPL root to perform this attack. To counter, the RPL
root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the root <bcp14>SHOULD</bcp14> either restrict ingress of IPv6-in-IPv6 p
simpler solution), or it SHOULD walk the IP header extension chain u ackets (the
ntil it can inspect the simpler solution), or it <bcp14>SHOULD</bcp14> walk the IP header ex
upper-layer-payload as described in <xref target="RFC7045" />. tension chain until it can inspect the
In particular, the RPL root SHOULD do <xref upper-layer payload as described in <xref target="RFC7045" format="d
target="BCP38" /> processing on the source addresses of all IP efault"/>.
In particular, the RPL root <bcp14>SHOULD</bcp14> do network ingress
filtering <xref target="BCP38" format="default"/> on the source addresses of al
l IP
headers that it examines in both directions. headers that it examines in both directions.
</t> </t>
<t> <t>
Note: there are some situations where a prefix will spread Note: there are some situations where a prefix will spread
across multiple LLNs via mechanisms such as the one described in across multiple LLNs via mechanisms such as the one described in
<xref target="I-D.ietf-6lo-backbone-router" />. <xref target="RFC8929" format="default"/>.
In this case the BCP38 filtering needs to take this into account, In this case, the network ingress filtering <xref target="BCP38" for
either by exchanging detailed routing information on each LLN, mat="default"/> needs to take this into account,
or by moving the BCP38 filtering further towards the Internet, either by exchanging detailed routing information on each LLN
or by moving the network ingress filtering <xref target="BCP38" form
at="default"/> further towards the Internet,
so that the details of the multiple LLNs do not matter. so that the details of the multiple LLNs do not matter.
</t> </t>
</section>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
This work is done thanks to the grant given by the StandICT.eu projec
t.
</t>
<t>
A special BIG thanks to C. M. Heard for the help with the <xref targ
et="updateRFCs_section" />.
Much of the redaction in that section is based on his comments.
</t>
<t>
Additionally, the authors would like to acknowledge the review, feedb
ack, and
comments of (alphabetical order): Dominique Barthel, Robert Cragie, S
imon Duquennoy, Ralph Droms,
Cenk Gündogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gusta
vo Mercado, Subramanian Moonesamy,
Marcela Orbiscay, Charlie Perkins, Cristian Perez, Alvaro Retana, Pet
er van der Stok,
Xavier Vilajosana, Éric Vyncke and Thomas Watteyne.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC6553; </middle>
&RFC6554; <back>
&RFC2119;
&RFC6040;
<?rfc include="reference.RFC.8174.xml" ?> <displayreference target="I-D.ietf-intarea-tunnels" to="TUNNELS"/>
<displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZEROTOU
CH-JOIN"/>
<displayreference target="I-D.ietf-anima-bootstrapping-keyinfra" to="BRSKI"/>
<displayreference target="I-D.ietf-anima-autonomic-control-plane" to="ACP"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6553.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6554.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8025.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8138.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6550.xml"/>
<?rfc include="reference.RFC.8200.xml" ?> <referencegroup anchor="BCP38" target="https://rfc-editor.org/info/bcp38">
<?rfc include="reference.RFC.8025.xml" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2827.xml"/>
</referencegroup>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7045.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0801.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8504.xml"/>
<?rfc include="reference.RFC.8138.xml" ?> <!-- [I-D.ietf-6lo-ap-nd] Published as RFC 8928 -->
<?rfc include="reference.RFC.6282.xml" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8928.xml"/>
&RFC6550; <!-- [I-D.ietf-intarea-tunnels] IESG state Expired -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-intarea-tunnels.xml"/>
<reference anchor='BCP38' target='https://www.rfc-editor.org/info/bcp38'> <!-- [I-D.ietf-roll-unaware-leaves] companion document RFC 9010 -->
<front> <reference anchor="RFC9010">
<title>Network Ingress Filtering: Defeating Denial of Service Attacks which <front>
employ IP Source Address Spoofing</title> <title>Routing for RPL (Routing Protocol for Low-Power and&nbsp;Lossy&nbsp;Netwo
<author initials='P.' surname='Ferguson' fullname='P. Ferguson'><organizati rks)&nbsp;Leaves</title>
on /></author>
<author initials='D.' surname='Senie' fullname='D. Senie'><organization /><
/author>
<date year='2000' month='May' />
<abstract><t>This paper discusses a simple, effective, and straightforward
method for using ingress traffic filtering to prohibit DoS (Denial of Service) a
ttacks which use forged IP addresses to be propagated from 'behind' an Internet
Service Provider's (ISP) aggregation point. This document specifies an Internet
Best Current Practices for the Internet Community, and requests discussion and
suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='38'/>
<seriesInfo name='RFC' value='2827'/>
<seriesInfo name='DOI' value='10.17487/RFC2827'/>
</reference>
<?rfc include="reference.RFC.7045.xml" ?> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization/>
</author>
</references> <author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<references title="Informative References"> <date month="March" year="2021"/>
<?rfc include="reference.RFC.0801.xml" ?> </front>
<?rfc include="reference.RFC.8504.xml" ?> <seriesInfo name="RFC" value="9010"/>
<seriesInfo name="DOI" value="10.17487/RFC9010"/>
</reference>
<?rfc include="reference.I-D.ietf-6lo-ap-nd.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6437.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7416.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7102.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8180.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2473.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8505.xml"/>
<!-- RFC2460 obsoleted by RFC8200, mentioned for historical background -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2460.xml"/>
<?rfc include="reference.I-D.ietf-intarea-tunnels.xml"?> <!-- [I-D.ietf-anima-autonomic-control-plane] in REF state as of 02 Feb 21 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-anima-autonomic-control-plane.xml"/>
<?rfc include="reference.I-D.ietf-roll-unaware-leaves.xml" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5406.xml"/>
&RFC6775; <!-- [I-D.ietf-anima-bootstrapping-keyinfra] in EDIT state as of 02 Feb 21 -->
&RFC6437; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
&RFC7416; .ietf-anima-bootstrapping-keyinfra.xml"/>
&RFC4443;
&RFC7102;
&RFC8180;
&RFC2473;
&RFC8505;
&RFC2460;
<?rfc include="reference.I-D.ietf-anima-autonomic-control-plane.xml" ?> <!-- [I-D.ietf-6tisch-dtsecurity-zerotouch-join] IESG state Expired -->
<?rfc include="reference.RFC.5406.xml" ?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-6tisch-dtsecurity-zerotouch-join.xml"/>
<?rfc include="reference.I-D.ietf-anima-bootstrapping-keyinfra.xml" ?> <!-- [I-D.ietf-6lo-backbone-router] Published as RFC 8929 -->
<?rfc include="reference.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.I-D.ietf-6lo-backbone-router.xml" ?> FC.8929.xml"/>
<?rfc include="reference.RFC.6997.xml" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.6997.xml"/>
<reference anchor="DDOS-KREBS" target="http://arstechnica.com/security/2016 <!-- [DDOS-KREBS] http://arstechnica.com/security/2016/09/botnet-of-145k- camera
/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/"> s-reportedly-deliver-internets-biggest-ddos-ever/
<front> redirects to https://arstechnica.com/information-technology/2016/09/botnet-
<title>Record-breaking DDoS reportedly delivered by >145k hacked cameras of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/-->
</title> <reference anchor="DDOS-KREBS" target="https://arstechnica.com/informati
<author initials="D." surname="Goodin"> <organization></organization> < on-technology/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-bigges
/author> t-ddos-ever/">
<date year="2016" month="September"/> <front>
</front> <title>Record-breaking DDoS reportedly delivered by &gt;145k hacked
</reference> cameras</title>
<author initials="D." surname="Goodin">
<organization/>
</author>
<date year="2016" month="September"/>
</front>
</reference>
</references>
</references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
This work is done thanks to the grant given by the StandICT.eu projec
t.
</t>
<t>
A special BIG thanks to <contact fullname="C. M. Heard"/> for the he
lp with <xref target="updateRFCs_section" format="default"/>.
Much of the editing in that section is based on his comments.
</t>
<t>
Additionally, the authors would like to acknowledge the review, feedb
ack, and
comments of the following (in alphabetical order): <contact fullname=
"Dominique Barthel"/>, <contact fullname="Robert Cragie"/>, <contact fullname="R
alph Droms"/>, <contact fullname="Simon Duquennoy"/>,
<contact fullname="Cenk Guendogan"/>, <contact fullname="Rahul Jadhav
"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Matthias Kovatsch"
/>, <contact fullname="Gustavo Mercado"/>, <contact fullname="Subramanian Moones
amy"/>,
<contact fullname="Marcela Orbiscay"/>, <contact fullname="Cristian P
erez"/>, <contact fullname="Charlie Perkins"/>, <contact fullname="Alvaro Retana
"/>, <contact fullname="Peter van der Stok"/>,
<contact fullname="Xavier Vilajosana"/>, <contact fullname="Éric Vync
ke"/>, and <contact fullname="Thomas Watteyne"/>.
</t>
</section>
</references> </back>
</back>
</rfc> </rfc>
 End of changes. 372 change blocks. 
2925 lines changed or deleted 3764 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/