rfc9035xml2.original.xml   rfc9035.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr='trust200902' tocInclude="t
<?rfc tocompact="yes"?> rue" sortRefs="true" symRefs="true" obsoletes="" updates="8138" submissionType=
<?rfc tocdepth="3"?> "IETF" category="std" consensus="true" xml:lang="en" docName="draft-ietf-roll-
<?rfc tocindent="yes"?> turnon-rfc8138-18" number="9035" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902
' tocInclude="true" obsoletes="" updates="8138" consensus="true" submissionType
="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-turnon-rfc8138-18">
<front>
<title abbrev='Turn On 6LoRH'>A RPL DODAG Configuration Option for the 6LoWPA <front>
N Routing Header</title> <title abbrev='Turn On 6LoRH Compression'>A Routing Protocol for Low-Power an
d Lossy Networks (RPL) Destination&nbhy;Oriented Directed Acyclic Graph (DODAG)
Configuration Option for the 6LoWPAN Routing Header</title>
<seriesInfo name="RFC" value="9035"/>
<author fullname='Pascal Thubert' initials='P.' role='editor' surname='Thuber t'> <author fullname='Pascal Thubert' initials='P.' role='editor' surname='Thuber t'>
<organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> <organization abbrev='Cisco Systems'>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>
<author initials='L' surname='Zhao' fullname='Li Zhao'> <author initials='L' surname='Zhao' fullname='Li Zhao'>
<organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> <organization abbrev='Cisco Systems'>Cisco Systems, Inc.</organization >
<address> <address>
<postal> <postal>
<street>Xinsi Building</street> <extaddr>Xinsi Building</extaddr>
<street>No. 926 Yi Shan Rd </street> <street>No. 926 Yi Shan Rd</street>
<city>SHANGHAI </city> <city>Shanghai</city>
<code>200233</code> <code>200233</code>
<country>CHINA</country> <country>China</country>
</postal> </postal>
<email>liz3@cisco.com</email> <email>liz3@cisco.com</email>
</address> </address>
</author> </author>
<date/> <date year="2021" month="April"/>
<area>Routing Area</area>
<workgroup>ROLL</workgroup> <keyword>IoT</keyword>
<keyword>Draft</keyword> <keyword>Header Compression</keyword>
<keyword>Source Routing Header</keyword>
<keyword>Hop-by-Hop Header</keyword>
<keyword>RPL artifacts</keyword>
<abstract> <abstract>
<t> <t>
This document updates RFC 8138 by defining a bit in the RPL DODAG This document updates RFC 8138 by defining a bit in the Routing Protocol fo
Configuration Option to indicate whether compression is used within the r Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph
RPL Instance, and specify the behavior of RFC 8138-capable nodes (DODAG)
Configuration option to indicate whether compression is used within the
RPL Instance and to specify the behavior of nodes compliant with RFC 8138
when the bit is set and unset. when the bit is set and unset.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section><name>Introduction</name> <section><name>Introduction</name>
<t> <t>
The design of Low Power and Lossy Networks (LLNs) is generally focused on The design of Low-Power and Lossy Networks (LLNs) is generally focused on
saving energy, which is the most constrained resource of all. The routing saving energy, which is the most constrained resource of all. The routing
optimizations in the <xref target='RFC6550'>"Routing Protocol for Low Power optimizations in "<xref target="RFC6550" format="title"/>" <xref target="RFC
and Lossy Networks"</xref> (RPL) such as routing along a 6550" format="default"/>, such as routing along a
Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node and the Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node and the
associated routing header compression and forwarding technique specified in associated routing header compression and forwarding technique specified in
<xref target='RFC8138'/> derive from that primary concern. <xref target='RFC8138'/>, derive from that primary concern.
</t> </t>
<t> <t>
Enabling <xref target='RFC8138'/> on a running network requires a Flag Day Enabling <xref target='RFC8138'/> on a running network requires a "flag day"
where the network is upgraded and rebooted. ,
Otherwise, if acting as a Leaf, a node that does not where the network is upgraded and rebooted.
support the compression would fail to communicate; if acting as a router it Otherwise, if acting as a leaf, a node that does not
support compression per <xref target='RFC8138'/> would fail to communicate;
if acting as a router, it
would drop the compressed packets and black-hole a portion of the network. would drop the compressed packets and black-hole a portion of the network.
This specification enables a hot upgrade where a live network is migrated. During the migration, the compression remains inactive, until all nodes are upgr aded. This specification enables a hot upgrade where a live network is migrated. D uring the migration, compression remains inactive until all nodes are upgraded.
</t> </t>
<t> <t>
This document complements <xref target='RFC8138'/> and signals whether it This document complements <xref target='RFC8138'/> and signals whether it
should be used within a RPL DODAG with a new flag in the RPL DODAG should be used within a RPL DODAG with a new flag in the RPL DODAG
Configuration Option. Configuration option.
The setting of this new flag is controlled by the Root and propagates as The setting of this new flag is controlled by the Root and propagates as
is in the whole network as part of the normal RPL signaling. is in the whole network as part of the normal RPL signaling.
</t> </t>
<t> <t>
The flag is cleared to maintain the compression inactive during The flag is cleared to ensure that compression remains inactive during
the migration phase. When the migration is complete (e.g., as known by the migration phase. When the migration is complete (e.g., as known by
network management and/or inventory), the flag is set and the compression network management and/or inventory), the flag is set and compression
is globally activated in the whole DODAG. is globally activated in the whole DODAG.
</t> </t>
<!-- </section>
The appendix proposes a method to isolate the legacy nodes that cannot be
upgraded in a separate instance where the compression remains off.
Upgraded nodes can participate to that instance as routers but will prefer
an upgraded instance for their own traffic, so they can use the compressio
n.
-->
</section><!-- title="Introduction"-->
<section><name>Terminology</name> <section><name>Terminology</name>
<section anchor='lo'><name>References</name> <section anchor='lo'><name>Related Documents</name>
<t> <t>
The terminology used in this document is consistent with and incorporates The terminology used in this document is consistent with, and incorporates
that described in <xref target='RFC7102'>"Terms Used in Routing for Low-Power the terms provided in, "<xref target="RFC7102" format="title"/>" <xref target
and Lossy Networks (LLNs)"</xref>. ="RFC7102" format="default"/>.
Other terms in use in LLNs are found in <xref target='RFC7228'> Other terms in use as related to LLNs are found in "<xref target="RFC7228" fo
"Terminology for Constrained-Node Networks"</xref>. rmat="title"/>" <xref target="RFC7228" format="default"/>.
</t> </t>
<t>"RPL", the "RPL Packet Information" (RPI), and "RPL Instance" (indexed by a <t>"RPL", "RPL Packet Information" (RPI), and "RPL Instance" (indexed by a
RPLInstanceID) are defined in <xref target='RFC6550'>"RPL: IPv6 Routing RPLInstanceID) are defined in "<xref target="RFC6550" format="title"/>" <xref
Protocol for Low-Power and Lossy Networks"</xref>. The RPI is the abstract target="RFC6550" format="default"/>.
The RPI is the abstract
information that RPL defines to be placed in data packets, e.g., as the RPL information that RPL defines to be placed in data packets, e.g., as the RPL
Option <xref target='RFC6553'/> within the IPv6 Hop-By-Hop Header. Option <xref target='RFC6553'/> within the IPv6 Hop-By-Hop Header.
By extension the term "RPI" is often used to refer to the RPL Option itself. By extension, the term "RPI" is often used to refer to the RPL Option itself.
The DODAG Information Solicitation (DIS), Destination Advertisement Object The DODAG Information Solicitation (DIS), Destination Advertisement Object
(DAO) and DODAG Information Object (DIO) messages are also specified in (DAO), and DODAG Information Object (DIO) messages are also specified in
<xref target='RFC6550'/>. <xref target='RFC6550'/>.
</t><t> </t><t>
This document uses the terms RPL-Unaware Leaf (RUL) and RPL-Aware Leaf This document uses the terms "RPL-Unaware Leaf" (RUL) and "RPL-Aware Leaf"
(RAL) consistently with <xref target='I-D.ietf-roll-useofrplinfo'> (RAL) consistently with <xref target='RFC9008'> "Using RPI Option Type, Routi
"Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 enc ng Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plan
apsulation in the RPL Data Plane"</xref>. e"</xref>.
The term RPL-Aware Node (RAN) refers to a node that is either The term "RPL-Aware Node" (RAN) refers to a node that is either
a RAL or a RPL Router. A RAN manages the reachability of its addresses and a RAL or a RPL router. A RAN manages the reachability of its addresses and
prefixes by injecting them in RPL by itself. In contrast, a RUL leverages prefixes by injecting them in RPL by itself. In contrast, a RUL leverages
<xref target='RFC8505'>"Registration Extensions for IPv6 over "<xref target="RFC8505" format="title"/>" <xref target="RFC8505" format="defa
Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" ult"/>
</xref> to obtain reachability services from its parent router(s) to obtain reachability services from its parent router(s)
as specified in <xref target='I-D.ietf-roll-unaware-leaves'> as specified in <xref target='RFC9010'> "Routing for RPL (Routing Protocol f
"Routing for RPL Leaves"</xref>. or Low-Power and Lossy Networks) Leaves"</xref>.
</t> </t>
</section> <!-- end section "References" --> </section>
<section anchor='gloss'><name>Glossary</name> <section anchor='gloss'><name>Glossary</name>
<t> This document often uses the following acronyms: <t> This document often uses the following abbreviations:
</t> </t>
<dl spacing='compact'> <dl spacing='compact'>
<dt>6LoWPAN:</dt><dd>IPv6 over Low-Power Wireless Personal Area Network</dd>
<dt>6LoRH:</dt><dd>6LoWPAN Routing Header</dd> <dt>6LoRH:</dt><dd>6LoWPAN Routing Header</dd>
<dt>6LoWPAN:</dt><dd>IPv6 over Low-Power Wireless Personal Area Network</dd>
<dt>DIO:</dt><dd> DODAG Information Object (a RPL message) </dd> <dt>DIO:</dt><dd> DODAG Information Object (a RPL message) </dd>
<dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph </dd> <dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph </dd>
<dt>LLN:</dt><dd> Low-Power and Lossy Network </dd> <dt>LLN:</dt><dd> Low-Power and Lossy Network </dd>
<dt>RPL:</dt><dd> IPv6 Routing Protocol for Low-Power and Lossy Networks </d
d>
<dt>SubDAG:</dt><dd> A DODAG rooted at a node which is a child of that node
and a subset of a larger DAG </dd>
<dt>MOP:</dt><dd> RPL Mode of Operation </dd> <dt>MOP:</dt><dd> RPL Mode of Operation </dd>
<dt>RPI:</dt><dd> RPL Packet Information </dd>
<dt>RAL:</dt><dd> RPL-Aware Leaf </dd> <dt>RAL:</dt><dd> RPL-Aware Leaf </dd>
<dt>RAN:</dt><dd> RPL-Aware Node </dd> <dt>RAN:</dt><dd> RPL-Aware Node </dd>
<dt>RPI:</dt><dd> RPL Packet Information </dd>
<dt>RPL:</dt><dd> IPv6 Routing Protocol for Low-Power and Lossy Networks </d
d>
<dt>RUL:</dt><dd> RPL-Unaware Leaf</dd> <dt>RUL:</dt><dd> RPL-Unaware Leaf</dd>
<dt>SRH:</dt><dd>Source Routing Header</dd> <dt>SRH:</dt><dd>Source Routing Header</dd>
<dt>Sub-DODAG:</dt><dd>The sub-DODAG of a node is a DODAG rooted at that nod
e that is a subset of a main DODAG the node belongs to. It is formed by the othe
r nodes in the
main DODAG whose paths to the main DODAG root pass through that node.</dd>
</dl> </dl>
</section> <!-- end section "Glossary" --> </section>
<section anchor='bcp'><name>Requirements Language</name> <section anchor='bcp'><name>Requirements Language</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target='RFC2119'/><xref target='RFC8174'/> when, and only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
appear in all capitals, as shown here. are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
</t> when, they appear in all capitals, as shown here.</t>
</section> <!-- end section "Requirements Language" --> </section>
</section> <!-- end section "Terminology" --> </section>
<section><name>Extending RFC 6550</name> <section><name>Extending RFC 6550</name>
<t> <t>
The DODAG Configuration Option is defined in Section 6.7.6 of <xref target= The DODAG Configuration option is defined in <xref target="RFC6550" sectionFo
'RFC6550'/>. Its purpose is extended to distribute configuration rmat="of" section="6.7.6"/>. Its purpose is extended to distribute configuration
information affecting the construction and maintenance of the DODAG, as information affecting the construction and maintenance of the DODAG, as
well as operational parameters for RPL on the DODAG, through the DODAG. well as operational parameters for RPL on the DODAG, through the DODAG.
As shown in <xref target="RPLDCO"/>, the Option was originally The DODAG Configuration option was originally
designed with 4 bit positions reserved for future use as Flags. designed with four bit positions reserved for future use as flags.
</t> </t>
<figure anchor="RPLDCO"> <figure anchor="RPLDCO">
<name>DODAG Configuration Option (Partial View) </name> <name>DODAG Configuration Option (Partial View) </name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| | |T| |A| ... | | Type = 0x04 |Opt Length = 14| | |T| |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
<- Flags -> <- flags ->]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
This specification defines a new flag "Enable RFC8138 Compression" (T). This specification defines a new flag, "Enable Compression per RFC 8138 (T)".
The "T" flag is set to turn-on the use of The 'T' flag is set to turn on the use of
<xref target='RFC8138'/> within the DODAG. The "T" flag is encoded <xref target='RFC8138'/> within the DODAG. The 'T' flag is encoded
in position 2 of the reserved Flags in the DODAG Configuration Option (counti in position 2 of the reserved flags in the DODAG Configuration option (counti
ng from bit 0 as the most significant bit) and set to 0 in ng from bit 0 as the most significant bit) and set to 0 in
legacy implementations as specified respectively in Sections 20.14 and 6.7.6 legacy implementations as specified in
of <xref target='RFC6550'/>. Sections&nbsp;<xref target="RFC6550" section="20.14"
sectionFormat="bare"/> and <xref target="RFC6550" section="6.7.6"
sectionFormat="bare"/> of <xref target="RFC6550"/>, respectively.
</t> </t>
<t> <t>
Section 4.3 of <xref target='I-D.ietf-roll-useofrplinfo'/> updates <xref target="RFC9008" sectionFormat="of" section="4.1.2"/>
<xref target='RFC6550'/> to indicate that the definition of the Flags applies updates
to Mode of Operation (MOP) values zero (0) to six (6) only. <xref target='RFC6550'/> to indicate that the definition of the flags applies
For a MOP value of 7, <xref target='RFC8138'/> MUST be used on Links where 6L to Mode of Operation (MOP) values zero (0) to six (6) only.
oWPAN Header For a MOP value of 7, <xref target='RFC8138'/> <bcp14>MUST</bcp14> be used on
Compression <xref target='RFC6282'/> applies and MUST NOT be used otherwise. links where 6LoWPAN Header
Compression <xref target='RFC6282'/> applies and <bcp14>MUST NOT</bcp14> be u
sed otherwise.
</t> </t>
<t> <t>
The RPL DODAG Configuration Option is typically placed in The RPL DODAG Configuration option is typically placed in
a DODAG Information Object (DIO) message. The DIO message propagates down the a DIO message. The DIO message propagates down the
DODAG to form and then maintain its structure. The DODAG Configuration Option DODAG to form and then maintain its structure. The DODAG Configuration option
is copied unmodified from parents to children. is copied unmodified from parents to children.
<xref target='RFC6550'/> states that "Nodes other than the DODAG Root MUST
NOT modify this information when propagating the DODAG Configuration option". <!-- Quoted text is DNE. Verified. Fixed per RFC 6550. -->
Therefore, a legacy parent propagates the "T" flag as set by the Root, and <xref target='RFC6550'/> states that "Nodes other than the DODAG root
when the "T" flag is set, it is transparently flooded to all the nodes in the <bcp14>MUST NOT</bcp14> modify this information when propagating the DODAG Co
DODAG. nfiguration option."
Therefore, a legacy parent propagates the 'T' flag as set by the Root, and
when the 'T' flag is set, it is transparently flooded to all the nodes in the
DODAG.
</t> </t>
</section><!-- Updating RFC 6550 was: The RPL DODAG Configuration Option --> </section>
<section><name>Updating RFC 8138</name> <section><name>Updating RFC 8138</name>
<t> <t>
A node SHOULD generate packets in the compressed form using A node <bcp14>SHOULD</bcp14> generate packets in compressed form using
<xref target='RFC8138'/> if and only if the "T" flag <xref target='RFC8138'/> if and only if the 'T' flag
is set. This behavior can be overridden by configuration or network is set. This behavior can be overridden by configuration or network
management. Overriding may be needed e.g., to turn on the compression in a management. Overriding may be needed, e.g., to turn on compression in a
network where all nodes support <xref target='RFC8138'/> but the Root does network where all nodes support <xref target='RFC8138'/> but the Root does
not support this specification and cannot set the "T" flag, or to disable it not support this specification and cannot set the 'T' flag, or to disable it
locally in case of a problem. locally in case of a problem.
</t> </t>
<t> <t>
The decision to use <xref target='RFC8138'/> is made by the originator of The decision to use <xref target='RFC8138'/> is made by the originator of
the packet depending on its capabilities and its knowledge of the state of the packet, depending on its capabilities and its knowledge of the state of
the "T" flag. the 'T' flag.
A router encapsulating a packet is the originator of the resulting A router encapsulating a packet is the originator of the resulting
packet and is responsible for compressing the outer headers with packet and is responsible for compressing the outer headers per
<xref target= 'RFC8138'/>, but it MUST leave the encapsulated packet as is. <xref target= 'RFC8138'/>, but it <bcp14>MUST NOT</bcp14> perform compression
on the encapsulated packet.
</t> </t>
<t> <t>
An external target <xref target='I-D.ietf-roll-useofrplinfo'/> is not An external target <xref target='RFC9008'/> is not
expected to support <xref target='RFC8138'/>. In most cases, packets to and expected to support <xref target='RFC8138'/>. In most cases, packets to and
from an external target are tunneled back and forth between the border router from an external target are tunneled back and forth between the border router
(referred to as 6LR) that serves the external target and the Root, regardless (referred to as a 6LoWPAN Router (6LR)) that serves the external target and t he Root, regardless
of the MOP used in the RPL DODAG. of the MOP used in the RPL DODAG.
The inner packet is typically not compressed with <xref target='RFC8138'/>, The inner packet is typically not compressed per <xref target='RFC8138'/>,
so for outgoing packets, the border router just needs to decapsulate the so for outgoing packets, the border router just needs to decapsulate the
(compressed) outer header and forward the (uncompressed) inner packet towards (compressed) outer header and forward the (uncompressed) inner packet towards
the external target. the external target.
</t> </t>
<t> <t>
A router MUST uncompress a packet that is to be forwarded to an external A border router that forwards a packet to an external target <bcp14>MUST</bcp
target. Otherwise, the router MUST forward the packet in the form that the 14>
source used, either compressed or uncompressed. uncompress the packet first. In all other cases, a router <bcp14>MUST</bcp14>
forward a packet in the form that the source used, either compressed or
uncompressed.
</t> </t>
<t> <t>
A RUL <xref target='I-D.ietf-roll-unaware-leaves'/> is both a leaf and an A RUL <xref target='RFC9010'/> is both a leaf and an
external target. A RUL does not participate in RPL and external target. A RUL does not participate in RPL and
depends on the parent router to obtain connectivity. In the case of a RUL, depends on the parent router to obtain connectivity. In the case of a RUL,
forwarding towards an external target actually means delivering the packet. forwarding towards an external target actually means delivering the packet.
</t> </t>
</section><!-- Updating RFC 8138 --> </section>
<section><name>Transition Scenarios</name> <section><name>Transition Scenarios</name>
<t> <t>
A node that supports <xref target='RFC8138'/> but not this specification A node that supports <xref target='RFC8138'/> but not this specification
can only be used in a homogeneous network. can only be used in a homogeneous network.
Enabling the <xref target='RFC8138'/> compression without a turn-on signaling Enabling compression per <xref target='RFC8138'/> without a turn-on signaling
method requires a "flag day"; by which time all nodes must be upgraded, and method requires a flag day, by which time all nodes must be upgraded and
at which point the network can be rebooted with the <xref target='RFC8138'/> at which point the network can be rebooted with 6LoRH compression <xref targe
compression turned on. t='RFC8138'/> turned on.
</t> </t>
<t> <t>
The intent for this specification is to perform a migration once and for all The intent of this specification is to perform a migration once and for all,
without the need for a flag day. In particular it is not the intention to without the need for a flag day. In particular, the intent is not to
undo the setting of the "T" flag. undo the setting of the 'T' flag.
Though it is possible to roll back (see <xref target='rb'/>), the roll back Though it is possible to roll back (see <xref target='rb'/>), the rollback
operation SHOULD be complete before the network operator adds nodes operation <bcp14>SHOULD</bcp14> be complete before the network operator adds
nodes
that do not support <xref target='RFC8138'/>. that do not support <xref target='RFC8138'/>.
</t> </t>
<section anchor='coex'><name>Coexistence</name> <section anchor='coex'><name>Coexistence</name>
<t> <t>
A node that supports this specification can operate in a network with the A node that supports this specification can operate in a network with 6LoRH
<xref target='RFC8138'/> compression turned on or off with the "T" flag set compression <xref target='RFC8138'/> turned on or off with the 'T' flag set
accordingly and in a network in transition from off to on or on to off accordingly and in a network in transition from off to on or on to off
(see <xref target='mig'/>). (see <xref target='mig'/>).
</t> </t>
<t> <t>
A node that does not support <xref target='RFC8138'/> can interoperate with A node that does not support <xref target='RFC8138'/> can interoperate with
nodes that do in a network with <xref target='RFC8138'/> compression turned nodes that do in a network with 6LoRH compression <xref target='RFC8138'/> t
off. If the compression is turned on, all the RPL-Aware Nodes are expected urned
to be able to handle compressed packets in the compressed form. A node that off. If compression is turned on, all the RANs are expected
to be able to handle packets in compressed form. A node that
cannot do so may remain connected to the network as a RUL as described in cannot do so may remain connected to the network as a RUL as described in
<xref target='I-D.ietf-roll-unaware-leaves'/>. <xref target='RFC9010'/>.
</t> </t>
</section><!--Coexistence--> </section>
<section anchor='mig'><name>Inconsistent State While Migrating</name> <section anchor='mig'><name>Inconsistent State While Migrating</name>
<t> <t>
When the "T" flag is turned on by the Root, the When the 'T' flag is turned on by the Root, the
information slowly percolates through the DODAG as the DIO gets propagated. information slowly percolates through the DODAG as the DIO gets propagated.
Some nodes will see the flag and start sourcing packets in the compressed Some nodes will see the flag and start sourcing packets in compressed
form while other nodes in the same RPL DODAG are still not aware of it. form, while other nodes in the same RPL DODAG will still not be aware of it.
In non-storing mode, the Root will start using In Non-Storing mode, the Root will start using
<xref target='RFC8138'/> with a Source Routing Header 6LoRH (SRH-6LoRH) <xref target='RFC8138'/> with a Source Routing Header 6LoRH (SRH-6LoRH)
that routes all the way to the parent router or to the leaf. that routes all the way to the parent router or to the leaf.
</t> </t>
<t> <t>
To ensure that a packet is forwarded across the RPL DODAG in the form in To ensure that a packet is forwarded across the RPL DODAG in the form in
which it was generated, it is required that all the RPL nodes support which it was generated, it is required that all the RPL nodes support
<xref target='RFC8138'/> at the time of the switch. <xref target='RFC8138'/> at the time of the switch.
</t> </t>
<t> <t>
Setting the "T" flag is ultimately the responsibility of the Network Setting the 'T' flag is ultimately the responsibility of the network
Administrator. The expectation is that the network management or upgrading administrator. The expectation is that the network management or upgrading
tools in place enable the Network Administrator to know when all the nodes tools in place enable the network administrator to know when all the nodes
that may join a DODAG were migrated. In the case of a RPL instance with that may join a DODAG were migrated. In the case of a RPL Instance with
multiple Roots, all nodes that participate to the RPL Instance may multiple Roots, all nodes that participate in the RPL Instance may
potentially join any DODAG. potentially join any DODAG.
The network MUST be operated with the "T" flag unset until all nodes in the The network <bcp14>MUST</bcp14> be operated with the 'T' flag unset until all nodes in the
RPL Instance are upgraded to support this specification. RPL Instance are upgraded to support this specification.
</t> </t>
</section> <!--"Transient State while migrating"--> </section>
<section anchor='rb'><name>Rolling Back</name> <section anchor='rb'><name>Rolling Back</name>
<t> <t>
When turning <xref target='RFC8138'/> compression off in the network, the When turning 6LoRH compression <xref target='RFC8138'/> off in the network, t
Network Administrator MUST wait until all nodes have converged to the he
"T" flag unset before allowing nodes that do not support the compression in network administrator <bcp14>MUST</bcp14> wait until each node has its 'T' fl
the network. To that effect, whether the compression is active in a node ag
SHOULD be exposed the node's management interface. unset before allowing nodes that do not support compression in
the network. Information regarding whether compression is active in a node
<bcp14>SHOULD</bcp14> be exposed in the node's management interface.
</t> </t>
<t> <t>
Nodes that do not support <xref target='RFC8138'/> SHOULD NOT be deployed Nodes that do not support <xref target='RFC8138'/> <bcp14>SHOULD NOT</bcp14>
in a network where the compression is turned on. If that is done, the node be deployed
in a network where compression is turned on. If that is done, the node
can only operate as a RUL. can only operate as a RUL.
</t> </t>
</section> <!-- Rolling Back --> </section>
</section> <!-- Transition Scenarios --> </section>
<section anchor="iana"><name>IANA Considerations</name> <section anchor="iana"><name>IANA Considerations</name>
<t> <t>
This specification updates the Registry that was created for <xref target='R This specification updates the "DODAG Configuration Option Flags for MOP
FC6550'/> as the registry for "DODAG Configuration Option Flags" and updated as 0..6" registry <xref target='RFC9008'/> (formerly the "DODAG Configuration Optio
the registry for "DODAG Configuration Option Flags for MOP 0..6" by <xref target n Flags" registry, which was created for <xref target='RFC6550'/>), by allocatin
='I-D.ietf-roll-useofrplinfo'/>, by allocating one g one
new Flag as follows: new flag as follows:
<!--
IANA is requested to assign a new option flag from the Registry for the
"DODAG Configuration Option Flags" that was created for
<xref target='RFC6550'/> and updated as the registry for "DODAG Configurati
on Option Flags for MOP 0..6" by <xref target='I-D.ietf-roll-useofrplinfo'/>as f
ollows:
-->
</t> </t>
<table anchor="nexndopt"><name>New DODAG Configuration Option Flag</name> <table anchor="nexndopt"><name>New DODAG Configuration Option Flag</name>
<thead> <thead>
<tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></ tr> <tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></ tr>
</thead><tbody> </thead><tbody>
<tr><td>2</td><td>Enable Compression per RFC 8138 (T)</td><td>RFC 9035</td
<!-- ></tr>
Note to IANA:
if the bit position is changed, then fig 1 and the text below are impacted
and should be modified accordingly
-->
<tr><td>2 (suggested)</td><td>Turn on RFC8138 Compression (T)</td><td>THIS
RFC</td></tr>
</tbody> </tbody>
</table> </table>
<t>IANA is requested to add [this document] as a reference for MOP 7 in the RPL Mode of Operation registry. <t>IANA has added this document as a reference for MOP 7 in the RPL "Mode of Ope ration" registry.
</t> </t>
<!--t>
The DODAG Configuration Option Flags defined so far will be obsolete for
RPL Mode of Operation (MOP) above and including 7.
</t>
<t>
IANA is requested to update the name of the Registry from "DODAG Configurati
on Option Flags" to "DODAG Configuration Option Flags for RPL MOP 0..6".
</t>
<t>
When MOP values of 7 and more are defined, a new registry will be needed.
</t-->
</section> </section>
<section anchor='sec'><name>Security Considerations</name> <section anchor='sec'><name>Security Considerations</name>
<t> <t>
It is worth noting that in RPL <xref target='RFC6550'/>, every node in the It is worth noting that in RPL <xref target='RFC6550'/>, every node in the
LLN that is RPL-aware and has access to the RPL domain can inject any RPL-bas LLN that is RPL aware and has access to the RPL domain can inject any RPL-bas
ed attack in the network, more in <xref target='RFC7416'/>. ed attack in the network; see <xref target='RFC7416'/> for details.
This document applies typically to an existing deployment and does not change This document typically applies to an existing deployment and does not change
its security requirements and operations. its security requirements and operations.
It is assumed that the security mechanisms as defined for RPL are followed. It is assumed that the security mechanisms as defined for RPL are followed.
<!--
First of all, it is worth noting that with <xref target='RFC6550'/>, every
node in the LLN that is RPL-aware can inject any RPL-based attack in the
network.
A trust model is REQUIRED in an effort to exclude rogue nodes from
participating to the RPL and the 6LoWPAN signaling, as well as from the data
packet exchange. This trust model could at a minimum be based on a Layer-2
Secure joining and the Link-Layer security. This is a generic RPL and 6LoWPAN
requirement, see Req5.1 in Appendix of <xref target='RFC8505'/>.
-->
</t> </t>
<t> <t>
Setting the "T" flag before all routers are upgraded may cause a loss Setting the 'T' flag before all routers are upgraded may cause a loss
of packets. The new bit is protected as the rest of the configuration so of packets. The new bit benefits from the same protection as the rest of the
this is just one of the many attacks that can happen if an attacker manages information in the DODAG Configuration option that transports it. Touching
to inject a corrupted configuration. the new bit is just one of the many attacks that can happen if an
attacker manages to inject a corrupted configuration option in the network.
</t><t> </t><t>
Setting and unsetting the "T" flag may create inconsistencies in the network Setting and unsetting the 'T' flag may create inconsistencies in the network
but as long as all nodes are upgraded to <xref target='RFC8138'/> support ,
but as long as all nodes are upgraded to provide support for <xref target='R
FC8138'/>,
they will be able to forward both forms. The source is responsible they will be able to forward both forms. The source is responsible
for selecting whether the packet is compressed or not, and all routers must for selecting whether the packet is compressed or not, and all routers must
use the format that the source selected. So the result of an inconsistency use the format that the source selected. So, the result of an inconsistency
is merely that both forms will be present in the network, at an additional is merely that both forms will be present in the network, at an additional
cost of bandwidth for packets in the uncompressed form. cost of bandwidth for packets in uncompressed form.
</t><t> </t><t>
An attacker may unset the "T" flag to force additional energy consumption of An attacker may unset the 'T' flag to force additional energy consumption of
child or descendant nodes in its subDAG. child or descendant nodes in its sub-DODAG.
Conversely it may set the "T" flag, so Conversely, it may set the 'T' flag so
that nodes located downstream would compress when that it is not desired, that nodes located downstream would compress packets even when compression i
potentially resulting in the loss of packets. In a tree structure, the s not desired, potentially causing packet loss. In a tree structure, the attack
attacker would be in position to drop the packets from and to the attacked er would be in a position to drop the packets from and to the attacked nodes. S
nodes. So the attacks above would be more complex and more visible than o, the attacks mentioned above would be more complex and more visible than simpl
simply dropping selected packets. The downstream node may have other y dropping selected packets. The downstream node may have other parents and see
parents and see both settings, which could raise attention. the bit with both
settings; such a situation may be detected, and an alert may be triggered.
</t> </t>
</section> </section>
<section><name>Acknowledgments</name>
<t>
The authors wish to thank
Murray Kucherawy, Meral Shirazipour, Barry Leiba, Tirumaleswar Reddy,
Nagendra Kumar Nainar, Stewart Bryant, Carles Gomez, Eric Vyncke,
Roman Danyliw,
and especially Benjamin Kaduk, Alvaro Retana, Dominique Barthel
and Rahul Jadhav for their in-depth reviews and constructive suggestions.
</t><t>
Also many thanks to Michael Richardson for being always helpful and responsiv
e
when need comes.
</t>
</section><!-- ack -->
</middle> </middle>
<back> <back>
<references><name>References</name>
<displayreference target="I-D.ietf-roll-useofrplinfo" to="USEofRPLinfo"
/>
<displayreference target="I-D.ietf-roll-unaware-leaves" to="UNAWARE-LEA
VES"/>
<references><name>Normative References</name> <references><name>Normative References</name>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
rence.RFC.2119.xml'/> <!-- BCP14 --> .RFC.2119.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
rence.RFC.8174.xml'/> <!-- BCP14 --> .RFC.8174.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
rence.RFC.6550.xml'/> <!-- RPL --> .RFC.6550.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.710
FC.7102.xml'/> <!-- RPI --> 2.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
rence.RFC.8138.xml'/> <!-- 6LoRH for RPL artifacts --> .RFC.8138.xml'/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.8505.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <!-- draft-ietf-roll-unaware-leaves (RFC 9010) -->
rence.RFC.8505.xml'/> <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
<!--6LoWPAN ND --> <xi:include href='https://xml2rfc.tools.ietf.org/pu .RFC.9010.xml'/>
blic/rfc/bibxml3/reference.I-D.ietf-roll-unaware-leaves.xml'/>
</references> </references>
<references><name>Informative References</name> <references><name>Informative References</name>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
rence.RFC.6282.xml'/> <!-- 6lowpan HC --> .RFC.6282.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
rence.RFC.6553.xml'/> <!-- RPI --> .RFC.6553.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.722
FC.7228.xml'/> <!-- termonology --> 8.xml'/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe .RFC.7416.xml'/>
rence.RFC.7416.xml'/> <!-- Security Threat Analysis for RPL -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-roll-useofrplinfo.xml'/>
<!-- draft-ietf-roll-useofrplinfo (RFC 9008) -->
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference
.RFC.9008.xml'/>
</references>
</references> </references>
<!-- section anchor='dic'><name>Double RPL Instances Scenario</name> <section numbered="false"><name>Acknowledgments</name>
<t>
Sections 8.5 and 9.2 of <xref target='RFC6550'/> suggests that a
RAN may only attach to a DODAG as a leaf when it does
not support the Mode of Operation of a RPL Instance, the Objective Function
(OF) as indicated by the Objective Code Point (OCP) or some other parameters
in the configuration option.
</t>
<t>
This specification reiterates that a RAN that is configured to operate in a
RPL Instance but does not support a value for a known parameter that is
mandatory for routing, such as the OCP, MUST NOT operate as a router but MAY
still join as a leaf. Note that a legacy RAN will not recognize when a
reserved field is used and will not turn to a leaf when the "T" flag is set.
</t>
<t>
The two RPL Instances operate independently as specified
in <xref target='RFC6550'/>. The preexisting RPL Instance does not use
<xref target='RFC8138'/>, whereas the new RPL Instance does. This is signaled
by the "T" flag which is only set in the configuration option in DIO messages
in the new RPL Instance.
</t>
<t>
Nodes that support <xref target='RFC8138'/> participate in both Instances but
favor the new RPL Instance for the traffic that they source.
By contrast, nodes that only support the uncompressed format would
either not be configured for the new RPL Instance, or would be configured to
join it as leaves only.
</t>
<t>
This method requires implementations to support at least two RPL
Instances and demands management capabilities to introduce new RPL Instances
and deprecate old ones.
</t>
<t> <t>
The 2 instances MUST be operated with the same security guarantees, e.g., The authors wish to thank
both "unsecured" with a lower layer security of a same strength, both <contact fullname="Murray Kucherawy"/>, <contact fullname="Meral Shirazipour"
"preinstalled" or both "authenticated" security mode (see section 3.2.3 of />, <contact fullname="Barry Leiba"/>, <contact fullname="Tirumaleswar Reddy"/>,
<xref target='RFC6550'/> for more details on those modes). The latter mode <contact fullname="Nagendra Kumar Nainar"/>, <contact fullname="Stewart Bryan
could be use to enforce the segregation of updated and non-updated nodes, by t"/>, <contact fullname="Carles Gomez"/>, <contact fullname="Éric Vyncke"/>,
providing the keys for joining as routers to the updated nodes only. <contact fullname="Roman Danyliw"/>,
and especially <contact fullname="Benjamin Kaduk"/>, <contact fullname="Alvar
o Retana"/>, <contact fullname="Dominique Barthel"/>,
and <contact fullname="Rahul Jadhav"/> for their in-depth reviews and constru
ctive suggestions.
</t><t>
Also, many thanks to <contact fullname="Michael Richardson"/> for always bein
g helpful and responsive when the need arises.
</t> </t>
</section> </section>
Double Instance Scenario -->
</back> </back>
</rfc> </rfc>
 End of changes. 96 change blocks. 
345 lines changed or deleted 262 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/