One document matched: draft-ietf-roll-rpl-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?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 category="std" docName="draft-ietf-roll-rpl-11" ipr="trust200902">
<front>
<title abbrev="draft-ietf-roll-rpl-11">RPL: IPv6 Routing Protocol for Low
power and Lossy Networks</title>
<author fullname="Tim Winter" initials="T" role="editor" surname="Winter">
<organization></organization>
<address>
<email>wintert@acm.org</email>
</address>
</author>
<author fullname="Pascal Thubert" initials="P" role="editor"
surname="Thubert">
<organization abbrev="Cisco Systems">Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author fullname="RPL Author Team" initials="" surname="RPL Author Team">
<organization>IETF ROLL WG</organization>
<address>
<email>rpl-authors@external.cisco.com</email>
</address>
</author>
<date day="28" month="July" year="2010" />
<area>Routing Area</area>
<workgroup>ROLL</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained: LLN routers
typically operate with constraints on (any subset of) processing power,
memory and energy (battery), and their interconnects are characterized
by (any subset of) high loss rates, low data rates and instability. LLNs
are comprised of anything from a few dozen and up to thousands of
routers, and support point-to-point traffic (between devices inside the
LLN), point-to-multipoint traffic (from a central control point to a
subset of devices inside the LLN) and multipoint-to-point traffic (from
devices inside the LLN towards a central control point). This document
specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a
mechanism whereby multipoint-to-point traffic from devices inside the
LLN towards a central control point, as well as point-to-multipoint
traffic from the central control point to the devices inside the LLN, is
supported. Support for point-to-point traffic is also available.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Low power and Lossy Networks (LLNs) consist of largely of constrained
nodes (with limited processing power, memory, and sometimes energy when
they are battery operated or energy scavenging). These routers are
interconnected by lossy links, typically supporting only low data rates,
that are usually unstable with relatively low packet delivery rates.
Another characteristic of such networks is that the traffic patterns are
not simply point-to-point, but in many cases point-to-multipoint or
multipoint-to-point. Furthermore such networks may potentially comprise
up to thousands of nodes. These characteristics offer unique challenges
to a routing solution: the IETF ROLL Working Group has defined
application-specific routing requirements for a Low power and Lossy
Network (LLN) routing protocol, specified in <xref
target="RFC5867"></xref>, <xref target="RFC5826"></xref>, <xref
target="RFC5673"></xref>, and <xref target="RFC5548"></xref>.</t>
<t>This document specifies the IPv6 Routing Protocol for Low power and
lossy networks (RPL). Note that although RPL was specified according to
the requirements set forth in the aforementioned requirement documents,
its use is in no way limited to these applications.</t>
<section title="Design Principles">
<t>RPL was designed with the objective to meet the requirements
spelled out in <xref target="RFC5867"></xref>, <xref
target="RFC5826"></xref>, <xref target="RFC5673"></xref>, and <xref
target="RFC5548"></xref>.</t>
<t>A network may run multiple instances of RPL concurrently. Each such
instance may serve different and potentially antagonistic constraints
or performance criteria. This document defines how a single instance
operates.</t>
<t>In order to be useful in a wide range of LLN application domains,
RPL separates packet processing and forwarding from the routing
optimization objective. Examples of such objectives include minimizing
energy, minimizing latency, or satisfying constraints. This document
describes the mode of operation of RPL. Other companion documents
specify routing objective functions. A RPL implementation, in support
of a particular LLN application, will include the necessary objective
function(s) as required by the application.</t>
<t>A set of companion documents to this specification will provide
further guidance in the form of applicability statements specifying a
set of operating points appropriate to the Building Automation, Home
Automation, Industrial, and Urban application scenarios.</t>
</section>
<section title="Expectations of Link Layer Type">
<t>In compliance with the layered architecture of IP, RPL does not
rely on any particular features of a specific link layer technology.
RPL is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low power wireless or PLC
(Power Line Communication) technologies.</t>
<t>Implementers may find <xref target="RFC3819"></xref> a useful
reference when designing a link layer interface between RPL and a
particular link layer technology.</t>
</section>
</section>
<section anchor="Terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>Additionally, this document uses terminology from <xref
target="I-D.ietf-roll-terminology"></xref>, and introduces the following
terminology: <list hangIndent="6" style="hanging">
<t hangText="DAG:">Directed Acyclic Graph. A directed graph having
the property that all edges are oriented in such a way that no
cycles exist. All edges are contained in paths oriented toward and
terminating at one or more root nodes.</t>
<t hangText="DAG root:">A DAG root is a node within the DAG that has
no outgoing edge. Because the graph is acyclic, by definition all
DAGs must have at least one DAG root and all paths terminate at a
DAG root.</t>
<t hangText="Destination Oriented DAG (DODAG):">A DAG rooted at a
single destination, i.e. at a single DAG root (the DODAG root) with
no outgoing edges.</t>
<t hangText="DODAG root:">A DODAG root is the DAG root of a
DODAG.</t>
<t hangText="Virtual DODAG root:">A Virtual DODAG root is the result
of two or more RPL routers, most typically LBRs, coordinating to
synchronize DODAG state and act in concert as if they are a single
DODAG root (with multiple interfaces), with respect to the LLN. The
coordination most likely occurs between powered devices over a
reliable transit link, and the details of that scheme are beyond the
scope of this specification.</t>
<t hangText="Up:">Up refers to the direction from leaf nodes towards
DODAG roots, following DODAG edges. This follows the common
terminology used in graphs and depth-first-search, where vertices
further from the root are "deeper," or "down," and vertices closer
to the root are "shallower," or "up".</t>
<t hangText="Down:">Down refers to the direction from DODAG roots
towards leaf nodes, in the reverse direction of DODAG edges. This
follows the common terminology used in graphs and
depth-first-search, where vertices further from the root are
"deeper," or "down," and vertices closer to the root are
"shallower," or "up".</t>
<t hangText="Rank:">A node's Rank defines the node's individual
position relative to other nodes with respect to a DODAG root. Rank
strictly increases in the Down direction and strictly decreases in
the Up direction. The exact way Rank is computed depends on the
DAG's Objective Function (OF). The Rank may analogously track a
simple topological distance, may be calculated as a function of link
metrics, and may consider other properties such as constraints.</t>
<t hangText="Objective Function (OF):">Defines how routing
metrics, optimization objectives, and related functions are used
to compute Rank. Furthermore, the OF dictates how parents in the
DODAG are selected and thus the DODAG formation itself.</t>
<t hangText="Objective Code Point (OCP):">An identifier that
indicates which Objective Function the DODAG uses.</t>
<t hangText="RPLInstanceID:">A unique identifier within a network.
DODAGs with the same RPLInstanceID share the same Objective
Function.</t>
<t hangText="RPL Instance:">A set of one or more DODAGs that share a
RPLInstanceID. A RPL node can belong to at most one DODAG in a RPL
Instance. Each RPL Instance operates independently of other RPL
Instances. This document describes operation within a single RPL
Instance.</t>
<t hangText="DODAGID:">The identifier of a DODAG root. The DODAGID
is unique within the scope of a RPL Instance in the LLN. The tuple
(RPLInstanceID, DODAGID) uniquely identifies a DODAG.</t>
<t hangText="DODAG Version:">A specific iteration ("Version") of a
DODAG with a given DODAGID.</t>
<t hangText="DODAGVersionNumber:">A sequential counter that is
incremented by the root to form a new Version of a DODAG. A DODAG
Version is identified uniquely by the (RPLInstanceID, DODAGID,
DODAGVersionNumber) tuple.</t>
<t hangText="Goal:">The Goal is an application specific goal that is
defined outside the scope of RPL. Any node that roots a DODAG will
need to know about this Goal to decide if the Goal can be satisfied
or not. A typical Goal is to construct the DODAG according to a
specific objective function and to keep connectivity to a set of
hosts (e.g. to use an objective function that minimizes a metric and to
be connected to a specific database host to store the collected
data).</t>
<t hangText="Grounded:">A DODAG is grounded when the DODAG root can
satisfy the Goal.</t>
<t hangText="Floating:">A DODAG is floating if it is not Grounded. A
floating DODAG is not expected to have the properties required to
satisfy the goal. It may, however, provide connectivity to other
nodes within the DODAG.</t>
<t hangText="DODAG parent:">A parent of a node within a DODAG is one
of the immediate successors of the node on a path towards the DODAG
root. A DODAG parent's Rank is lower than the node's. (See <xref
target="RankComparison"></xref>).</t>
<t hangText="Sub-DODAG">The sub-DODAG of a node is the set of other
nodes whose paths to the DODAG root pass through that node. Nodes in
the sub-DODAG of a node have a greater Rank than that node itself.
(See <xref target="RankComparison"></xref>).</t>
<t hangText="Local DODAG:">Local DODAGs contain one and only one
root node, and allows that single root node to allocate and manage a
RPL Instance, identified by a local RPLInstanceID, without
coordination with other nodes. This is typically done in order to
optimize routes to a destination withing the LLN. See <xref
target="RPLInstance"></xref>.</t>
<t hangText="Global DODAG:">A Global DODAG uses a global
RPLInstanceID that may be coordinated among several other nodes. See
<xref target="RPLInstance"></xref>.</t>
</list></t>
<t>As they form networks, LLN devices often mix the roles of 'host' and
'router' when compared to traditional IP networks. In this document,
'host' refers to an LLN device that can generate but does not forward
RPL traffic, 'router' refers to an LLN device that can forward as well
as generate RPL traffic, and 'node' refers to any RPL device, either a
host or a router.</t>
</section>
<section anchor="ProtocolModel" title="Protocol Overview">
<t>The aim of this section is to describe RPL in the spirit of <xref
target="RFC4101"></xref>. Protocol details can be found in further
sections.</t>
<section anchor="UpwardTopology" title="Topology">
<t>This section describes the basic RPL topologies that may be formed,
and the rules by which these are constructed, i.e. the rules governing
DODAG formation.</t>
<section anchor="TopologyIdentifiers" title="RPL Identifiers">
<t>RPL uses four values to identify and maintain a topology: <list
style="symbols">
<t>The first is a RPLInstanceID. A RPLInstanceID identifies a
set of one or more Destination Oriented DAGs (DODAGs). A network
may have multiple RPLInstanceIDs, each of which defines an
independent set of DODAGs, which may be optimized for different
Objective Functions (OFs) and/or applications. The set of DODAGs
identified by a RPLInstanceID is called a RPL Instance. All
DODAGs in the same RPL Instance use the same OF.</t>
<t>The second is a DODAGID. The scope of a DODAGID is a RPL
Instance. The combination of RPLInstanceID and DODAGID uniquely
identifies a single DODAG in the network. A RPL Instance may
have multiple DODAGs, each of which has an unique DODAGID.</t>
<t>The third is a DODAGVersionNumber. The scope of a
DODAGVersionNumber is a DODAG. A DODAG is sometimes
reconstructed from the DODAG root, by incrementing the
DODAGVersionNumber. The combination of RPLInstanceID, DODAGID,
and DODAGVersionNumber uniquely identifies a DODAG Version.</t>
<t>The fourth is Rank. The scope of Rank is a DODAG Version.
Rank establishes a partial order over a DODAG Version, defining
individual node positions with respect to the DODAG root.</t>
</list></t>
</section>
</section>
<section title="Instances, DODAGs, and DODAG Versions">
<t>A RPL Instance contains one or more DODAG roots. A RPL Instance may
provide routes to certain destination prefixes, reachable via the
DODAG roots or alternate paths within the DODAG. These roots may
operate independently, or may coordinate over a network that is not
necessarily as constrained as a LLN.</t>
<t>A RPL Instance may comprise:</t>
<t><list style="symbols">
<t>a single DODAG with a single root <list>
<t>For example, a DODAG optimized to minimize latency rooted
at a single centralized lighting controller in a home
automation application.</t>
</list></t>
<t>multiple uncoordinated DODAGs with independent roots (differing
DODAGIDs) <list>
<t>For example, multiple data collection points in an urban
data collection application that do not have suitable
connectivity to coordinate with each other, or that
use the formation of multiple DODAGs as a means to dynamically
and autonomously partition the network.</t>
</list></t>
<t>a single DODAG with a virtual root that coordinates LLN sinks
(with the same DODAGID) over a backbone network.<list>
<t>For example, multiple border routers operating with a
reliable transit link, e.g. in support of a 6LowPAN
application, that are capable to act as logically equivalent
interfaces to the sink of the same DODAG.</t>
</list></t>
<t>a combination of the above as suited to some application
scenario.</t>
</list></t>
<t>Each RPL packet is associated with a particular RPLInstanceID (see
<xref target="loopdetect"></xref>) and therefore RPL Instance (<xref
target="RPLInstance"></xref>). The provisioning or automated discovery
of a mapping between a RPLInstanceID and a type or service of
application traffic is beyond the scope of this specification.</t>
<t><xref target="figInstance"></xref> depicts an example of a RPL
Instance comprising three DODAGs with DODAG Roots R1, R2, and R3. Each
of these DODAG Roots advertises the same RPLInstanceID. The lines
depict connectivity between parents and children. Although tree-like
DODAGs are depicted for simplicity, the DODAG structure allows for
each node to have multiple parents when the connectivity supports
it.</t>
<t><xref target="figDODAGVersion"></xref> depicts how a DODAG Version
number increment leads to a new DODAG Version. This depiction
illustrates a DODAG Version number increment that results in a
different DODAG topology. Note that a new DODAG Version does not
always imply a different DODAG topology. To accommodate certain
topology changes requires a new DODAG Version, as described later in
this specification.</t>
<figure anchor="figInstance" title="RPL Instance">
<artwork><![CDATA[
+----------------------------------------------------------------+
| |
| +--------------+ |
| | | |
| | (R1) | (R2) (R3) |
| | / \ | /| \ / | \ |
| | / \ | / | \ / | \ |
| | (A) (B) | (C) | (D) ... (F) (G) (H) |
| | /|\ |\ | / | |\ | | | |
| | : : : : : | : (E) : : : : : |
| | | / \ |
| +--------------+ : : |
| DODAG |
| |
+----------------------------------------------------------------+
RPL Instance
]]></artwork>
</figure>
<figure anchor="figDODAGVersion" title="DODAG Version">
<artwork><![CDATA[
+----------------+ +----------------+
| | | |
| (R1) | | (R1) |
| / \ | | / |
| / \ | | / |
| (A) (B) | \ | (A) |
| /|\ |\ | ------\ | /|\ |
| : : (C) : : | \ | : : (C) |
| | / | \ |
| | ------/ | \ |
| | / | (B) |
| | | |\ |
| | | : : |
| | | |
+----------------+ +----------------+
Version N Version N+1
]]></artwork>
</figure>
</section>
<section title="Upward Routes and DODAG Construction">
<t>RPL provisions routes Up towards DODAG roots, forming a DODAG
optimized according to an Objective Function (OF). RPL nodes construct
and maintain these DODAGs through DODAG Information Object (DIO)
messages.</t>
<section title="Objective Function (OF)">
<t>The Objective Function (OF) defines how RPL nodes select and
optimize routes within a RPL Instance. The OF is identified by an
Objective Code Point (OCP) within the DIO Configuration option. An
OF defines how nodes translate one or more metrics and constraints,
which are themselves defined in <xref
target="I-D.ietf-roll-routing-metrics"></xref>, into a value called
Rank, which approximates the node's distance from a DODAG root. An
OF also defines how nodes select parents. Further details may be
found in <xref target="OFGuide"></xref>, <xref
target="I-D.ietf-roll-routing-metrics"></xref>, <xref
target="I-D.ietf-roll-of0"></xref>, and related companion
specifications.</t>
</section>
<section anchor="DODAGRepair" title="DODAG Repair">
<t>A DODAG Root institutes a global repair operation by incrementing
the DODAG Version Number. This initiates a new DODAG Version. Nodes
in the new DODAG Version can choose a new position whose Rank is not
constrained by their Rank within the old DODAG Version.</t>
<!-- CUT?
<t>RPL also supports local repair within a DODAG Version. Because
local repair can increase Rank, it can lead to issues such as the
count-to-infinity problem. DODAG roots can control the degree of
local repair allowed. If local repair is insufficient to maintain
routes, a root can institute a global repair operation.</t>
-->
<t>RPL also supports mechanisms which may be used for local repair
within the DODAG Version. The DIO message specifies the necessary
parameters as configured from and controlled by policy at the DODAG
root.</t>
<!-- Local repair options include allowing a node,
upon detecting a loss of connectivity to a DODAG it is a member of,
to:</t>
<t><list style="symbols">
<t>Poison its sub-DODAG by advertising an effective rank of
INFINITY to its sub-DODAG, OR detach and form a floating DODAG
in order to preserve inner connectivity within its
sub-DODAG.</t>
<t>Move down within the DODAG Version (i.e. increase its rank)
in a limited manner, no further than a bound configured by the
DODAG root via the DIO so as not to count all the way to
infinity. Such a move may be undertaken after waiting an
appropriate poisoning interval, and should allow the node to
restore connectivity to the DODAG Version, if at all
possible.</t>
</list></t>
-->
</section>
<section title="Security">
<t>RPL supports message confidentiality and integrity. It is
designed such that link-layer mechanisms can be used when available
and appropriate, yet in their absence RPL can use its own
mechanisms. RPL has three basic security modes.</t>
<t>In the first, called "unsecured," RPL control messages are sent
without any additional security mechanisms. Unsecured mode does not
imply that the RPL network is unsecure: it could be using other
present security primitives (e.g. link-layer security) to meet
application security requirements.</t>
<t>In the second, called "pre-installed," nodes joining a RPL
Instance have pre-installed keys that enable them to process and
generate secured RPL messages.</t>
<t>The third mode is called "authenticated." In authenticated mode,
nodes have pre-installed keys as in pre-installed mode, but the
pre-installed key may only be used to join a RPL Instance as a leaf.
Joining an authenticated RPL Instance as a router requires obtaining
a key from an authentication authority. The process by which this
key is obtained is outside the scope of this specification.</t>
</section>
<section title="Grounded and Floating DODAGs">
<t>DODAGs can be grounded or floating: the DODAG root advertises
which is the case. A grounded DODAG offers connectivity to hosts
that are required for satisfying the application-defined goal. A
floating DODAG is not expected to satisfy the goal and in most cases
only provides routes to nodes within the DODAG. Floating DODAGs may
be used, for example, to preserve inner connectivity during
repair.</t>
</section>
<section title="Local DODAGs">
<t>RPL nodes can optimize routes to a destination within an LLN by
forming a local DODAG whose DODAG Root is the desired destination.
Unlike global DAGs, which can consist of multiple DODAGs, local DAGs
have one and only one DODAG and therefore one DODAG Root. Local
DODAGs can be constructed on-demand.</t>
</section>
<section title="Administrative Preference">
<t>An implementation/deployment may specify that some DODAG roots
should be used over others through an administrative preference.
Administrative preference offers a way to control traffic and
engineer DODAG formation in order to better support application
requirements or needs.</t>
</section>
<section title="Datapath Validation and Loop Detection">
<t>RPL carries routing information in a RPL Option contained in an
IPv6 Hop-by-Hop Option as specified in <xref
target="I-D.ietf-6man-rpl-option"></xref>. Such routing information
is used, for example, for loop detection within a DODAG as discussed
in <xref target="loopdetect"></xref> and may be extended in future
documents for additional features.</t>
<t>Each data packet includes the Rank of the transmitter. An
inconsistency between the routing decision for a packet (upward or
downward) and the Rank relationship between the two nodes indicates
a possible loop. On receiving such a packet, a node institutes a
local repair operation.</t>
<t>For example, if a node receives a packet flagged as moving in the
upward direction, and if that packet records that the transmitter is
of a lower (lesser) Rank than the receiving node, then the receiving
node is able to conclude that the packet has not progressed in the
upward direction and that the DODAG is inconsistent.</t>
</section>
<section title="Distributed Algorithm Operation">
<t>A high level overview of the distributed algorithm, which
constructs the DODAG, is as follows:</t>
<t><list style="symbols">
<t>Some nodes are configured to be DODAG roots, with associated
DODAG configurations.</t>
<t>Nodes advertise their presence, affiliation with a DODAG,
routing cost, and related metrics by sending link-local
multicast DIO messages to all-RPL-nodes.</t>
<t>Nodes listen for DIOs and use their information to join a new
DODAG, or to maintain an existing DODAG, according to the
specified Objective Function and Rank of their neighbors.</t>
<!-- CUT? -->
<t>Nodes provision routing table entries, for the destinations
specified by the DIO message, via their DODAG parents in the
DODAG Version. Nodes that decide to join a DODAG MUST provision
a DODAG parent as a default route for the associated instance.
It is up to the end-to-end application to select the RPL
instance to be associated to its traffic (should there be more
than one instance) and thus the default route upwards when no
longer-match exists.</t>
</list></t>
</section>
</section>
<section title="Downward Routes and Destination Advertisement">
<t>RPL uses Destination Advertisement Object (DAO) messages to
establish downward routes. DAO messages are an optional feature for
applications that require P2MP or P2P traffic. RPL supports two modes
of downward traffic: storing (fully stateful) or non-storing (fully
source routed). Any given RPL Instance is either storing or
non-storing. In both cases, P2P packets travel Up toward a DODAG Root
then Down to the final destination (unless the destination is on the
upward route). In the non-storing case the packet will travel all the
way to a DODAG root before traveling Down. In the storing case the
packet may be directed Down towards the destination by a common
ancestor of the source and the destination prior to reaching a DODAG
Root.</t>
<t>This specification describes a basic mode of operation in support
of P2P traffic. Note that more optimized P2P solutions may be
described in companion specifications.</t>
</section>
<!-- CUT? -->
<section title="Local DODAGs Route Discovery">
<t>A RPL network can optionally support on-demand discovery of DODAGs
to specific destinations within an LLN. Such local DODAGs behave
slightly differently than global DODAGs: they are uniquely defined by
the combination of DODAGID and RPLInstanceID. The RPLInstanceID
denotes whether a DODAG is a local DODAG.</t>
</section>
<!-- CUT? -->
<section anchor="DAGRank" title="Rank Properties">
<t>The rank of a node is a scalar representation of the location of
that node within a DODAG Version. The rank is used to avoid and detect
loops, and as such must demonstrate certain properties. The exact
calculation of the rank is left to the Objective Function, and may
depend on parents, link metrics, node metrics, and the node
configuration and policies.</t>
<t>The rank is not a path cost, although its value can be derived from
and influenced by path metrics. The rank has properties of its own
that are not necessarily those of all metrics: <list hangIndent="8"
style="hanging">
<t hangText="Type:">The rank is an abstract numeric value.</t>
<t hangText="Function:">The rank is the expression of a relative
position within a DODAG Version with regard to neighbors and is
not necessarily a good indication or a proper expression of a
distance or a path cost to the root.</t>
<t hangText="Stability:">The stability of the rank determines the
stability of the routing topology. Some dampening or filtering is
RECOMMENDED to keep the topology stable, and thus the rank does
not necessarily change as fast as some link or node metrics would.
A new DODAG Version would be a good opportunity to reconcile the
discrepancies that might form over time between metrics and ranks
within a DODAG Version.</t>
<!--
<t hangText="Granularity:">The portion of the rank that is used
to define a node's position in the DAG, DAGRank(node), is coarse
grained. A fine granularity would make the selection of siblings
difficult, since siblings must have the exact same rank
value.</t>
-->
<t hangText="Properties:">The rank is incremented in a strictly
monotonic fashion, and can be used to validate a progression from
or towards the root. A metric, like bandwidth or jitter, does not
necessarily exhibit this property.</t>
<t hangText="Abstract:">The rank does not have a physical unit,
but rather a range of increment per hop, where the assignment of
each increment is to be determined by the Objective Function.</t>
</list></t>
<t>The rank value feeds into DODAG parent selection, according to the
RPL loop-avoidance strategy. Once a parent has been added, and a rank
value for the node within the DODAG has been advertised, the nodes
further options with regard to DODAG parent selection and movement
within the DODAG are restricted in favor of loop avoidance.</t>
<!-- CUT? -->
<section anchor="RankComparison" title="Rank Comparison (DAGRank())">
<t>Rank may be thought of as a fixed point number, where the
position of the radix point between the integer part and the
fractional part is determined by MinHopRankIncrease.
MinHopRankIncrease is the minimum increase in rank between a node
and any of its DODAG parents. A DODAG Root provisions
MinHopRankIncrease. MinHopRankIncrease creates a tradeoff between
hop cost precision and the maximum number of hops a network can
support. A very large MinHopRankIncrease, for example, allows
precise characterization of a given hop's affect on Rank but cannot
support many hops.</t>
<t>When an objective function computes rank, the objective function
operates on the entire (i.e. 16-bit) rank quantity. When rank is
compared, e.g. for determination of parent relationships or loop
detection, the integer portion of the rank is to be used. The
integer portion of the Rank is computed by the DAGRank() macro as
follows, where floor(x) is the function that evaluates to the
greatest integer less than or equal to x:</t>
<figure>
<artwork><![CDATA[
DAGRank(rank) = floor(rank/MinHopRankIncrease)
]]></artwork>
</figure>
<t>For example, if a 16-bit rank quantity is decimal 27, and the
MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) =
1. The integer part of the rank is 1 and the fractional part is
11/16.</t>
<t>By convention in this document, using the macro DAGRank(node) may
be interpreted as DAGRank(node.rank), where node.rank is the rank
value as maintained by the node.</t>
<t>A node A has a rank less than the rank of a node B if DAGRank(A)
is less than DAGRank(B).</t>
<t>A node A has a rank equal to the rank of a node B if DAGRank(A)
is equal to DAGRank(B).</t>
<t>A node A has a rank greater than the rank of a node B if
DAGRank(A) is greater than DAGRank(B).</t>
</section>
<!-- CUT? -->
<section title="Rank Relationships">
<t>Rank computations maintain the following properties for any nodes
M and N that are neighbors in the LLN:</t>
<t><list hangIndent="8" style="hanging">
<t hangText="DAGRank(M) is less than DAGRank(N):">In this case,
the position of M is closer to the DODAG root than the position
of N. Node M may safely be a DODAG parent for Node N without
risk of creating a loop. Further, for a node N, all parents in
the DODAG parent set must be of rank less than DAGRank(N). In
other words, the rank presented by a node N MUST be greater than
that presented by any of its parents.</t>
<t hangText="DAGRank(M) equals DAGRank(N):">In this case the
positions of M and N within the DODAG and with respect to the
DODAG root are similar (identical). Routing through a node with
equal Rank may cause a routing loop (i.e., if that node chooses
to route through a node with equal Rank as well).</t>
<t hangText="DAGRank(M) is greater than DAGRank(N):">In this
case, the position of M is farther from the DODAG root than the
position of N. Further, Node M may in fact be in the sub-DODAG
of Node N. If node N selects node M as DODAG parent there is a
risk to create a loop.</t>
</list></t>
<t>As an example, the rank could be computed in such a way so as to
closely track ETX (Expected Transmission Count, a fairly common
routing metric used in LLN and defined in <xref
target="I-D.ietf-roll-routing-metrics"></xref>) when the metric that
an objective function minimizes is ETX, or latency, or in a more complicated way as appropriate
to the objective function being used within the DODAG.</t>
</section>
</section>
<section anchor="ConstrainedLLNs"
title="Routing Metrics and Constraints Used By RPL">
<t>Routing metrics are used by routing protocols to compute shortest
paths. Interior Gateway Protocols (IGPs) such as IS-IS (<xref
target="RFC5120"></xref>) and OSPF (<xref target="RFC4915"></xref>)
use static link metrics. Such link metrics can simply reflect the
bandwidth or can also be computed according to a polynomial function
of several metrics defining different link characteristics. Some
routing protocols support more than one metric: in the vast majority
of the cases, one metric is used per (sub)topology. Less often, a
second metric may be used as a tie-breaker in the presence of Equal
Cost Multiple Paths (ECMP). The optimization of multiple metrics is
known as an NP complete problem and is sometimes supported by some
centralized path computation engine.</t>
<t>In contrast, LLNs do require the support of both static and dynamic
metrics. Furthermore, both link and node metrics are required. In the
case of RPL, it is virtually impossible to define one metric, or even
a composite metric, that will satisfy all use cases.</t>
<t>In addition, RPL supports constrained-based routing where
constraints may be applied to both link and nodes. If a link or a node
does not satisfy a required constraint, it is 'pruned' from the
candidate neighbor set, thus leading to a constrained shortest
path.</t>
<t>An Objective Function specifies the objectives used to compute the
(constrained) path. Furthermore, nodes are configured to support a set
of metrics and constraints, and select their parents in the DODAG
according the the metrics and constraints advertised in the DIO
messages. Upstream and Downstream metrics may be merged or advertised
separately depending on the OF and the metrics. When they are
advertised separately, it may happen that the set of DIO parents is
different from the set of DAO parents (a DAO parent is a node to which
unicast DAO messages are sent). Yet, all are DODAG parents with
regards to the rules for Rank computation.</t>
<t>The Objective Function itself is decoupled from the routing metrics
and constraints used by RPL. Indeed, whereas the OF dictates rules
such as DODAG parents selection, load balancing and so on, the set of
metrics and/or constraints used, and thus determine the preferred
path, are based on the information carried within the DAG container
option in DIO messages.</t>
<t>The set of supported link/node constraints and metrics is specified
in <xref target="I-D.ietf-roll-routing-metrics"></xref>.</t>
<t><list hangIndent="11" style="hanging">
<t hangText="Example 1:">Shortest path: path offering the shortest
end-to-end delay.</t>
<t hangText="Example 2:">Shortest Constrained path: the path that
does not traverse any battery-operated node and that optimizes the
path reliability.</t>
</list></t>
</section>
<!-- CUT? -->
<section title="Loop Avoidance">
<t>RPL avoids creating loops when undergoing topology changes and
includes rank-based datapath validation mechanisms for detecting loops
when they do occur (see <xref target="forwarding"></xref> for more
details). In practice, this means that RPL guarantees neither loop
free path selection nor tight delay convergence times, but can detect
and repair a loop as soon as it is used. RPL uses this loop detection
to ensure that packets make forward progress within the DODAG Version
and trigger repairs when necessary.</t>
<!-- CUT? -->
<section title="Greediness and Instability">
<t>A node is greedy if it attempts to move deeper (increase Rank) in
the DODAG Version in order to increase the size of the parent set or
improve some other metric. Once a node has joined a DODAG Version,
RPL disallows certain behaviors, including greediness, in order to
prevent resulting instabilities in the DODAG Version.</t>
<t>Suppose a node is willing to receive and process a DIO message
from a node in its own sub-DODAG, and in general a node deeper than
itself. In this case, a possibility exists that a feedback loop is
created, wherein two or more nodes continue to try and move in the
DODAG Version while attempting to optimize against each other. In
some cases, this will result in instability. It is for this reason
that RPL limits the cases where a node may process DIO messages from
deeper nodes to some forms of local repair. This approach creates an
'event horizon', whereby a node cannot be influenced beyond some
limit into an instability by the action of nodes that may be in its
own sub-DODAG.</t>
<!-- Greedy example -->
<section anchor="ExGreedyExample"
title="Example: Greedy Parent Selection and Instability">
<figure anchor="Greedy" title="Greedy DODAG Parent Selection">
<artwork><![CDATA[
(A) (A) (A)
|\ |\ |\
| `-----. | `-----. | `-----.
| \ | \ | \
(B) (C) (B) \ | (C)
\ | | /
`-----. | | .-----'
\| |/
(C) (B)
-1- -2- -3-
]]></artwork>
</figure>
<t><xref target="Greedy"></xref> depicts a DODAG in 3 different
configurations. A usable link between (B) and (C) exists in all 3
configurations. In <xref target="Greedy"></xref>-1, Node (A) is a
DODAG parent for Nodes (B) and (C). In <xref
target="Greedy"></xref>-2, Node (A) is a DODAG parent for Nodes
(B) and (C), and Node (B) is also a DODAG parent for Node (C). In
<xref target="Greedy"></xref>-3, Node (A) is a DODAG parent for
Nodes (B) and (C), and Node (C) is also a DODAG parent for Node
(B).</t>
<t>If a RPL node is too greedy, in that it attempts to optimize
for an additional number of parents beyond its most preferred
parents, then an instability can result. Consider the DODAG
illustrated in <xref target="Greedy"></xref>-1. In this example,
Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but
we will consider the case when they are operating under the greedy
condition that will try to optimize for 2 parents.</t>
<t><list style="symbols">
<t>Let <xref target="Greedy"></xref>-1 be the initial
condition.</t>
<t>Suppose Node (C) first is able to leave the DODAG and
rejoin at a lower rank, taking both Nodes (A) and (B) as DODAG
parents as depicted in <xref target="Greedy"></xref>-2. Now
Node (C) is deeper than both Nodes (A) and (B), and Node (C)
is satisfied to have 2 DODAG parents.</t>
<t>Suppose Node (B), in its greediness, is willing to receive
and process a DIO message from Node (C) (against the rules of
RPL), and then Node (B) leaves the DODAG and rejoins at a
lower rank, taking both Nodes (A) and (C) as DODAG parents.
Now Node (B) is deeper than both Nodes (A) and (C) and is
satisfied with 2 DAG parents.</t>
<t>Then Node (C), because it is also greedy, will leave and
rejoin deeper, to again get 2 parents and have a lower rank
then both of them.</t>
<t>Next Node (B) will again leave and rejoin deeper, to again
get 2 parents</t>
<t>And again Node (C) leaves and rejoins deeper...</t>
<t>The process will repeat, and the DODAG will oscillate
between <xref target="Greedy"></xref>-2 and <xref
target="Greedy"></xref>-3 until the nodes count to infinity
and restart the cycle again.</t>
<t>This cycle can be averted through mechanisms in RPL: <list>
<t>Nodes (B) and (C) stay at a rank sufficient to attach
to their most preferred parent (A) and don't go for any
deeper (worse) alternate parents (Nodes are not
greedy)</t>
<t>Nodes (B) and (C) do not process DIO messages from
nodes deeper than themselves (because such nodes are
possibly in their own sub-DODAGs)</t>
</list></t>
</list></t>
</section>
<!-- /Greed example -->
</section>
<!-- CUT? -->
<section title="DODAG Loops">
<t>A DODAG loop may occur when a node detaches from the DODAG and
reattaches to a device in its prior sub-DODAG. This may happen in
particular when DIO messages are missed. Strict use of the DODAG
Version Number can eliminate this type of loop, but this type of
loop may possibly be encountered when using some local repair
mechanisms.</t>
<t>For example, consider the local repair mechanism that allows a
node to detach from the DODAG, advertise a rank of INFINITE_RANK (in
order to poison its routes / inform its sub-DODAG), and then to
re-attach to the DODAG. In that case the node may in some cases
re-attach to its own prior-sub-DODAG, causing a DODAG loop, because
the poisoning may fail if the INFINITE_RANK advertisements are lost
in the LLN environment. (In this case the rank-based datapath
validation mechanisms would eventually detect and trigger correction
of the loop)</t>
</section>
<!-- CUT? -->
<section title="DAO Loops">
<t>A DAO loop may occur when the parent has a route installed upon
receiving and processing a DAO message from a child, but the child
has subsequently cleaned up the related DAO state. This loop happens
when a No-Path (a DAO message that invalidates a previously
announced prefix) was missed and persists until all state has been
cleaned up. RPL includes an optional mechanism to acknowledge DAO
messages, which may mitigate the impact of a single DAO message
being missed. RPL includes loop detection mechanisms that may
mitigate the impact of DAO loops and trigger their repair.</t>
<!-- t>In the case where stateless DAO operation is used, i.e. source
routing specifies the Down routes, then DAO Loops should not occur
on the stateless portions of the path.</t -->
</section>
<!-- CUT? -->
</section>
</section>
<section title="Traffic Flows Supported by RPL">
<t>RPL supports three basic traffic flows: Multipoint-to-Point (MP2P),
Point-to-Multipoint (P2MP), and Point-to-Point (P2P).</t>
<section title="Multipoint-to-Point Traffic">
<t>Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN
applications (<xref target="RFC5867"></xref>, <xref
target="RFC5826"></xref>, <xref target="RFC5673"></xref>, <xref
target="RFC5548"></xref>). The destinations of MP2P flows are
designated nodes that have some application significance, such as
providing connectivity to the larger Internet or core private IP
network. RPL supports MP2P traffic by allowing MP2P destinations to be
reached via DODAG roots.</t>
</section>
<section title="Point-to-Multipoint Traffic">
<t>Point-to-multipoint (P2MP) is a traffic pattern required by several
LLN applications (<xref target="RFC5867"></xref>, <xref
target="RFC5826"></xref>, <xref target="RFC5673"></xref>, <xref
target="RFC5548"></xref>). RPL supports P2MP traffic by using a
destination advertisement mechanism that provisions Down routes toward
destinations (prefixes, addresses, or multicast groups), and away from
roots. Destination advertisements can update routing tables as the
underlying DODAG topology changes.</t>
</section>
<section title="Point-to-Point Traffic">
<t>RPL DODAGs provide a basic structure for point-to-point (P2P)
traffic. For a RPL network to support P2P traffic, a root must be able
to route packets to a destination. Nodes within the network may also
have routing tables to destinations. A packet flows towards a root
until it reaches an ancestor that has a known route to the
destination. As pointed out later in this document, in the most
constrained case (when nodes cannot store routes), that common
ancestor may be the DODAG root. In other cases it may be a node closer
to both the source and destination.</t>
<t>RPL also supports the case where a P2P destination is a 'one-hop'
neighbor.</t>
<t>RPL neither specifies nor precludes additional mechanisms for
computing and installing potentially more optimal routes to support
arbitrary P2P traffic.</t>
</section>
</section>
<section anchor="RPLInstance" title="RPL Instance">
<t>Within a given LLN, there may be multiple, logically independent RPL
instances. A RPL node may belong to multiple RPL instances, and may act
as a router in some and as a leaf in others. This document describes how
a single instance behaves.</t>
<t>There are two types of RPL Instances: local and global. RPL divides
the RPLInstanceID space between Global and Local instances to allow for
both coordinated and unilateral allocation of RPLInstanceIDs. Global RPL
Instances are coordinated, have one or more DODAGs, and are typically
long-lived. Local RPL Instances are always a single DODAG whose singular
root owns the corresponding DODAGID and allocates the Local
RPLInstanceID in a unilateral manner. Local RPL Instances can be used,
for example, for constructing DODAGs in support of a future on-demand
routing solution. The mode of operation of Local RPL Instances is
outside of the scope of this document and may be described in other
companion specifications.</t>
<t>The definition and provisioning of RPL instances are beyond the scope
of this specification. Those operations are expected to be such that
data packets coming from the outside of the RPL network can
unambiguously be associated to at least one RPL instance, and be safely
routed over any instance that would match the packet. Information used
to match a packet to a RPL instance can typically be taken from fields
in the IPv6 header, like the flow label, differentiated services (DS)
field, or destination address.</t>
<!-- CUT? -->
<t>Control and data packets within RPL network are tagged to
unambiguously identify what RPL Instance they are part of.</t>
<t>Every RPL control message has a RPLInstanceID field. Some RPL control
messages, when referring to a local RPLInstanceID as defined below, may
also include a DODAGID.</t>
<t>Data packets that flow within the RP network expose the RPLInstanceID
in the RPL option that is specified in <xref
target="I-D.ietf-6man-rpl-option"></xref>, and further described in
<xref target="loopdetect"></xref>. For data packets coming from outside
the RPL network, the RPLInstanceID is determined by the RPL network
ingress router and placed in the RPL option that is added to the
packet.</t>
<section anchor="RPLinstanceID" title="RPL Instance ID">
<t>A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms
for allocating and provisioning global RPLInstanceID are out of scope
for this document. There can be up to 128 global instance in the whole
network. Local instances are always used in conjunction with a DODAGID
(which is either given explicitly or implicitly in some cases), and up
64 local instances per DODAGID can be supported. Local instances are
allocated and managed by the node that owns the DODAGID, without any
explicit coordination with other nodes, as further detailed below.</t>
<t>A global RPLinstanceID is encoded in a RPLinstanceID field as
follows: <figure anchor="GRIDFormat"
title="RPL Instance ID field format for global instances">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLinstanceID in 0..127
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>A local RPLInstanceID is autoconfigured by the node that owns the
DODAGID and it MUST be unique for that DODAGID. The DODAGID used to
configure the local RPLInstanceID MUST be a reachable IPv6 address of
the node, and MUST be used as an endpoint of all communications within
that local instance.</t>
<t>A local RPLinstanceID is encoded in a RPLinstanceID field as
follows: <figure anchor="LRIDFormat"
title="RPL Instance ID field format for local instances">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The D flag in a Local RPLInstanceID is always set to 0 in RPL
control messages. It is used in data packets to indicate whether the
DODAGID is the source or the destination of the packet. If the D flag
is set to 1 then the destination address of the IPv6 packet MUST be
the DODAGID. If the D flag is cleared then the source address of the
IPv6 packet MUST be the DODAGID.</t>
<t>For example, consider a node A that is the DODAG Root of a local
RPL Instance, and has allocated a local RPLInstanceID. By definition,
all traffic traversing that local RPL Instance will either originate
or terminate at node A. The DODAGID in this case will be the reachable
IPv6 address of node A, and all traffic will contain the address of
node A, thus the DODAGID, in either the source or destination address.
Thus the Local RPLInstanceID may indicate that the DODAGID is
equivalent to either the source address or the destination address by
setting the D flag appropriately.</t>
</section>
</section>
<section anchor="RPLControlMessage" title="ICMPv6 RPL Control Message">
<t>This document defines the RPL Control Message, a new ICMPv6 message.
A RPL Control Message is identified by a code, and composed of a base
that depends on the code, and a series of options.</t>
<t>A RPL Control Message has the scope of a link. The source address is
a link local address. The destination address is either the RPL nodes
multicast address or a unicast address. The all-RPL-nodes multicast
address is a new address with a requested value of FF02::1A (to be
confirmed by IANA).</t>
<t>In accordance with <xref target="RFC4443"></xref>, the RPL Control
Message consists of an ICMPv6 header followed by a message body. The
message body is comprised of a message base and possibly a number of
options as illustrated in <xref target="RPLCtrlICMPFormat"></xref>.</t>
<t><figure anchor="RPLCtrlICMPFormat" title="RPL Control Message">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The RPL Control message is an ICMPv6 information message with a
requested Type of 155 (to be confirmed by IANA).</t>
<t>The Code field identifies the type of RPL Control Message. This
document defines codes for the following RPL Control Message types (all
codes are to be confirmed by IANA <xref
target="RPLCtrlCodeReg"></xref>):</t>
<t><list style="symbols">
<t>0x00: DODAG Information Solicitation (<xref
target="DAGInformationSolicitation"></xref>)</t>
<t>0x01: DODAG Information Object (<xref
target="DAGInformationObject"></xref>)</t>
<t>0x02: Destination Advertisement Object (<xref
target="DestinationAdvertisementObject"></xref>)</t>
<t>0x03: Destination Advertisement Object Acknowledgment (<xref
target="DestinationAdvertisementObjectAck"></xref>)</t>
<t>0x80: Secure DODAG Information Solicitation (<xref
target="SecureDAGInformationSolicitation"></xref>)</t>
<t>0x81: Secure DODAG Information Object (<xref
target="SecureDAGInformationObject"></xref>)</t>
<t>0x82: Secure Destination Advertisement Object (<xref
target="SecureDestinationAdvertisementObject"></xref>)</t>
<t>0x83: Secure Destination Advertisement Object Acknowledgment
(<xref target="SecureDestinationAdvertisementObjectAck"></xref>)</t>
<t>0x8A: Consistency Check (<xref
target="ConsistencyCheck"></xref>)</t>
</list></t>
<t>The high order bit (0x80) of the code denotes whether the RPL message
has security enabled. Secure RPL messages have a format to support
confidentiality and integrity, illustrated in <xref
target="RPLSecureCtrlICMPFormat"></xref>.</t>
<t><figure anchor="RPLSecureCtrlICMPFormat"
title="Secure RPL Control Message">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Security .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The remainder of this section describes the currently defined RPL
Control Message Base formats followed by the currently defined RPL
Control Message Options.</t>
<section anchor="RPLSecurityFields" title="RPL Security Fields">
<t>Each RPL message has a secure variant. The secure variants provide
integrity and replay protection as well as optional confidentiality
and delay protection. Because security covers the base message as well
as options, in secured messages the security information lies between
the checksum and base, as shown in <xref
target="RPLSecureCtrlICMPFormat"></xref>.</t>
<!-- t>Because many deployments may rely on link-layer or other security
mechanisms to meet their security requirements and implementation
complexity is a core concern for LLNs, the security features described
in this document are OPTIONAL. A given implementation MAY support a
subset of the described security features, for example support
integrity and confidentiality but not signatures.</t -->
<t>
The level of security and the algorithms in use are indicated in
the protocol messages as described below:</t>
<t><figure anchor="RPLSecuritySection" title="Security Section">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Level | Algorithm | KIM |Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>Message authentication codes (MACs) and signatures cover the entire
ICMPv6 RPL message, while encryption starts after the Security
section. Use of the Security section is further detailed in <xref
target="Security"></xref>.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Security Control Field:">The Security Control Field
has one flag and three fields: <list hangIndent="6"
style="hanging">
<t hangText="Counter is Time (T):">If the Counter is Time flag
is set then the Counter field is a timestamp. If the flag is
cleared then the Counter is an incrementing counter. <xref
target="SecurityCounter"></xref> describes the details of the
'T' flag and Counter field.</t>
<t hangText="Security Level (Level):">The Security Level field
indicates the provided packet protection. This value can be
adapted on a per-packet basis and allows for varying levels of
data authenticity and, optionally, for data confidentiality.
The KIM field indicates whether signatures are used and the
meaning of the Level field. The Security Level is set to one
of the non-reserved values in the tables below: <figure
anchor="LVLEncoding" title="Security Level (LVL) Encoding">
<artwork><![CDATA[
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-127 | Reserved | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2-127 | Reserved | N/A |
+-------+---------------+-----+
]]></artwork>
</figure>The MAC attribute indicates that the message has a
Message Authentication Code of the specified length. The ENC
attribute indicates that the message is encrypted. The Sign
attribute indicates that the message has a signature of the
specified length.</t>
<t hangText="Security Algorithm (Algorithm):">The Security
Algorithm field specifies the encryption, MAC, and signature
scheme the network uses. Supported values of this field are as
follows: <figure anchor="SecurityEncoding"
title="Security Algorithm (Algorithm) Encoding">
<artwork><![CDATA[
+-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+
| 0 | CCM* with AES-128 | RSA with SHA2 |
| 1-255 | Reserved | Reserved |
+-------+-------------------+----------------------------+
]]></artwork>
</figure> <xref target="CryptoMode"></xref> describes the
algorithms in greater detail.</t>
<t hangText="Key Identifier Mode (KIM):">The Key Identifier
Mode field indicates whether the key used for packet
protection is determined implicitly or explicitly and
indicates the particular representation of the Key Identifier
field. The Key Identifier Mode is set one of the non-reserved
values from the table below: <figure anchor="KIMEncoding"
title="Key Identifier Mode (KIM) Encoding">
<artwork><![CDATA[
+------+-----+-----------------------------+------------+
| Mode | KIM | Meaning | Key |
| | | | Identifier |
| | | | Length |
| | | | (octets) |
+------+-----+-----------------------------+------------+
| 0 | 00 | Group key used. | 1 |
| | | Key determined by Key Index | |
| | | field. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 1 | 01 | Per-pair key used. | 0 |
| | | Key determined by source | |
| | | and destination of packet. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is not present. | |
+------+-----+-----------------------------+------------+
| 2 | 10 | Group key used. | 9 |
| | | Key determined by Key Index | |
| | | and Key Source Identifier. | |
| | | | |
| | | Key Source is present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 3 | 11 | Node's signature key used. | 0/9 |
| | | If packet is encrypted, |
| | | it uses a group key, Key | |
| | | Index and Key Source | |
| | | specify key. | |
| | | | |
| | | Key Source may be present. | |
| | | Key Index may be present. | |
+------+-----+-----------------------------+------------+
]]></artwork>
</figure> In Mode 3 (KIM=11), the presence or absence of the
Key Source and Key Identifier depends on the Security Level
(LVL) described below. If the Security Level indicates there
is encryption, then the fields are present; if it indicates
there is no encryption, then the fields are not present.</t>
</list></t>
<t hangText="Reserved:">5-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="Flags:">8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Counter:">The Counter field indicates the
non-repeating 4-octet value (nonce) used with the cryptographic
mechanism that implements packet protection and allows for the
provision of semantic security.</t>
<t hangText="Key Identifier:">The Key Identifier field indicates
which key was used to protect the packet. This field provides
various levels of granularity of packet protection, including
peer-to-peer keys, group keys, and signature keys. This field is
represented as indicated by the Key Identifier Mode field and is
formatted as follows: <figure anchor="KeyIdentifier"
title="Key Identifier">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Source .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Index .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure><list hangIndent="6" style="hanging">
<t hangText="Key Source:">The Key Source field, when present,
indicates the logical identifier of the originator of a group
key. When present this field is 8 bytes in length.</t>
<t hangText="Key Index:">The Key Index field, when present,
allows unique identification of different keys with the same
originator. It is the responsibility of each key originator to
make sure that actively used keys that it issues have distinct
key indices and that all key indices have a value unequal to
0x00. Value 0x00 is reserved for a pre-installed, shared key.
When present this field is 1 byte in length.</t>
</list></t>
</list></t>
<t>Unassigned bits of the Security section are reserved. They MUST be
set to zero on transmission and MUST be ignored on reception.</t>
</section>
<section anchor="DAGInformationSolicitation"
title="DODAG Information Solicitation (DIS)">
<t>The DODAG Information Solicitation (DIS) message may be used to
solicit a DODAG Information Object from a RPL node. Its use is
analogous to that of a Router Solicitation as specified in IPv6
Neighbor Discovery; a node may use DIS to probe its neighborhood for
nearby DODAGs. <xref target="DIOTransmission"></xref> describes how
nodes respond to a DIS.</t>
<section title="Format of the DIS Base Object">
<t><figure anchor="DISBase" title="The DIS Base Object">
<artwork><![CDATA[
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Flags:">8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Reserved:">8-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
</list></t>
<t>Unassigned bits of the DIS Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.</t>
</section>
<section anchor="SecureDAGInformationSolicitation" title="Secure DIS">
<t>A Secure DIS message follows the format in <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DIS message shown in <xref target="DISBase"></xref>.</t>
</section>
<section title="DIS Options">
<t>The DIS message MAY carry valid options.</t>
<t>This specification allows for the DIS message to carry the
following options: <?rfc subcompact="yes"?><list>
<t>0x00 Pad1</t>
<t>0x01 PadN</t>
<t>0x07 Solicited Information</t>
</list><?rfc subcompact="no"?></t>
</section>
</section>
<section anchor="DAGInformationObject"
title="DODAG Information Object (DIO)">
<t>The DODAG Information Object carries information that allows a node
to discover a RPL Instance, learn its configuration parameters, select
a DODAG parent set, and maintain the DODAG.</t>
<section title="Format of the DIO Base Object">
<t><figure anchor="DIObase" title="The DIO Base Object">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Control Field:">The DAG Control Field has three
flags and two fields: <list hangIndent="6" style="hanging">
<t hangText="Grounded (G):">The Grounded (G) flag indicates
whether the DODAG advertised can satisfy the
application-defined goal. If the flag is set, the DODAG is
grounded. If the flag is cleared, the DODAG is floating.</t>
<!--
<t> hangText="Destination Advertisement Supported (A):">The
Destination Advertisement Supported (A) flag indicates
whether the root of this DODAG can collect and use downward
route state. If the flag is set, nodes in the network are
enabled to exchange destination advertisements messages to
build downward routes (<xref
target="DownwardRoutes"></xref>). If the flag is cleared,
destination advertisement messages are disabled and the
DODAG maintains only upward routes.</t>
-->
<!--
<t hangText="Destination Advertisement Trigger (T):">The
Destination Advertisement Trigger (T) flag indicates a
complete refresh of downward routes. If the flag is set,
then a refresh of downward route state is to take place over
the entire DODAG. If the flag is cleared, the downward route
maintenance is in its normal mode of operation. The further
details of this process are described in <xref
target="DownwardRoutes"></xref>.</t>
-->
<t hangText="Mode of Operation (MOP):">The Mode of Operation
(MOP) field identifies the mode of operation of the RPL
Instance as administratively provisioned at and distributed
by the DODAG Root. All nodes who join the DODAG must be able
to honor the MOP in order to fully participate as a router,
or else they must only join as a leaf. MOP is encoded as in
the figure below:<figure anchor="MOPEncoding"
title="Mode of Operation (MOP) Encoding">
<artwork><![CDATA[
+-----+-------------------------------------------------+
| MOP | Meaning |
+-----+-------------------------------------------------+
| 000 | No downward routes maintained by RPL |
| 001 | Non storing mode |
| 010 | Storing without multicast support |
| 011 | Storing with multicast support |
| | |
| | All other values are reserved |
+-----+-------------------------------------------------+
]]></artwork>
<postamble>A value of 000 indicates that destination
advertisement messages are disabled and the DODAG
maintains only upward routes</postamble>
</figure></t>
<t hangText="DODAGPreference (Prf):">A 3-bit unsigned
integer that defines how preferable the root of this DODAG
is compared to other DODAG roots within the instance.
DAGPreference ranges from 0x00 (least preferred) to 0x07
(most preferred). The default is 0 (least preferred). <xref
target="DAGDiscovery"></xref> describes how DAGPreference
affects DIO processing.</t>
</list></t>
<t hangText="Version Number:">8-bit unsigned integer set by the
DODAG root to the DODAGVersionNumber. <xref
target="DAGDiscovery"></xref> describes the rules for DODAG
Version numbers and how they affect DIO processing.</t>
<t hangText="Rank:">16-bit unsigned integer indicating the DODAG
rank of the node sending the DIO message. <xref
target="DAGDiscovery"></xref> describes how Rank is set and how
it affects DIO processing.</t>
<t hangText="RPLInstanceID:">8-bit field set by the DODAG root
that indicates which RPL Instance the DODAG is part of.</t>
<t
hangText="Destination Advertisement Trigger Sequence Number (DTSN):">8-bit
unsigned integer set by the node issuing the DIO message. The
Destination Advertisement Trigger Sequence Number (DTSN) flag is
used as part of the procedure to maintain downward routes. The
details of this process are described in <xref
target="DownwardRoutes"></xref>.</t>
<t hangText="Flags:">8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Reserved:">8-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="DODAGID:">128-bit IPv6 address set by a DODAG root
which uniquely identifies a DODAG. The DODAGID MUST be a
routable IPv6 address belonging to the DODAG root.</t>
</list></t>
<t>Unassigned bits of the DIO Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.</t>
</section>
<section anchor="SecureDAGInformationObject" title="Secure DIO">
<t>A Secure DIO message follows the format in <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DIO message shown in <xref target="DIObase"></xref>.</t>
</section>
<section title="DIO Options">
<t>The DIO message MAY carry valid options.</t>
<t>This specification allows for the DIO message to carry the
following options: <?rfc subcompact="yes"?><list>
<t>0x00 Pad1</t>
<t>0x01 PadN</t>
<t>0x02 Metric Container</t>
<t>0x03 Routing Information</t>
<t>0x04 DODAG Configuration</t>
<t>0x08 Prefix Information</t>
</list><?rfc subcompact="no"?></t>
</section>
</section>
<section anchor="DestinationAdvertisementObject"
title="Destination Advertisement Object (DAO)">
<t>The Destination Advertisement Object (DAO) is used to propagate
destination information upwards along the DODAG. In storing mode the
DAO message is unicast by the child to the selected parent(s). In
non-storing mode the DAO message is unicast to the DODAG root. The DAO
message may optionally, upon explicit request or error, be
acknowledged by its destination with a Destination Advertisement
Acknowledgement (DAO-ACK) message back to the sender of the DAO.</t>
<section title="Format of the DAO Base Object">
<t><figure anchor="DAObject" title="The DAO Base Object">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>The '*' denotes that the DODAGID is not always
present, as described below.</postamble>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="RPLInstanceID:">8-bit field indicating the topology
instance associated with the DODAG, as learned from the DIO.</t>
<t hangText="K:">The 'K' flag indicates that the recipient is
expected to send a DAO-ACK back. (See <xref
target="DAOBaseRules"></xref></t>
<t hangText="D:">The 'D' flag indicates that the DODAGID field
is present. This flag MUST be set when a local RPLInstanceID is
used.</t>
<t hangText="Flags:">6-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Reserved:">8-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="DAOSequence:">Incremented at each unique DAO
message from a node and echoed in the DAO-ACK message.</t>
<t hangText="DODAGID (optional):">128-bit unsigned integer set
by a DODAG root which uniquely identifies a DODAG. This field is
only present when the 'D' flag is set. This field is typically
only present when a local RPLInstanceID is in use, in order to
identify the DODAGID that is associated with the RPLInstanceID.
When a global RPLInstanceID is in use this field need not be
present.</t>
</list></t>
<t>Unassigned bits of the DAO Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.</t>
</section>
<section anchor="SecureDestinationAdvertisementObject"
title="Secure DAO">
<t>A Secure DAO message follows the format in <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DAO message shown in <xref target="DAObject"></xref>.</t>
</section>
<section anchor="DAOOptions" title="DAO Options">
<t>The DAO message MAY carry valid options.</t>
<t>This specification allows for the DAO message to carry the
following options: <?rfc subcompact="yes"?><list>
<t>0x00 Pad1</t>
<t>0x01 PadN</t>
<t>0x05 RPL Target</t>
<t>0x06 Transit Information</t>
<t>0x09 RPL Target Descriptor</t>
</list><?rfc subcompact="no"?></t>
<t>A special case of the DAO message, termed a No-Path, is used in
storing mode to clear downward routing state that has been
provisioned through DAO operation. The No-Path carries a Target
option and an associated Transit Information option with a lifetime
of 0x00000000 to indicate a loss of reachability to that Target.</t>
</section>
</section>
<section anchor="DestinationAdvertisementObjectAck"
title="Destination Advertisement Object Acknowledgement (DAO-ACK)">
<t>The DAO-ACK message is sent as a unicast packet by a DAO recipient
(a DAO parent or DODAG root) in response to a unicast DAO message.</t>
<section title="Format of the DAO-ACK Base Object">
<t><figure anchor="DAOackbject" title="The DAO ACK Base Object">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>The '*' denotes that the DODAGID is not always
present, as described below.</postamble>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="RPLInstanceID:">8-bit field indicating the topology
instance associated with the DODAG, as learned from the DIO.</t>
<t hangText="D:">The 'D' flag indicates that the DODAGID field
is present. This would typically only be set when a local
RPLInstanceID is used.</t>
<t hangText="Flags:">7-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="DAOSequence:">Incremented at each DAO message from
a node, and echoed in the DAO-ACK by the recipient. The
DAOSequence is used to correlate a DAO message and a DAO ACK
message and is not to be confused with the Transit Information
option Path Sequence that is associated to a given target Down
the DODAG.</t>
<t hangText="Status:">Indicates the completion. Status 0 is
unqualified acceptance, 1 to 127 are reserved and undetermined,
and 128 and greater are rejection codes used to indicate that
the node should select an alternate parent.</t>
<t hangText="DODAGID (optional):">128-bit unsigned integer set
by a DODAG root which uniquely identifies a DODAG. This field is
only present when the 'D' flag is set. This field is typically
only present when a local RPLInstanceID is in use, in order to
identify the DODAGID that is associated with the RPLInstanceID.
When a global RPLInstanceID is in use this field need not be
present.</t>
</list></t>
<t>Unassigned bits of the DAO-ACK Base are reserved. They MUST be
set to zero on transmission and MUST be ignored on reception.</t>
</section>
<section anchor="SecureDestinationAdvertisementObjectAck"
title="Secure DAO-ACK">
<t>A Secure DAO-ACK message follows the format in <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DAO-ACK message shown in <xref target="DAOackbject"></xref>.</t>
</section>
<section anchor="DAOackOptions" title="DAO-ACK Options">
<t>This specification does not define any options to be carried by
the DAO-ACK message.</t>
</section>
</section>
<section anchor="ConsistencyCheck" title="Consistency Check (CC)">
<t>The CC message is used to check secure message counters and issue
challenge/responses. A CC message MUST be sent as a secured RPL
message.</t>
<t>A CC message (request or response) MUST NOT set the 'C' bit of the
security section: CC messages always have full counters.</t>
<section title="Format of the CC Base Object">
<t><figure anchor="CC" title="The CC Base Object">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |R| Flags | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="RPLInstanceID:">8-bit field indicating the topology
instance associated with the DODAG, as learned from the DIO.</t>
<t hangText="R:">The 'R' flag indicates whether the CC message
is a response. A message with the 'R' flag cleared is a request;
a message with the 'R' flag set is a response. A CC message with
the R bit set MUST NOT compress the security Counter field: the
C bit of the security section MUST be 0.</t>
<t hangText="Flags:">7-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Nonce:">16-bit unsigned integer set by a CC
request. The corresponding CC response includes the same nonce
value as the request.</t>
<t hangText="Destination Counter:">32-bit unsigned integer value
indicating the sender's estimate of the destination's current
security Counter value. If the sender does not have an estimate,
it SHOULD set the Destination Counter field to zero.</t>
</list></t>
<t>Unassigned bits of the CC Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.</t>
<t>The Destination Counter value allows new or recovered nodes to
resynchronize through CC message exchanges. This is important to
ensure that a Counter value is not repeated for a given security key
even in the event of devices recovering from a failure that created
a loss of Counter state. For example, where a CC request or other
RPL message is received with an initialized Counter within the
message security section, the provision of the Incoming Counter
within the CC response message allows the requesting node to reset
its Outgoing Counter to a value greater than the last value received
by the responding node; the Incoming Counter will also be updated
from the received CC response.</t>
</section>
<section title="CC Options">
<t>The CC message MAY carry valid options. In the scope of this
specification, there are no valid options for a CC message.</t>
<t>This specification allows for the CC message to carry the
following options: <?rfc subcompact="yes"?><list>
<t>0x00 Pad1</t>
<t>0x01 PadN</t>
</list><?rfc subcompact="no"?></t>
</section>
</section>
<section anchor="RPLMsgOptions" title="RPL Control Message Options">
<section title="RPL Control Message Option Generic Format">
<t>RPL Control Message Options all follow this format: <figure
anchor="DIOsub" title="RPL Option Generic Format">
<artwork><![CDATA[
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">8-bit identifier of the type of
option. The Option Type values are to be confirmed by IANA <xref
target="RPLCtrlMsgOptionsReg"></xref>.</t>
<t hangText="Option Length:">8-bit unsigned integer,
representing the length in octets of the option, not including
the Option Type and Length fields.</t>
<t hangText="Option Data:">A variable length field that contains
data specific to the option.</t>
</list></t>
<t>When processing a RPL message containing an option for which the
Option Type value is not recognized by the receiver, the receiver
MUST silently ignore the unrecognized option and continue to process
the following option, correctly handling any remaining options in
the message.</t>
<t>RPL message options may have alignment requirements. Following
the convention in IPv6, options with alignment requirements are
aligned in a packet such that multi-octet values within the Option
Data field of each option fall on natural boundaries (i.e., fields
of width n octets are placed at an integer multiple of n octets from
the start of the header, for n = 1, 2, 4, or 8).</t>
</section>
<section title="Pad1">
<t>The Pad1 option MAY be present in DIS, DIO, DAO, and DAO-ACK
messages, and its format is as follows:</t>
<t><figure anchor="DIOsubPad1" title="Format of the Pad 1 Option">
<artwork><![CDATA[
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The Pad1 option is used to insert one or two octets of padding
into the message to enable options alignment. If more than one octet
of padding is required, the PadN option should be used rather than
multiple Pad1 options.</t>
<t>NOTE! the format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields.</t>
</section>
<section title="PadN">
<t>The PadN option MAY be present in DIS, DIO, DAO, and DAO-ACK
messages, and its format is as follows:</t>
<t><figure anchor="DIOsubPadN" title="Format of the Pad N Option">
<artwork><![CDATA[
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 1 | Option Length | 0x00 Padding...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
]]></artwork>
</figure></t>
<t>The PadN option is used to insert two or more octets of padding
into the message to enable options alignment. PadN Option data MUST
be ignored by the receiver.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x01 (to be confirmed by IANA)</t>
<t hangText="Option Length:">For N (N > 1) octets of padding,
the Option Length field contains the value N-2.</t>
<t hangText="Option Data:">For N (N > 1) octets of padding,
the Option Data consists of N-2 zero-valued octets.</t>
</list></t>
</section>
<section title="Metric Container">
<t>The Metric Container option MAY be present in DIO or DAO
messages, and its format is as follows:</t>
<t><figure anchor="DIOsubLLNMetric"
title="Format of the Metric Container Option">
<artwork><![CDATA[
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 2 | Option Length | Metric Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
]]></artwork>
</figure></t>
<t>The Metric Container is used to report metrics along the DODAG.
The Metric Container may contain a number of discrete node, link,
and aggregate path metrics and constraints specified in <xref
target="I-D.ietf-roll-routing-metrics"></xref> as chosen by the
implementer.</t>
<t>The Metric Container MAY appear more than once in the same RPL
control message, for example to accommodate a use case where the
Metric Data is longer than 256 bytes. More information is in <xref
target="I-D.ietf-roll-routing-metrics"></xref>.</t>
<t>The processing and propagation of the Metric Container is
governed by implementation specific policy functions.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x02 (to be confirmed by IANA)</t>
<t hangText="Option Length:">The Option Length field contains
the length in octets of the Metric Data.</t>
<t hangText="Metric Data:">The order, content, and coding of the
Metric Container data is as specified in <xref
target="I-D.ietf-roll-routing-metrics"></xref>.</t>
</list></t>
</section>
<section title="Route Information">
<t>The Route Information option MAY be present in DIO messages, and
is equivalent in function to the IPv6 Neighbor Discovery (ND) Route
Information option as defined in <xref target="RFC4191"></xref>. The
format of the option is modified slightly (Type, Length, Prefix) in
order to be carried as a RPL option as follows:</t>
<t><figure anchor="DIOsubRouteInformation"
title="Format of the Route Information Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Prefix (Variable Length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The Route Information option is used to indicate that
connectivity to the specified destination prefix is available from
the DODAG root.</t>
<t>In the event that a RPL Control Message may need to specify
connectivity to more than one destination, the Route Information
option may be repeated.</t>
<t><xref target="RFC4191"></xref> should be consulted as the
authoritative reference with respect to the Route Information
option. The field descriptions are transcribed here for
convenience:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x03 (to be confirmed by IANA)</t>
<t hangText="Option Length:">Variable, length of the option in
octets excluding the Type and Length fields. Note that this
length is expressed in units of single-octets, unlike in IPv6
ND.</t>
<t hangText="Prefix Length">8-bit unsigned integer. The number
of leading bits in the Prefix that are valid. The value ranges
from 0 to 128. The Prefix field has the number of bytes inferred
from the Option Length field, that must be at least the Prefix
Length. Note that in RPL this means that the Prefix field may
have lengths other than 0, 8, or 16.</t>
<t hangText="Prf:">2-bit signed integer. The Route Preference
indicates whether to prefer the router associated with this
prefix over others, when multiple identical prefixes (for
different routers) have been received. If the Reserved (10)
value is received, the Route Information Option MUST be ignored.
As per <xref target="RFC4191"></xref>, the Reserved (10) value
MUST NOT be sent. (<xref target="RFC4191"></xref> restricts the
Preference to just three values to reinforce that it is not a
metric).</t>
<t hangText="Resvd:">Two 3-bit unused fields. They MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="Route Lifetime">32-bit unsigned integer. The length
of time in seconds (relative to the time the packet is sent)
that the prefix is valid for route determination. A value of all
one bits (0xffffffff) represents infinity.</t>
<t hangText="Prefix">Variable-length field containing an IP
address or a prefix of an IPv6 address. The Prefix Length field
contains the number of valid leading bits in the prefix. The
bits in the prefix after the prefix length (if any) are reserved
and MUST be initialized to zero by the sender and ignored by the
receiver. Note that in RPL this field may have lengths other
than 0, 8, or 16.</t>
</list></t>
<t>Unassigned bits of the Route Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.</t>
</section>
<section title="DODAG Configuration">
<t>The DODAG Configuration option MAY be present in DIO messages,
and its format is as follows:</t>
<t><figure anchor="DIOsubDAGConfig"
title="Format of the DODAG Configuration Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIOIntMin. | DIORedun. | MaxRankIncrease |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinHopRankIncrease | OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Def. Lifetime | Lifetime Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The DODAG Configuration option is used to distribute
configuration information for DODAG Operation through the DODAG.</t>
<t>The information communicated in this option is generally static
and unchanging within the DODAG, therefore it is not necessary to
include in every DIO. This information is configured at the DODAG
Root and distributed throughout the DODAG with the DODAG
Configuration Option. Nodes other than the DODAG Root MUST NOT
modify this information when propagating the DODAG Configuration
option. This option MAY be included occasionally by the DODAG Root
(as determined by the DODAG Root), and MUST be included in response
to a unicast request, e.g. a unicast DODAG Information Solicitation
(DIS) message.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x04 (to be confirmed by IANA)</t>
<t hangText="Option Length:">14</t>
<t hangText="Flags:">4-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Authentication Enabled (A):">One bit flag
describing the security mode of the network. The bit describe
whether a node must authenticate with a key authority before
joining the network as a router. If the DIO is not a secure DIO,
the 'A' bit MUST be zero.</t>
<t hangText="Path Control Size (PCS):">3-bit unsigned integer
used to configure the number of bits that may be allocated to
the Path Control field (see <xref target="PathControl"></xref>).
Note that when PCS is consulted to determine the width of the
Path Control field a value of 1 is added, i.e. a PCS value of 0
results in 1 active bit in the Path Control field. The default
value of PCS is DEFAULT_PATH_CONTROL_SIZE.</t>
<t hangText="DIOIntervalDoublings:">8-bit unsigned integer used
to configure Imax of the DIO trickle timer (see <xref
target="TrickleParameters"></xref>). The default value of
DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.</t>
<t hangText="DIOIntervalMin:">8-bit unsigned integer used to
configure Imin of the DIO trickle timer (see <xref
target="TrickleParameters"></xref>). The default value of
DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.</t>
<t hangText="DIORedundancyConstant:">8-bit unsigned integer used
to configure k of the DIO trickle timer (see <xref
target="TrickleParameters"></xref>). The default value of
DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT.</t>
<t hangText="MaxRankIncrease:">16-bit unsigned integer used to
configure DAGMaxRankIncrease, the allowable increase in rank in
support of local repair. If DAGMaxRankIncrease is 0 then this
mechanism is disabled.</t>
<t hangText="MinHopRankInc">16-bit unsigned integer used to
configure MinHopRankIncrease as described in <xref
target="RankComparison"></xref>. The default value of
MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE.</t>
<t hangText="Default Lifetime:">8-bit unsigned integer. This is
the lifetime that is used as default for all RPL routes. It is
expressed in units of Lifetime Units, e.g. the default lifetime
in seconds is (Default Lifetime) * (Lifetime Unit).</t>
<t hangText="Lifetime Unit:">16-bit unsigned integer. Provides
the unit in seconds that is used to express route lifetimes in
RPL. For very stable networks, it can be hours to days.</t>
<t hangText="Objective Code Point (OCP)">16-bit unsigned
integer. The OCP field identifies the OF and is managed by the
IANA.</t>
</list></t>
</section>
<section title="RPL Target">
<t>The RPL Target option MAY be present in DAO messages, and its
format is as follows:</t>
<t><figure anchor="RPLtargetopt"
title="Format of the RPL Target Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Option Length | Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Target Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The RPL Target Option is used to indicate a target IPv6 address,
prefix, or multicast group that is reachable or queried along the
DODAG. In a DAO, the RPL Target option indicates reachability.</t>
<t>A RPL Target Option May optionally be paired with a RPL Target
Descriptor Option (<xref target="RPLtargetdescopt"></xref>) that
qualifies the target.</t>
<t>A set of one or more Transit Information options (<xref
target="TransitInformation"></xref>) MAY directly follow a set of
one or more Target option in a DAO message (where each Target Option
MAY be paired with a RPL Target Descriptor Option as above). The
structure of the DAO message, detailing how Target options are used
in conjunction with Transit Information options, is further
described in <xref target="DAOStructure"></xref>.</t>
<t>The RPL Target option may be repeated as necessary to indicate
multiple targets.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x05 (to be confirmed by IANA)</t>
<t hangText="Option Length:">Variable, length of the option in
octets excluding the Type and Length fields.</t>
<t hangText="Flags:">8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Prefix Length:">8-bit unsigned integer. Number of
valid leading bits in the IPv6 Prefix.</t>
<t hangText="Target Prefix:">Variable-length field identifying
an IPv6 destination address, prefix, or multicast group. The
Prefix Length field contains the number of valid leading bits in
the prefix. The bits in the prefix after the prefix length (if
any) are reserved and MUST be set to zero on transmission and
MUST be ignored on receipt.</t>
</list></t>
</section>
<section anchor="TransitInformation" title="Transit Information">
<t>The Transit Information option MAY be present in DAO messages,
and its format is as follows:</t>
<t><figure anchor="TransitInformationOption"
title="Format of the Transit Information option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Option Length |E| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Parent Address* +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>The '*' denotes that the Parent Address is not always
present, as described below.</postamble>
</figure></t>
<t>The Transit Information option is used for a node to indicate
attributes for a path to one or more destinations. The destinations
are indicated by one or more Target options that immediately precede
the Transit Information option(s).</t>
<t>The Transit Information option can be used for a node to indicate
its DODAG parents to an ancestor that is collecting DODAG routing
information, typically for the purpose of constructing source
routes. In the non-storing mode of operation this ancestor will be
the DODAG Root, and this option is carried by the DAO message. In
the storing mode of operation the Parent Address is not needed,
since the DAO message is sent directly to the parent. The option
length is used to determine whether the Parent Address is present or
not.</t>
<t>A non-storing node that has more than one DAO parent MAY include
a Transit Information option for each DAO parent as part of the
non-storing destination advertisement operation. The node may
distribute the bits in the Path Control field among different groups
of DAO parents in order to signal a preference among parents. That
preference may influence the decision of the DODAG root when
selecting among the alternate parents/paths for constructing
downward routes.</t>
<t>One or more Transit Information options MUST be preceded by one
or more RPL Target options. In this manner the RPL Target option
indicates the child node, and the Transit Information option(s)
enumerate the DODAG parents. The structure of the DAO message,
further detailing how Target options are used in conjunction with
Transit Information options, is further described in <xref
target="DAOStructure"></xref>.</t>
<t>A typical non-storing node will use multiple Transit Information
options, and it will send the DAO message thus formed directly to
the root. A typical storing node will use one Transit Information
option with no parent field, and will send the DAO message thus
formed, with additional adjustments to Path Control as detailed
later, to one or multiple parents.</t>
<t>For example, in a non-storing mode of operation let Tgt(T) denote
a Target option for a target T. Let Trnst(P) denote a Transit
Information option that contains a parent address P. Consider the
case of a non-storing node N that advertises the self-owned targets
N1 and N2 and has parents P1, P2, and P3. In that case the DAO
message would be expected to contain the sequence ( (Tgt(N1),
Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3)) ), such that the group
of Target options {N1, N2} are described by the Transit Information
options as having the parents {P1, P2, P3}. The non-storing node
would then address that DAO message directly to the DODAG root, and
forward that DAO message through one of the DODAG parents P1, P2, or
P3.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x06 (to be confirmed by IANA)</t>
<t hangText="Option Length:">Variable, depending on whether or
not Parent Address is present.</t>
<t hangText="External (E):">1-bit flag. The 'E' flag is set to
indicate that the parent router redistributes external targets
into the RPL network. An external target is a target that has
been learned through an alternate protocol. The external targets
are listed in the target options that immediately precede the
Transit Information option. An external target is not expected
to support RPL messages and options.</t>
<t hangText="Flags:">7-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText="Path Control:">8-bit bitfield. The Path Control
field limits the number of DAO-Parents to which a DAO message
advertising connectivity to a specific destination may be sent,
as well as providing some indication of relative preference. The
limit provides some bound on overall DAO message fan-out in the
LLN. The assignment and ordering of the bits in the path control
also serves to communicate preference. Not all of these bits may
be enabled as according the the PCS in the DODAG Configuration.
The Path Control field is divided into four subfields which
contain two bits each: PC1, PC2, PC3, and PC4, as illustrated in
<xref target="PathControlEncoding"></xref>. The subfields are
ordered by preference, with PC1 being the most preferred and PC4
being the least preferred. Within a subfield there is no order
of preference. By grouping the parents (as in ECMP) and ordering
them, the parents may be associated with specific bits in the
Path Control field in a way that communicates preference.
<figure anchor="PathControlEncoding"
title="Path Control Preference Sub-field Encoding">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t hangText="Path Sequence:">8-bit unsigned integer. When a RPL
Target option is issued by the node that owns the Target Prefix
(i.e. in a DAO message), that node sets the Path Sequence and
increments the Path Sequence each time it issues a RPL Target
option with updated information.</t>
<t hangText="Path Lifetime:">8-bit unsigned integer. The length
of time in Lifetime Units (obtained from the Configuration
option) that the prefix is valid for route determination. The
period starts when a new Path Sequence is seen. A value of all
one bits (0xFF) represents infinity. A value of all zero bits
(0x00) indicates a loss of reachability. A DAO message that
contains a Transit Information option with a Path Lifetime of
0x00 for a Target is referred as a No-Path (for that Target) in
this document.</t>
<t hangText="Parent Address (optional):">IPv6 Address of the
DODAG Parent of the node originally issuing the Transit
Information Option. This field may not be present, as according
to the DODAG Mode of Operation (storing or non-storing) and
indicated by the Transit Information option length.</t>
</list></t>
<t>Unassigned bits of the Transit Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.</t>
</section>
<section title="Solicited Information">
<t>The Solicited Information option MAY be present in DIS messages,
and its format is as follows:</t>
<t><figure anchor="SolicitedInformation"
title="Format of the Solicited Information Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 |Opt Length = 19| RPLInstanceID |V|I|D| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version Number |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The Solicited Information option is used for a node to request
DIO messages from a subset of neighboring nodes. The Solicited
Information option may specify a number of predicate criteria to be
matched by a receiving node. This is used by the requester to limit
the number of replies from "non-interesting" nodes. These predicates
affect whether a node resets its DIO trickle timer, as described in
<xref target="DIOTransmission"></xref>.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x07 (to be confirmed by IANA)</t>
<t hangText="Option Length:">19</t>
<t hangText="Control Field:">The control field contains flags
that indicate which predicates a node should check when deciding
whether to reset its Trickle timer. A node resets its Trickle
timer when all predicates are true. If a flag is set, then the
RPL node MUST check the associated predicate. If a flag is
cleared, then the RPL node MUST NOT check the associated
predicate and assume the predicate is true. The Solicited
Information option Control Field has three flags: <list
hangIndent="6" style="hanging">
<t hangText="V:">The V flag is the Version predicate. The
Version predicate is true if the receiver's
DODAGVersionNumber matches the requested Version Number. If
the V flag is cleared then the Version field is not valid
and the Version field MUST be set to zero on transmission
and ignored upon receipt.</t>
<t hangText="I:">The I flag is the InstanceID predicate. The
InstanceID predicate is true when the RPL node's current
RPLInstanceID matches the requested RPLInstanceID. If the I
flag is cleared then the RPLInstanceID field is not valid
and the RPLInstanceID field MUST be set to zero on
transmission and ignored upon receipt.</t>
<t hangText="D:">The D flag is the DODAGID predicate. The
DODAGID predicate is true if the RPL node's parent set has
the same DODAGID as the DODAGID field. If the D flag is
cleared then the DODAGID field is not valid and the DODAGID
field MUST be set to zero on transmission and ignored upon
receipt.</t>
<t hangText="Flags:">5-bit unused field reserved for flags.
The field MUST be initialized to zero by the sender and MUST
be ignored by the receiver.</t>
<!--
<t hangText="F:">The F flag is the False predicate. The
False predicate is always false. Setting the F flag allows a
node to send a DIS which does not reset Trickle timers.</t>
-->
</list></t>
<t hangText="Version Number:">8-bit unsigned integer containing
the value of DODAGVersionNumber that is being solicited when
valid.</t>
<t hangText="RPLInstanceID:">8-bit unsigned integer containing
the RPLInstanceID that is being solicited when valid.</t>
<t hangText="DODAGID:">128-bit unsigned integer containing the
DODAGID that is being solicited when valid.</t>
</list></t>
<t>Unassigned bits of the Solicited Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.</t>
</section>
<section title="Prefix Information">
<t>The Prefix Information option MAY be present in DIO messages, and
is equivalent in function to the IPv6 ND Prefix Information option
as defined in <xref target="RFC4861"></xref>. The format of the
option is modified slightly (Type, Length, Prefix) in order to be
carried as a RPL option as follows:</t>
<t><figure anchor="DIOsubPrefixInformation"
title="Format of the Prefix Information Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The Prefix Information option may be used to distribute the
prefix in use inside the DODAG, e.g. for address
autoconfiguration.</t>
<t><xref target="RFC4861"></xref> and <xref target="RFC3775"></xref>
should be consulted as the authoritative reference with respect to
the Prefix Information option. The field descriptions are
transcribed here for convenience:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x08 (to be confirmed by IANA)</t>
<t hangText="Option Length:">30. Note that this length is
expressed in units of single-octets, unlike in IPv6 ND.</t>
<t hangText="Prefix Length">8-bit unsigned integer. The number
of leading bits in the Prefix that are valid. The value ranges
from 0 to 128. The prefix length field provides necessary
information for on-link determination (when combined with the L
flag in the prefix information option). It also assists with
address autoconfiguration as specified in <xref
target="RFC4862"></xref>, for which there may be more
restrictions on the prefix length.</t>
<t hangText="L">1-bit on-link flag. When set, indicates that
this prefix can be used for on-link determination. When not set
the advertisement makes no statement about on-link or off-link
properties of the prefix. In other words, if the L flag is not
set a host MUST NOT conclude that an address derived from the
prefix is off-link. That is, it MUST NOT update a previous
indication that the address is on-link.</t>
<t hangText="A">1-bit autonomous address-configuration flag.
When set indicates that this prefix can be used for stateless
address configuration as specified in <xref
target="RFC4862"></xref>.</t>
<t hangText="R">1-bit Router address flag. When set, indicates
that the Prefix field contains a complete IPv6 address assigned
to the sending router that can be used as parent in a target
option. The indicated prefix is the first Prefix Length bits of
the Prefix field. The router IPv6 address has the same scope and
conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits.</t>
<t hangText="Reserved1">5-bit unused field. It MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="Valid Lifetime">32-bit unsigned integer. The length
of time in seconds (relative to the time the packet is sent)
that the prefix is valid for the purpose of on-link
determination. A value of all one bits (0xffffffff) represents
infinity. The Valid Lifetime is also used by <xref
target="RFC4862"></xref>.</t>
<t hangText="Preferred Lifetime">32-bit unsigned integer. The
length of time in seconds (relative to the time the packet is
sent) that addresses generated from the prefix via stateless
address autoconfiguration remain preferred <xref
target="RFC4862"></xref>. A value of all one bits (0xffffffff)
represents infinity. See <xref target="RFC4862"></xref>. Note
that the value of this field MUST NOT exceed the Valid Lifetime
field to avoid preferring addresses that are no longer
valid.</t>
<t hangText="Reserved2">This field is unused. It MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText="Prefix">An IPv6 address or a prefix of an IPv6
address. The Prefix Length field contains the number of valid
leading bits in the prefix. The bits in the prefix after the
prefix length are reserved and MUST be initialized to zero by
the sender and ignored by the receiver. A router SHOULD NOT send
a prefix option for the link-local prefix and a host SHOULD
ignore such a prefix option. A non-storing node SHOULD refrain
from advertising a prefix till it owns an address of that
prefix, and then it SHOULD advertise its full address in this
field, with the 'R' flag set. The children of a node that so
advertises a full address with the 'R' flag set may then use
that address to determine the content of the Parent Address
field of the Transit Information Option.</t>
</list></t>
<t>Unassigned bits of the Prefix Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.</t>
</section>
<section anchor="RPLtargetdescoptsec" title="RPL Target descriptor">
<t>The RPL Target option MAY be immediately followed by one opaque
descriptor that qualifies that specific target.</t>
<t><figure anchor="RPLtargetdescopt"
title="Format of the RPL Target Descriptor Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 |Opt Length = 4 | Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The RPL Target Descriptor Option is used to qualify a target,
something that is sometimes called tagging.</t>
<t>There can be at most one descriptor per target. The descriptor is
set by the node that injects the target in the RPL network. It MUST
be copied but not modified by routers that propagate the target Up
the DODAG in DAO messages.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Option Type:">0x09 (to be confirmed by IANA)</t>
<t hangText="Option Length:">4</t>
<t hangText="Descriptor:">32-bit unsigned integer. Opaque.</t>
</list></t>
</section>
</section>
</section>
<section anchor="SequenceNumbers" title="Sequence Counters">
<t>This section describes the general scheme for bootstrap and operation
of sequence counters in RPL, such as the DODAGVersionNumber in the DIO
message, the DAOSequence in the DAO message, and the Path Sequence in
the Transit Information option.</t>
<section title="Sequence Counter Overview">
<t>This specification utilizes three different sequence numbers to
validate the freshness and the synchronization of protocol
information:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="DODAGVersionNumber: ">This sequence counter is
present in the DIO base to indicate the Version of the DODAG being
formed. The DODAGVersionNumber is monotonically incremented by the
root each time the root decides to form a new Version of the DODAG
in order to revalidate the integrity and allow a global repairs to
occur. The DODAGVersionNumber is propagated unchanged Down the
DODAG as routers join the new DODAG Version. The
DODAGVersionNumber is globally significant in a DODAG and
indicates the Version of the DODAG that a router is operating in.
An older (lesser) value indicates that the originating router has
not migrated to the new DODAG Version and can not be used as a
parent once the receiving node has migrated to the newer DODAG
Version.</t>
<t hangText="DAOSequence: ">This sequence counter is present in
the DAO base to correlate a DAO message and a DAO ACK message. The
DAOSequence number is locally significant to the node that issues
a DAO message for its own consumption to detect the loss of a DAO
message and enable retries.</t>
<t hangText="Path Sequence: ">This sequence counter is present in
the Transit Information option in a DAO message. The purpose of
this counter is to differentiate a movement where a newer route
supersedes a stale one from a route redundancy scenario where
multiple routes exist in parallel for a same target. The Path
Sequence is globally significant in a DODAG and indicates the
freshness of the route to the associated target. An older (lesser)
value received from an originating router indicates that the
originating router holds stale routing states and the originating
router should not be considered anymore as a potential next-hop
for the target. The Path Sequence is computed by the node that
advertises the target, that is the target itself or a router that
advertises a target on behalf of a host, and is unchanged as the
DAO content is propagated towards the root by parent routers. If a
host does not pass a counter to its router, then the router is in
charge of computing the Path Sequence on behalf of the host and
the host can only register to one router for that purpose. If a
DAO message containing a same target is issued to multiple parents
at a given point of time for the purpose of route redundancy, then
the Path Sequence is the same in all the DAO messages for that
same target.</t>
</list></t>
</section>
<section title="Sequence Counter Operation">
<t>RPL sequence counters are subdivided in a 'lollipop' fashion (<xref
target="Perlman83"></xref>), where the values from 128 and greater are
used as a linear sequence to indicate a restart and bootstrap the
counter, and the values less than or equal to 127 used as a circular
sequence number space of size 128 as in <xref
target="RFC1982"></xref>. Consideration is given to the mode of
operation when transitioning from the linear region to the circular
region. Finally, when operating in the circular region, if sequence
numbers are detected to be too far apart then they are not comparable,
as detailed below.</t>
<t>A window of comparison, SEQUENCE_WINDOW = 16, is configured based
on a value of 2^N, where N is defined to be 4 in this
specification.</t>
<t>For a given sequence counter, <list style="numbers">
<t>The sequence counter SHOULD be initialized to an implementation
defined value which is 128 or greater prior to use. A recommended
value is 240 (256 - SEQUENCE_WINDOW).</t>
<t>When a sequence counter increment would cause the sequence
counter to increment beyond its maximum value, the sequence
counter MUST wrap back to zero. When incrementing a sequence
counter greater than or equal to 128, the maximum value is 255.
When incrementing a sequence counter less than 128, the maximum
value is 127.</t>
<t>When comparing two sequence counters, the following rules MUST
be applied: <list style="numbers">
<t>When a first sequence counter A is in the interval [0..127]
and a second sequence counter B is in [128..255]: <list
style="numbers">
<t>If B-A is less than or equal to SEQUENCE_WINDOW, then B
is greater than A, A is less than B, and the two are not
equal.</t>
<t>If B-A is greater than SEQUENCE_WINDOW, then A is
greater than B, B is less than A, and the two are not
equal.</t>
</list></t>
<t>In the case where both sequence counters to be compared are
less than or equal to 127, and in the case where both sequence
counters to be compared are greater than or equal to 128:<list
style="numbers">
<t>If the absolute magnitude of difference between the two
sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in <xref
target="RFC1982"></xref> is used to determine the
relationships greater than, less than, and equal.</t>
<t>If the absolute magnitude of difference of the two
sequence counters is greater than SEQUENCE_WINDOW, then a
desynchronization has occurred and the two sequence
numbers are not comparable.</t>
</list></t>
</list></t>
<t>If two sequence numbers are determined to be not comparable,
i.e. the results of the comparison are not defined, then a node
should consider the comparison as if it has evaluated in such a
way so as to give precedence to the sequence number that has most
recently been observed to increment. Failing this, the node should
consider the comparison as if it has evaluated in such a way so as
to minimize the resulting changes to its own state.</t>
</list></t>
</section>
</section>
<section anchor="UpwardRoutes" title="Upward Routes">
<t>This section describes how RPL discovers and maintains upward routes.
It describes the use of DODAG Information Objects (DIOs), the messages
used to discover and maintain these routes. It specifies how RPL
generates and responds to DIOs. It also describes DODAG Information
Solicitation (DIS) messages, which are used to trigger DIO
transmissions.</t>
<section anchor="DIOBaseRules" title="DIO Base Rules">
<t><list style="numbers">
<t>For the following DIO Base fields, a node that is not a DODAG
root MUST advertise the same values as its preferred DODAG parent
(defined in <xref target="parentset"></xref>). In this way these
values will propagate Down the DODAG unchanged and advertised by
every node that has a route to that DODAG root. These fields are:
<?rfc subcompact="yes"?><list>
<t>Grounded (G)</t>
<t>Mode of Operation (MOP)</t>
<t>DAGPreference (Prf)</t>
<t>Version</t>
<t>RPLInstanceID</t>
<t>DODAGID</t>
</list><?rfc subcompact="no"?></t>
<t>A node MAY update the following fields at each hop: <?rfc subcompact="yes"?><list>
<t>Rank</t>
<t>DTSN</t>
</list><?rfc subcompact="no"?></t>
<t>The DODAGID field each root sets MUST be unique within the RPL
Instance and MUST be a routable IPv6 address belonging to the
root.</t>
</list></t>
</section>
<section anchor="DAGDiscovery"
title="Upward Route Discovery and Maintenance">
<t>Upward route discovery allows a node to join a DODAG by discovering
neighbors that are members of the DODAG of interest and identifying a
set of parents. The exact policies for selecting neighbors and parents
is implementation-dependent and driven by the OF. This section
specifies the set of rules those policies must follow for
interoperability.</t>
<section anchor="parentset"
title="Neighbors and Parents within a DODAG Version">
<t>RPL's upward route discovery algorithms and processing are in
terms of three logical sets of link-local nodes. First, the
candidate neighbor set is a subset of the nodes that can be reached
via link-local multicast. The selection of this set is
implementation-dependent and OF-dependent. Second, the parent set is
a restricted subset of the candidate neighbor set. Finally, the
preferred parent is a member of the parent set that is the preferred
next hop in upward routes. The preferred parent is conceptually a
single parent although it may be a set of multiple parents if those
parents are equally preferred and have identical rank.</t>
<t>More precisely: <list style="numbers">
<t>The DODAG parent set MUST be a subset of the candidate
neighbor set.</t>
<t>A DODAG root MUST have a DODAG parent set of size zero.</t>
<t>A node that is not a DODAG root MAY maintain a DODAG parent
set of size greater than or equal to one.</t>
<t>A node's preferred DODAG parent MUST be a member of its DODAG
parent set.</t>
<t>A node's rank MUST be greater than all elements of its DODAG
parent set.</t>
<t>When Neighbor Unreachability Detection (NUD) <xref
target="RFC4861"></xref>, or an equivalent mechanism, determines
that a neighbor is no longer reachable, a RPL node MUST NOT
consider this node in the candidate neighbor set when
calculating and advertising routes until it determines that it
is again reachable. Routes through an unreachable neighbor MUST
be removed from the routing table.</t>
</list></t>
<t>These rules ensure that there is a consistent partial order on
nodes within the DODAG. As long as node ranks do not change,
following the above rules ensures that every node's route to a DODAG
root is loop-free, as rank decreases on each hop to the root.</t>
<!-- CUT? -->
<t>The OF can guide candidate neighbor set and parent set selection,
as discussed in <xref target="I-D.ietf-roll-of0"></xref>.</t>
</section>
<section anchor="DAGDiscoveryRules"
title="Neighbors and Parents across DODAG Versions">
<t>The above rules govern a single DODAG Version. The rules in this
section define how RPL operates when there are multiple DODAG
Versions:</t>
<section anchor="DAGDiscoveryRulesSeq" title="DODAG Version">
<t><list style="numbers">
<t>The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber)
uniquely defines a DODAG Version. Every element of a node's
DODAG parent set, as conveyed by the last heard DIO message
from each DODAG parent, MUST belong to the same DODAG Version.
Elements of a node's candidate neighbor set MAY belong to
different DODAG Versions.</t>
<t>A node is a member of a DODAG Version if every element of
its DODAG parent set belongs to that DODAG Version, or if that
node is the root of the corresponding DODAG.</t>
<t>A node MUST NOT send DIOs for DODAG Versions of which it is
not a member.</t>
<t>DODAG roots MAY increment the DODAGVersionNumber that they
advertise and thus move to a new DODAG Version. When a DODAG
root increments its DODAGVersionNumber, it MUST follow the
conventions of Serial Number Arithmetic as described in <xref
target="SequenceNumbers"></xref>. Events triggering the
increment of the DODAGVersionNumber are described later in
this section and in <xref target="Manageability"></xref>.</t>
<t>Within a given DODAG, a node that is a not a root MUST NOT
advertise a DODAGVersionNumber higher than the highest
DODAGVersionNumber it has heard. Higher is defined as the
greater-than operator in <xref
target="SequenceNumbers"></xref>.</t>
<t>Once a node has advertised a DODAG Version by sending a
DIO, it MUST NOT be a member of a previous DODAG Version of
the same DODAG (i.e. with the same RPLInstanceID, the same
DODAGID, and a lower DODAGVersionNumber). Lower is defined as
the less-than operator in <xref
target="SequenceNumbers"></xref>.</t>
</list></t>
<!-- CUT?
<t>Within a particular implementation, a DODAG root may increment
the DODAGVersionNumber periodically, at a rate that depends on the
deployment, in order to trigger a global reoptimization of the
DODAG. In other implementations, loop detection may be considered
sufficient to solve routing issues by triggering local repair
mechanisms, and the DODAG root may increment the
DODAGVersionNumber only upon administrative intervention. Another
possibility is that nodes within the LLN have some means by which
they can signal detected routing inconsistencies or
suboptimalities to the DODAG root, in order to request an
on-demand DODAGVersionNumber increment (i.e. request a global
repair of the DODAG). Note that such a mechanism is for further
study and out of the scope of this document.</t>
-->
<!-- CUT? -->
<t>When the DODAG parent set becomes empty on a node that is not a
root, (i.e. the last parent has been removed, causing the node to
no longer be associated with that DODAG), then the DODAG
information should not be suppressed until after the expiration of
an implementation-specific local timer in order to observe if the
DODAGVersionNumber has been incremented, should any new parents
appear for the DODAG. This will help protect against the
possibility of loops that may occur if that node were to
inadvertently rejoin the old DODAG Version in its own prior
sub-DODAG.</t>
<t>As the DODAGVersionNumber is incremented, a new DODAG Version
spreads outward from the DODAG root. A parent that advertises the
new DODAGVersionNumber cannot belong to the sub-DODAG of a node
advertising an older DODAGVersionNumber. Therefore a node can
safely add a parent of any Rank with a newer DODAGVersionNumber
without forming a loop.</t>
<t>For example, suppose that a node has left a DODAG with
DODAGVersionNumber N. Suppose that node had a sub-DODAG, and did
attempt to poison that sub-DODAG by advertising a rank of
INFINITE_RANK, but those advertisements may have become lost in
the LLN. Then, if the node did observe a candidate neighbor
advertising a position in that original DODAG at
DODAGVersionNumber N, that candidate neighbor could possibly have
been in the node's former sub-DODAG and there is a possible case
where to add that candidate neighbor as a parent could cause a
loop. If that candidate neighbor in this case is observed to
advertise a DODAGVersionNumber N+1, then that candidate neighbor
is certain to be safe, since it is certain not to be in that
original node's sub-DODAG as it has been able to increment the
DODAGVersionNumber by hearing from the DODAG root while that
original node was detached. It is for this reason that it is
useful for the detached node to remember the original DODAG
information, including the DODAGVersionNumber N.</t>
<t>Exactly when a DODAG Root increments the DODAGVersionNumber is
implementation and application-dependent and outside the scope of
this document. Examples include incrementing the
DODAGVersionNumber periodically, upon administrative intervention,
or on application-level detection of lost connectivity or DODAG
inefficiency.</t>
<t>After a node transitions to and advertises a new DODAG Version,
the rules above make it unable to advertise the previous DODAG
Version (prior DODAGVersionNumber) once it has committed to
advertising the new DODAG Version.</t>
<!-- Already addressed by LoopDetectInconsistency:
<t>During transition to a new DODAG Version, a node may decide to
forward packets via 'future parents' that belong to the same DODAG
(same RPLInstanceID and DODAGID), but are observed to advertise a
more recent (incremented) DODAGVersionNumber. In that case, the
node MUST act as a leaf with regard to the new version for the
purpose of loop detection as specified in <xref
target="loopdetect"></xref>.</t>
-->
</section>
<section anchor="DAGDiscoveryRulesRoot" title="DODAG Roots">
<t><list style="numbers">
<t>A DODAG root without possibility to satisfy the
application- defined goal MUST NOT set the Grounded bit.</t>
<t>A DODAG root MUST advertise a rank of ROOT_RANK.</t>
<t>A node whose DODAG parent set is empty MAY become the DODAG
Root of a floating DODAG. It MAY also set its DAGPreference
such that it is less preferred.</t>
</list></t>
<t>In a deployment that uses non-RPL links to federate a number of
LLN roots, it is possible to run RPL over those non-RPL links and
use one router as a "backbone root". The backbone root is the
virtual root of the DODAG, and exposes a rank of BASE_RANK over
the backbone. All the LLN roots that are parented to that backbone
root, including the backbone root if it also serves as LLN root
itself, expose a rank of ROOT_RANK to the LLN. These virtual roots
are part of the same DODAG and advertise the same DODAGID. They
coordinate DODAGVersionNumbers and other DODAG parameters with the
virtual root over the backbone. The method of coordination is
outside the scope of this specification.</t>
</section>
<section anchor="DAGSelection" title="DODAG Selection">
<t>The objective function and the set of advertised routing
metrics and constraints of a DAG determines how a node selects its
neighbor set, parent set, and preferred parents. This selection
implicitly also determines the DODAG within a DAG. Such selection
can include administrative preference (Prf) as well as metrics or
other considerations.</t>
<t>If a node has the option to join a more preferred DODAG while
still meeting other optimization objectives, then the node will
generally seek to join the more preferred DODAG as determined by
the OF. All else being equal, it is left to the implementation to
determine which DODAG is most preferred (since, as a reminder, a
node must only join one DODAG per RPL Instance).</t>
</section>
<section anchor="DAGDiscoveryRulesMove"
title="Rank and Movement within a DODAG Version">
<t><list style="numbers">
<t>A node MUST NOT advertise a Rank less than or equal to any
member of its parent set within the DODAG Version.</t>
<t>A node MAY advertise a Rank lower than its prior
advertisement within the DODAG Version.</t>
<t>Let L be the lowest rank within a DODAG Version that a
given node has advertised. Within the same DODAG Version, that
node MUST NOT advertise an effective rank higher than L +
DAGMaxRankIncrease. INFINITE_RANK is an exception to this
rule: a node MAY advertise an INFINITE_RANK within a DODAG
version without restriction. If a node's Rank were to be higher
than allowed by L + DAGMaxRankIncrease, when it advertises
Rank it MUST advertise its Rank as INFINITE_RANK.</t>
<t>A node MAY, at any time, choose to join a different DODAG
within a RPL Instance. Such a join has no rank restrictions,
unless that different DODAG is a DODAG Version of which this
node has previously been a member, in which case the rule of
the previous bullet (3) must be observed. Until a node
transmits a DIO indicating its new DODAG membership, it MUST
forward packets along the previous DODAG.</t>
<t>A node MAY, at any time after hearing the next
DODAGVersionNumber advertised from suitable DODAG parents,
choose to migrate to the next DODAG Version within the
DODAG.</t>
</list></t>
<t>Conceptually, an implementation is maintaining a DODAG parent
set within the DODAG Version. Movement entails changes to the
DODAG parent set. Moving Up does not present the risk to create a
loop but moving Down might, so that operation is subject to
additional constraints.</t>
<t>When a node migrates to the next DODAG Version, the DODAG
parent set needs to be rebuilt for the new Version. An
implementation could defer to migrate for some reasonable amount
of time, to see if some other neighbors with potentially better
metrics but higher rank announce themselves. Similarly, when a
node jumps into a new DODAG it needs to construct a new DODAG
parent set for this new DODAG.</t>
<t>If a node needs to move Down a DODAG that it is attached to,
increasing its Rank, then it MAY poison its routes and delay
before moving as described in <xref
target="DAGDiscoveryRulesPoison"></xref>.</t>
<t>A node is allowed to join any DODAG Version that it has never
been a prior member of without any restrictions, but if the node
has been a prior member of the DODAG Version then it must continue
to observe the rule that it may not advertise an effective rank
higher than L+DAGMaxRankIncrease at any point in the life of the
DODAG Version. This rule must be observed so as not to create a
loophole that would allow the node to effectively increment its
rank all the way to INFINITE_RANK, which may have impact on other
nodes and create a resource-wasting count-to-infinity
scenario.</t>
</section>
<section anchor="DAGDiscoveryRulesPoison" title="Poisoning">
<t><list style="numbers">
<t>A node poisons routes by advertising a Rank of
INFINITE_RANK.</t>
<t>A node MUST NOT have any nodes with a Rank of INFINITE_RANK
in its parent set.</t>
</list></t>
<t>Although an implementation may advertise INFINITE_RANK for the
purposes of poisoning, doing so is not the same as setting Rank to
INFINITE_RANK. For example, a node may continue to send data
packets whose RPL option (<xref
target="I-D.ietf-6man-rpl-option"></xref>) includes a Rank that is
not INFINITE_RANK, yet still advertise INFINITE_RANK in its
DIOs.</t>
<t>When a (former) parent is observed to advertise a Rank of
INFINITE_RANK, that (former) parent has detached from the DODAG
and is no longer able to act as a parent, nor is there any why
that another node may be considered to have a Rank greater-than
INFINITE_RANK. Therefore that (former) parent cannot act as a
parent any longer and is removed from the parent set.</t>
</section>
<section anchor="DAGDiscoveryRulesdetach" title="Detaching">
<t><list style="numbers">
<t>A node unable to stay connected to a DODAG within a given
DODAG Version, i.e. that cannot retain non-empty parent set
without violating the rules of this specification, MAY detach
from this DODAG Version. A node that detaches becomes root of
its own floating DODAG and SHOULD immediately advertise this
new situation in a DIO as an alternate to poisoning.</t>
</list></t>
</section>
<section anchor="DAGDiscoveryRulesfollow" title="Following a Parent">
<t><list style="numbers">
<t>If a node receives a DIO from one of its DODAG parents,
indicating that the parent has left the DODAG, that node
SHOULD stay in its current DODAG through an alternative DODAG
parent, if possible. It MAY follow the leaving parent.</t>
</list></t>
<t>A DODAG parent may have moved, migrated to the next DODAG
Version, or jumped to a different DODAG. A node ought to give some
preference to remaining in the current DODAG, if possible via an
alternate parent, but ought to follow the parent if there are no
other options.</t>
</section>
</section>
<section title="DIO Message Communication">
<t>When an DIO message is received, the receiving node must first
determine whether or not the DIO message should be accepted for
further processing, and subsequently present the DIO message for
further processing if eligible.</t>
<t><list style="numbers">
<t>If the DIO message is malformed, then the DIO message is not
eligible for further processing and a node MUST silently discard
it. (See <xref target="Manageability"></xref> for error
logging).</t>
<t>If the sender of the DIO message is a member of the candidate
neighbor set and the DIO message is not malformed, the node MUST
process the DIO.</t>
</list></t>
<section title="DIO Message Processing">
<t>As DIO messages are received from candidate neighbors, the
neighbors may be promoted to DODAG parents by following the rules
of DODAG discovery as described in <xref
target="DAGDiscovery"></xref>. When a node places a neighbor into
the DODAG parent set, the node becomes attached to the DODAG
through the new DODAG parent node.</t>
<t>The most preferred parent should be used to restrict which
other nodes may become DODAG parents. Some nodes in the DODAG
parent set may be of a rank less than or equal to the most
preferred DODAG parent. (This case may occur, for example, if an
energy constrained device is at a lesser rank but should be
avoided as per an optimization objective, resulting in a more
preferred parent at a greater rank).</t>
</section>
</section>
</section>
<section anchor="DIOTransmission" title="DIO Transmission">
<t>RPL nodes transmit DIOs using a Trickle timer (<xref
target="I-D.ietf-roll-trickle"></xref>). A DIO from a sender with a
lesser DAGRank that causes no changes to the recipient's parent set,
preferred parent, or Rank SHOULD be considered consistent with respect
to the Trickle timer.</t>
<t>The following packets and events MUST be considered inconsistencies
with respect to the Trickle timer, and cause the Trickle timer to
reset:</t>
<t><list style="symbols">
<t>When a node detects an inconsistency when forwarding a packet,
as detailed in <xref target="loopdetect"></xref>.</t>
<t>When a node receives a multicast DIS message without a
Solicited Information option, unless a DIS flag restricts this
behavior.</t>
<t>When a node receives a multicast DIS with a Solicited
Information option and the node matches all of the predicates in
the Solicited Information option, unless a DIS flag restricts this
behavior.</t>
<t>When a node joins a new DODAG Version (e.g. by updating its
DODAGVersionNumber, joining a new RPL Instance, etc.).</t>
</list></t>
<t>Note that this list is not exhaustive, and an implementation MAY
consider other messages or events to be inconsistencies.</t>
<t>A node SHOULD NOT reset its DIO trickle timer in response to
unicast DIS messages. When a node receives a unicast DIS without a
Solicited Information option, it MUST unicast a DIO to the sender in
response. This DIO MUST include a DODAG Configuration option. When a
node receives a unicast DIS message with a Solicited Information
option and matches the predicates of that Solicited Information
option, it MUST unicast a DIO to the sender in response. This unicast
DIO MUST include a DODAG Configuration Option. Thus a node MAY
transmit a unicast DIS message to a potential DODAG parent in order to
probe for DODAG Configuration and other parameters.</t>
<section anchor="TrickleParameters" title="Trickle Parameters">
<t>The configuration parameters of the trickle timer are specified
as follows:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Imin:">learned from the DIO message as
(2^DIOIntervalMin)ms. The default value of DIOIntervalMin is
DEFAULT_DIO_INTERVAL_MIN.</t>
<t hangText="Imax:">learned from the DIO message as
DIOIntervalDoublings. The default value of DIOIntervalDoublings
is DEFAULT_DIO_INTERVAL_DOUBLINGS.</t>
<t hangText="k:">learned from the DIO message as
DIORedundancyConstant. The default value of
DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. In
RPL, when k has the value of 0x00 this is to be treated as a
redundancy constant of infinity in RPL, i.e. Trickle never
suppresses messages.</t>
</list></t>
</section>
</section>
<section title="DODAG Selection">
<t>The DODAG selection is implementation and OF dependent. In order to
limit erratic movements, and all metrics being equal, nodes SHOULD
keep their previous selection. Also, nodes SHOULD provide a means to
filter out a parent whose availability is detected as fluctuating, at
least when more stable choices are available.</t>
<t>When connection to a grounded DODAG is not possible or preferable
for security or other reasons, scattered DODAGs MAY aggregate as much
as possible into larger DODAGs in order to allow connectivity within
the LLN.</t>
<t>A node SHOULD verify that bidirectional connectivity and adequate
link quality is available with a candidate neighbor before it
considers that candidate as a DODAG parent.</t>
</section>
<section anchor="OperationAsALeaf" title="Operation as a Leaf Node">
<t>In some cases a RPL node may attach to a DODAG as a leaf node only.
One example of such a case is when a node does not understand or does
not support (policy) the RPL Instance's OF or advertised
metric/constraint. As specified in <xref target="mgmtPolicy"></xref>
related to policy function, the node may either join the DODAG as a
leaf node or may not join the DODAG. As mentioned in <xref
target="mgmtFault"></xref>, it is then recommended to log a fault.</t>
<t>A leaf node does not extend DODAG connectivity but in some cases
the leaf node may still need to transmit DIOs on occasion, in
particular when the leaf node may not have always been acting as a
leaf node and an inconsistency is detected.</t>
<t>A node operating as a leaf node must obey the following rules:</t>
<t><list style="numbers">
<t>It MUST NOT transmit DIOs containing the DAG Metric
Container.</t>
<t>Its DIOs MUST advertise a DAGRank of INFINITE_RANK.</t>
<t>It MAY suppress DIO transmission, unless the DIO transmission
has been triggered due to
detection of inconsistency when a packet is being forwarded or in
response to a unicast DIS message, in which case
the DIO transmission MUST NOT be suppressed.</t>
<t>It MAY transmit unicast DAOs as described in <xref
target="DownwardDiscovery"></xref>.</t>
<t>It MAY transmit multicast DAOs to the '1 hop' neighborhood as
described in <xref target="MulticastDAO"></xref>.</t>
</list></t>
<t>A particular case that requires a leaf node to send a DIO is if
that leaf node was a prior member of another DODAG and another node
forwards a message assuming the old topology, triggering an
inconsistency. The leaf node needs to transmit a DIO in order to
repair the inconsistency. Note that due to the lossy nature of LLNs,
even though the leaf node may have optimistically poisoned its routes
by advertising a rank of INFINITE_RANK in the old DODAG prior to
becoming a leaf node, that advertisement may have become lost and a
leaf node must be capable to send a DIO later in order to repair the
inconsistency.</t>
<t>In the general case, the leaf node MUST NOT advertise itself as a
router (i.e. send DIOs).</t>
</section>
<section title="Administrative Rank">
<!-- TBD should this go with `Guidelines for OF?' -->
<t>In some cases it might be beneficial to adjust the rank advertised
by a node beyond that computed by the OF based on some implementation
specific policy and properties of the node. For example, a node that
has limited battery should be a leaf unless there is no other choice,
and may then augment the rank computation specified by the OF in order
to expose an exaggerated rank.</t>
</section>
</section>
<section anchor="DownwardRoutes" title="Downward Routes">
<t>This section describes how RPL discovers and maintains downward
routes. RPL constructs and maintains downward routes with Destination
Advertisement Object (DAO) messages. Downward routes support P2MP flows,
from the DODAG roots toward the leaves. Downward routes also support P2P
flows: P2P messages can flow toward a DODAG Root (or a common ancestor)
through an upward route, then away from the DODAG Root to a destination
through a downward route.</t>
<t>This specification describes the two modes a RPL Instance may choose
from for maintaining downward routes. In the first mode, called
"storing", nodes store downward routing tables for their sub-DODAG. Each
hop on a downward route in a storing network examines its routing table
to decide on the next hop. In the second mode, called "non-storing",
nodes do not store downward routing tables. Downward packets are routed
with source routes populated by a DODAG Root <xref
target="I-D.ietf-6man-rpl-routing-header"></xref>.</t>
<t>RPL allows a simple one-hop P2P optimization for both storing and
non-storing networks. A node may send a P2P packet destined to a one-hop
neighbor directly to that node.</t>
<section title="Destination Advertisement Parents">
<t>To establish downward routes, RPL nodes send DAO messages upwards.
The next hop destinations of these DAO messages are called DAO
parents. The collection of a node's DAO parents is called the DAO
parent set.</t>
<t><list style="numbers">
<t>A node's DAO parent set MUST be a subset of its DODAG parent
set.</t>
<t>In storing mode operation, a node MUST NOT address unicast DAO
messages to nodes that are not DAO parents.</t>
<t>In non-storing mode operation, a node MUST NOT address unicast
DAO messages to nodes that are not DODAG roots.</t>
<t>A node MUST NOT forward unicast DAO messages to nodes that are
not DAO parents.</t>
<t>A node MAY send DAO messages using the all-RPL-nodes multicast
address, which is an optimization to provision on-hop routing. The
'K' bit MUST be cleared on transmission of the multicast DAO.</t>
<t>The IPv6 Source Address of a DAO message MUST be the link local
address of the sending node.</t>
</list></t>
<t>The selection of DAO parents is implementation and objective
function specific.</t>
</section>
<section anchor="DownwardDiscovery"
title="Downward Route Discovery and Maintenance">
<t>Destination Advertisement may be configured to be entirely
disabled, or operate in either a storing or non-storing mode, as
reported in the MOP in the DIO message.</t>
<t><list style="numbers">
<t>All nodes who join a DODAG MUST abide by the MOP setting from
the root. Nodes that do not have the capability to fully
participate as a router, e.g. that does not match the advertised
MOP, MAY join the DODAG as a leaf.</t>
<t>If the MOP is 000, indicating no downward routing, nodes MUST
NOT transmit DAO messages, and MAY ignore DAO messages.</t>
<t>In non-storing mode, the DODAG Root SHOULD store source routing
table entries for destinations learned from DAOs.</t>
<t>In storing mode, all non-root, non-leaf nodes MUST store
routing table entries for destinations learned from DAOs.</t>
</list></t>
<t>A DODAG can have one of several possible modes of operation, as
defined by the MOP field. Either it does not support downward routes,
it supports downward routes through source routing from DODAG Roots,
or it supports downward routes through in-network routing tables. When
downward routes are supported through in-network routing tables, the
multicast operation defined in this specification may or may not be
supported, also as indicated by the MOP field. As of this
specification RPL does not support mixed-mode operation, where some
nodes source route and other store routing tables: future extensions
to RPL may support this mode of operation.</t>
<section title="Maintenance of Path Sequence">
<t>For each Target that is associated with (owned by) a node, that
node is responsible to emit DAO messages in order to provision the
downward routes. The Target+Transit information contained in those
DAO messages subsequently propagates Up the DODAG. The Path Sequence
counter in the Transit information option is used to indicate
freshness and update stale downward routing information as described
in <xref target="SequenceNumbers"></xref>.</t>
<t>For a Target that is associated with (owned by) a node, that node
MUST increment the Path Sequence counter, and generate a new DAO
message, when:<list style="numbers">
<t>The Path Lifetime is to be updated (e.g. a refresh or a
no-Path)</t>
<t>The Parent Address list is to be changed</t>
</list></t>
<t>For a Target that is associated with (owned by) a node, that node
MAY increment the Path Sequence counter, and generate a new DAO
message, on occasion in order to refresh the downward routing
information. In storing mode, the node generates such DAO to each of
its DAO parents in order to enable multipath. All DAOs generated at
the same time for a same target MUST be sent with the same path
sequence in the transit information.</t>
</section>
<section title="Generation of DAO Messages">
<t>A node might send DAO messages when it receives DAO messages, as
a result of changes in its DAO parent set, or in response to another
event such as the expiry of a related prefix lifetime. In the case
of receiving DAOs, it matters whether the DAO message is "new," or
contains new information. In non-storing mode, every DAO message a
node receives is "new." In storing mode, a DAO message is "new" if
it satisfies any of these criteria for a contained Target: <list
style="numbers">
<t>it has a newer Path Sequence number,</t>
<t>it has additional Path Control bits, or</t>
<t>is a No-Path DAO message that removes the last downward route
to a prefix.</t>
</list></t>
<t>A node that receives a DAO message from its sub-DODAG MAY
suppress scheduling a DAO message transmission if that DAO message
is not new.</t>
</section>
</section>
<section anchor="DAOBaseRules" title="DAO Base Rules">
<t><list style="numbers">
<!--
<t>Each time a node generates a new DAO, i.e. a DAO that includes
new information such as new Path Sequence numbers, the DAOSequence
field MUST increment by at least one since the last generated
DAO.</t>
-->
<t>If a node sends a DAO message with newer or different
information than the prior DAO message transmission, it MUST
increment the DAOSequence field by at least one. A DAO message
transmission that is identical to the prior DAO message
transmission MAY increment the DAOSequence field.</t>
<t>The RPLInstanceID and DODAGID fields of a DAO message MUST be
the same value as the members of the node's parent set and the
DIOs it transmits.</t>
<t>A node MAY set the 'K' flag in a unicast DAO message to solicit
a unicast DAO-ACK in response in order to confirm the attempt.</t>
<t>A node receiving a unicast DAO message with the 'K' flag set
SHOULD respond with a DAO-ACK. A node receiving a DAO message
without the 'K' flag set MAY respond with a DAO-ACK, especially to
report an error condition.</t>
<t>A node that sets the 'K' flag in a unicast DAO message but does
not receive a DAO-ACK in response MAY reschedule the DAO message
transmission for another attempt, up until an
implementation-specific number of retries.</t>
<t>Nodes SHOULD ignore DAOs without newer sequence numbers and
MUST NOT process them further.</t>
</list></t>
<t>Unlike the Version field of a DIO, which is incremented only by a
DODAG Root and repeated unchanged by other nodes, DAOSequence values
are unique to each node. The sequence number space for unicast and
multicast DAO messages can be either the same or distinct. It is
RECOMMENDED to use the same sequence number space.</t>
</section>
<section anchor="ScheduleDAO" title="DAO Transmission Scheduling">
<t>Because DAOs flow upwards, receiving a unicast DAO can trigger
sending a unicast DAO to a DAO parent.</t>
<t><list style="numbers">
<t>On receiving a unicast DAO message with updated information,
such as containing a Transit Information option with a new Path
Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO
message immediately. It SHOULD delay sending the DAO message in
order to aggregate DAO information from other nodes for which it
is a DAO parent.</t>
<t>A node SHOULD delay sending a DAO message with a timer
(DelayDAO). Receiving a DAO message starts the DelayDAO timer. DAO
messages received while the DelayDAO timer is active do not reset
the timer. When the DelayDAO timer expires, the node sends a
DAO.</t>
<t>When a node adds a node to its DAO parent set, it SHOULD
schedule a DAO message transmission.</t>
</list></t>
<t>DelayDAO's value and calculation is implementation-dependent.</t>
</section>
<section title="Triggering DAO Messages">
<t>Nodes can trigger their sub-DODAG to send DAO messages. Each node
maintains a DAO Trigger Sequence Number (DTSN), which it communicates
through DIO messages.</t>
<t><list style="numbers">
<t>If a node hears one of its DAO parents increment its DTSN, the
node MUST schedule a DAO message transmission using rules in <xref
target="DAOBaseRules"></xref> and <xref
target="ScheduleDAO"></xref>.</t>
<t>In non-storing mode, if a node hears one of its DAO parents
increment its DTSN, the node MUST increment its own DTSN.</t>
<!--
<t>If a node hears one of its parents send a DIO with the 'T' bit
set and a newly incremented DTSN, the node MUST increment its own
DTSN, MUST set the 'T' bit in its own DIOs, and MUST schedule a
DAO transmission using rules in <xref
target="DAOBaseRules"></xref> and <xref
target="ScheduleDAO"></xref>.</t>
-->
</list></t>
<t>In a storing mode of operation, as part of routine routing table
updates and maintenance, a storing node MAY increment DTSN in order to
reliably trigger a set of DAO updates from its immediate children. In
a storing mode of operation it is not necessary to trigger DAO updates
from the entire sub-DODAG, since that state information will propagate
hop-by-hop Up the DODAG.</t>
<t>In a non-storing mode of operation, a DTSN increment will also
cause the immediate children of a node to increment their DTSN in
turn, triggering a set of DAO updates from the entire sub-DODAG. In a
non-storing mode of operation typically only the root would
independently increment the DTSN when a DAO refresh is needed but a
global repair (such as by incrementing DODAGVersionNumber) is not
desired. In a non-storing mode of operation typically all non-root
nodes would increment their DTSN only when their parent(s) are
observed to do so.</t>
<t>In the general, a node may trigger DAO updates according to
implementation specific logic, such as based on the detection of a
downward route inconsistency or occasionally based upon an internal
timer.</t>
<t>In the case of triggered DAOs, selecting a proper DAODelay can
greatly reduce the number of DAOs transmitted. The trigger flows Down
the DODAG; in the best case the DAOs flow Up the DODAG such that
leaves send DAOs first, with each node sending a DAO message only
once. Such a scheduling could be approximated by setting DAODelay
inversely proportional to Rank. Note that this suggestion is intended
as an optimization to allow efficient aggregation (it is not required
for correct operation in the general case).</t>
</section>
<section anchor="DAOStructure" title="Structure of DAO Messages">
<t>DAOs follow a common structure in both storing and non-storing
networks. In the most general form, a DAO message may include several
groups of options, where each group consists of one or more Target
options followed by one or more Transit Information options. The
entire group of Transit Information options applies to the entire
group of Target options. Later sections describe further details for
each mode of operation.</t>
<t><list style="numbers">
<t>RPL nodes MUST include one or more RPL Target Options in each
DAO message they transmit. One RPL Target Option MUST have a
prefix that includes the node's IPv6 address if that node needs
the DODAG to provision downward routes to that node. The RPL
Target Option MAY be immediately followed by an opaque RPL Target
Descriptor Option that qualifies it.</t>
<t>When a node updates the information in a Transit Information
option for a Target option that covers one of its addresses, it
MUST increment the Path Sequence number in that Transit
Information option. The Path Sequence number MAY be incremented
occasionally to cause a refresh to the downward routes.</t>
<t>One or more RPL Target Option in a unicast DAO message MUST be
followed by one or more Transit Information Option. All the
transit options apply to all the target options that immediately
precede them.</t>
<t>Multicast DAOs MUST NOT include the Parent Address in Transit
Information options.</t>
<t>A node that receives and processes a DAO message containing
information for a specific Target, and that has prior information
for that Target, MUST use the Path Sequence number in the Transit
Information option associated with that Target in order to
determine whether or not the DAO message contains updated
information as per <xref target="SequenceNumbers"></xref>.</t>
<t>If a node receives a DAO message that does not follow the above
rules, it MUST discard the DAO message without further
processing.</t>
</list></t>
<t>In non-storing mode additional rules apply to ensure the continuity
of end-to-end source route path:</t>
<t><list style="numbers">
<t>The address used as transit parent by the children MUST be
taken from a PIO with the 'R' flag set from that parent but is not
necessarily on link for the children.</t>
<t>The router that advertises an address as parent in a PIO MUST
also advertise that address as target in a DAO message.</t>
<t>An address that is advertised as target in a DAO MUST be
collocated or reachable onlink by the parent that is indicated in
the associated transit information.</t>
<t>A router might have targets that are not known to be onlink for
a parent, either because they are addresses located on an
alternate interface or because they belong to nodes that are
external to RPL, for instance connected hosts. In order to inject
such a target in the RPL network, the router MUST advertise itself
as the Parent Address in the Transit Information option for that
target, using an address that is onlink for that nodes DAO parent.
If the target belongs to an external node then the router MUST set
the External 'E' flag in the transit information.</t>
</list></t>
</section>
<section anchor="DAONonStoring" title="Non-storing Mode">
<t>In non-storing mode, RPL routes messages downward using IP source
routing. The following rule applies to nodes that are in non-storing
mode. Storing mode has a separate set of rules, described in <xref
target="DAOStoring"></xref>.</t>
<t><list style="numbers">
<t>The Parent Address field of a Transit Information Option MUST
contain one or more addresses. All of these addresses MUST be
addresses of DAO parents of the sender.</t>
<t>On receiving a unicast DAO, a node MUST propagate the updated
downward route information upwards. The node MAY use any parent in
the parent set. The downward route information in the DAO message
MAY be aggregated with other DAOs before being propagated upwards,
which MAY entail to delay the propagation as described below.</t>
<t>When a node removes a node from its DAO parent set, it MAY
generate a new DAO message with an updated Transit Information
option.</t>
</list></t>
<t>In non-storing mode, a node uses DAOs to report its DAO parents to
the DODAG Root. The DODAG Root can piece together a downward route to
a node by using DAO parent sets from each node in the route. The Path
Sequence information may be used to detect stale DAO information. The
purpose of this per-hop route calculation is to minimize traffic when
DAO parents change. If nodes reported complete source routes, then on
a DAO parent change the entire sub-DODAG would have to send new DAOs
to the DODAG Root. Therefore, in non-storing mode, a node can send a
single DAO, although it might choose to send more than one DAO message
to each of multiple DAO parents.</t>
<t>Nodes pack DAOs by sending a single DAO message with multiple RPL
Target Options. Each RPL Target Option has its own, immediately
following, Transit Information options.<!-- CUT?
Options may be modified enroute, e.g. path control:
These RPL
Target Options and Transit Information options pass unchanged
from their original source Up to the DODAG Root. --></t>
</section>
<section anchor="DAOStoring" title="Storing Mode">
<t>In storing mode, RPL routes messages downward by the IPv6
destination address. The following rule apply to nodes that are in
storing mode:</t>
<t><list style="numbers">
<t>The Parent Address field of a Transmit Information option MUST
be empty.</t>
<t>On receiving a unicast DAO, a node MUST compute if the DAO
would change the set of prefixes that the node itself advertises.
This computation SHOULD include consultation of the Path Sequence
information in the Transit Information options associated with the
DAO, to determine if the DAO message contains newer information
that supersedes the information already stored at the node. If so,
the node MUST generate a new DAO message and transmit it,
following the rules in <xref target="ScheduleDAO"></xref>. Such a
change includes receiving a No-Path DAO.</t>
<t>When a node generates a new DAO, it SHOULD unicast it to each
of its DAO parents. It MUST NOT unicast the DAO message to nodes
that are not DAO parents.</t>
<!-- TBD MUST -->
<t>When a node removes a node from its DAO parent set, it SHOULD
send a No-Path DAO message (<xref target="DAOOptions"></xref>) to
that removed DAO parent to invalidate the existing route.</t>
<t>If messages to an advertised downwards address suffer from a
forwarding error, neighbor unreachable detected (NUD), or similar
failure, a node MAY mark the address as unreachable and generate
an appropriate No-Path DAO.</t>
</list></t>
<t>DAOs advertise what destination addresses and prefixes a node has
routes to. Unlike in non-storing mode, these DAOs do not communicate
information about the routes themselves: that information is stored
within the network and is implicit from the IPv6 source address. When
a storing node generates a DAO, it uses the stored state of DAOs it
has received to produce a set of RPL Target options and their
associated Transmit Information options.</t>
<t>Because this information is stored within each node's routing
tables, in storing mode DAOs are communicated directly to DAO parents,
who store this information.</t>
</section>
<section anchor="PathControl" title="Path Control">
<t>A DAO message from a node contains one or more Target Options. Each
Target Option specifies either the node's prefix, a prefix of
addresses reachable outside the LLN, or a destination in the node's
sub-DODAG. The Path Control field of the Transit Information option
allows nodes to request or allow for multiple downward routes. A node
constructs the Path Control field of a Transit Information option as
follows:</t>
<t><list style="numbers">
<t>The bit width of the path control field MUST be equal to the
value (PCS + 1), where PCS is specified in the control field of
the DODAG Configuration Option. Bits greater than or equal to the
value (PCS + 1) MUST be cleared on transmission and MUST be
ignored on reception. Bits below that value are considered
"active" bits.</t>
<t>The node MUST logically construct groupings of its DAO parents
while populating the Path Control field, where each group consists
of DAO parents of equal preference. Those groups MUST then be
ordered according to preference, which allows for a logical
mapping of DAO parents onto Path Control subfields (See <xref
target="PathControlEncoding"></xref>). Groups MAY be repeated in
order to extend over the entire bit width of the patch control
field, but the order, including repeated groups, MUST be retained
so that preference is properly communicated.</t>
<t>For a RPL Target option describing a node's own address or a
prefix outside the LLN, at least one active bit of the Path
Control field MUST be set. More active bits of the Path Control
field MAY be set.</t>
<t>If a node receives multiple DAOs with the same RPL Target
option, it MUST bitwise-OR the Path Control fields it receives.
This aggregated bitwise-OR represents the number of downward
routes the prefix requests.</t>
<t>When a node sends a DAO message to one of its DAO parents, it
MUST select one or more of the bits that are set active in the
subfield that is mapped to the group containing that DAO parent
from the aggregated Path Control field. A given bit can only be
presented as active to one parent. The DAO message it transmits to
its parent MUST have these active bits set and all other active
bits cleared.</t>
<t>For the RPL Target option and DAOSequence number, the DAOs a
node sends to different DAO parents MUST have disjoint sets of
active Path Control bits. A node MUST NOT set the same active bit
on DAOs to two different DAO parents.</t>
<t>Path control bits SHOULD be allocated according to the
preference mapping of DAO parents onto Path Control subfields,
such that the active Path Control bits, or groupings of bits, that
belong to a particular Path Control subfield are allocated to DAO
parents within the group that was mapped to that subfield.</t>
<t>In a non-storing mode of operation, a node MAY pass DAOs
through without performing any further processing on the Path
Control field.</t>
<t>A node MUST NOT unicast a DAO message that has no active bits
in the Path Control field set. It is possible that, for a given
Target option, that a node does not have enough aggregate Path
Control bits to send a DAO message containing that Target to each
of its DAO Parents, in which case those least preferred DAO
Parents may not get a DAO message for that Target.</t>
</list></t>
<t>The Path Control field allows a node to bound how many downward
routes will be generated to it. It sets a number of bits in the Path
Control field equal to the maximum number of downward routes it
prefers. Each bit is sent to at most one DAO parent; clusters of bits
can be sent to a single DAO parent for it to divide among its own DAO
parents.</t>
<t>A node that provisions a DAO route for a Target that has an
associated Path Control field SHOULD use the content of that Path
Control field in order to determine an order of preference among
multiple alternative DAO routes for that Target. The Path Control
field assignment is derived from preference (of the DAO parents), as
determined on the basis of this node's best knowledge of the
"end-to-end" aggregated metrics in the "downward" direction as per the
objective function. In non storing mode the root can determine the
downward route by aggregating the information from each received DAO,
which includes the Path Control indications of preferred DAO
parents.</t>
<section anchor="PathControlExample" title="Path Control Example">
<t>Suppose that there is an LLN operating in storing mode that
contains a Node N with four parents, P1, P2, P3, and P4. Let N have
three children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such
that there will be 8 active bits in the Path Control field:
11111111b. Consider the following example:</t>
<t>The Path Control field is split into 4 subfields, PC1
(11000000b), PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b),
such that those 4 subfields represent 4 different levels of
preference as per <xref target="PathControlEncoding"></xref>. The
implementation at Node N, in this example, groups {P1, P2} to be of
equal preference to each other, and the most preferred group
overall. {P3} is less preferred to {P1, P2}, and more preferred to
{P4}. Let Node N then perform its path control mapping such that:
<figure>
<artwork><![CDATA[
{P1, P2} -> PC1 (11000000b) in the Path Control field
{P3} -> PC2 (00110000b) in the Path Control field
{P4} -> PC3 (00001100b) in the Path Control field
{P4} -> PC4 (00000011b) in the Path Control field
]]></artwork>
</figure>Note that the implementation repeated {P4} in order to
get complete coverage of the Path Control field.</t>
<t><list style="numbers">
<t>Let C1 send a DAO containing a Target T with a Path Control
10000000b. Node N stores an entry associating 10000000b with the
Path Control field for C1 and Target T.</t>
<t>Let C2 send a DAO containing a Target T with a Path Control
00010000b. Node N stores an entry associating 00010000b with the
Path Control field for C1 and Target T.</t>
<t>Let C3 send a DAO containing a Target T with a Path Control
00001100b. Node N stores an entry associating 00001100b with the
Path Control field for C1 and Target T.</t>
<t>At some later time, Node N generates a DAO for Target T. Node
N will construct an aggregate Path Control field by ORing
together the contribution from each of its children that have
given a DAO for Target T. The aggregate Path Control field thus
has the active bits set as: 10011100b.</t>
<t>Node N then distributes the aggregate Path Control bits among
its parents P1, P2, P3, and P4 in order to prepare the DAO
messages.</t>
<t>P1 and P2 are eligible to receive active bits from the most
preferred subfield (11000000b). Those bits are 10000000b in the
aggregate Path Control field. Node N must the bit to one of the
two parents only. In this case, Node P1 is allocated the bit,
and gets the Path Control field 10000000b for its DAO. There are
no bits left to allocate to Node P2, thus Node P2 would have a
Path Control field of 00000000b and a DAO cannot be generated to
Node P2 since there are no active bits.</t>
<t>The second-most preferred subfield (00110000b) has the active
bits 00010000b. Node N has mapped P3 to this subfield. Node N
may allocates the active bit to P3, constructing a DAO for P3
containing Target T with a Path Control of 00010000b.</t>
<t>The third-most preferred subfield (00001100b) has the active
bits 00001100b. Node N has mapped P4 to this subfield. Node N
may allocate both bits to P4, constructing a DAO for P4
containing Target T with a Path Control of 00001100b.</t>
<t>The least preferred subfield (00000011b) has no active bits.
Had there been active bits, those bits would have been added to
the Path Control field of the DAO constructed for P4.</t>
<t>The process of populating the DAO messages destined for P1,
P2, P3, P4 with other targets (other than T) proceeds as
according the aggregate path control fields collected for those
targets.</t>
</list></t>
</section>
</section>
<section anchor="MulticastDAO"
title="Multicast Destination Advertisement Messages">
<t>A special case of DAO operation, distinct from unicast DAO
operation, is multicast DAO operation which may be used to populate
'1-hop' routing table entries.</t>
<t><list style="numbers">
<t>A node MAY multicast a DAO message to the link-local scope
all-RPL-nodes multicast address.</t>
<t>A multicast DAO message MUST be used only to advertise
information about the node itself, i.e. prefixes directly
connected to or owned by this node, such as a multicast group that
the node is subscribed to or a global address owned by the
node.</t>
<t>A multicast DAO message MUST NOT be used to relay connectivity
information learned (e.g. through unicast DAO) from another
node.</t>
<!-- TBD confirm
<t>Information obtained from a multicast DAO message MAY be
installed in the routing table and MAY be propagated by a node in
unicast DAOs.</t>
-->
<t>A node MUST NOT perform any other DAO related processing on a
received multicast DAO message, in particular a node MUST NOT
perform the actions of a DAO parent upon receipt of a multicast
DAO.</t>
</list></t>
<t><list style="symbols">
<t>The multicast DAO may be used to enable direct P2P
communication, without needing the DODAG to relay the packets.</t>
</list></t>
</section>
</section>
<section anchor="SecurityMechanisms" title="Security Mechanisms">
<t>This section describes the generation and processing of secure RPL
messages. The high order bit of the RPL message code identifies whether
a RPL message is secure or not. In addition to secure versions of basic
control messages (DIS, DIO, DAO, DAO-Ack), RPL has several messages
which are relevant only in networks with security enabled.</t>
<t>Implementation complexity and size is a core concern for LLNs such
that it may be economically or physically impossible to include
sophisticated security provisions in a RPL implementation.
Furthermore, many deployments can utilize link-layer or other
security mechanisms to meet their security requirements without
requiring the use of security in RPL itself.</t>
<t>
Therefore, the security features described in this document are
OPTIONAL to implement. A given implementation MAY support a subset
(including the empty set) of the described security features, for
example it could support integrity and confidentiality, but not
signatures. An implementation SHOULD clearly specify which security
mechanisms are supported, and deployers are RECOMMENDED to carefully
consider their security requirements and the availability of security
mechanisms in their network.
</t>
<section anchor="SecurityOverview" title="Security Overview">
<t>RPL supports three security modes:</t>
<t><list style="symbols">
<t>Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO,
and DAO-Ack messages, which do not have security sections. As a
network could be using other security mechanisms, such as
link-layer security, unsecured mode does not imply all messages
are sent without any protection.</t>
<t>Pre-installed. In this security mode, RPL uses secure messages.
To join a RPL Instance, a node must have a pre-installed key.
Nodes use this to provide message confidentiality, integrity, and
authenticity. A node may, using this preinstalled key, join the
RPL network as either a host or a router.</t>
<t>Authenticated. In this security mode, RPL uses secure messages.
To join a RPL Instance, a node must have a pre-installed key. Node
use this key to provide message confidentiality, integrity, and
authenticity. Using this preinstalled key, a node may join the
network as a host only. To join the network as a router, a node
must obtain a second key from a key authority. This key authority
can authenticate that the requester is allowed to be a router
before providing it with the second key.</t>
</list></t>
<t>Whether or not the RPL Instance uses unsecured mode is signaled by
whether it uses secure RPL messages. Whether a secured network uses
the pre-installed or authenticated mode is signaled by the 'A' bit of
the DAG Configuration option.</t>
<t>This specification specifies CCM* -- Counter with CBC-MAC (Cipher
Block Chaining Message Authentication Code) -- as the cryptographic
basis for RPL security<xref target="RFC3610"></xref>. In this
specification, CCM uses AES-128 as its underlying cryptographic
algorithm. There are bits reserved in the security section to specify
other algorithms in the future.</t>
<t>All secured RPL messages have either a message authentication code
(MAC) or a signature. Secured RPL messages optionally also have
encryption protection for confidentiality. Secured RPL message formats
support both integrated encryption/authentication schemes (e.g., CCM*)
as well as schemes that separately encrypt and authenticate
packets.</t>
</section>
<section anchor="SecureJoining" title="Joining a Secure Network">
<t>RPL security assumes that a node wishing to join a secured network
has been preconfigured with a shared key for communicating with
neighbors and the RPL root. To join a secure RPL network, a node
either listens for secure DIOs or triggers secure DIOs by sending a
secure DIS. In addition to the DIO/DIS rules in <xref
target="UpwardRoutes"></xref>, secure DIO and DIS messages have these
rules:</t>
<t><list style="numbers">
<t>If sent, this initial secure DIS MUST set the Key Identifier
Mode field to 0 (00) and MUST set the Security Level field to 1
(001). The key used MUST be the preconfigured group key (Key Index
0x00).</t>
<t>When a node resets its Trickle timer in response to a secure
DIS (<xref target="DIOTransmission"></xref>), the next DIO it
transmits MUST be a secure DIO with the same security
configuration as the secure DIS. If a node receives multiple
secure DIS messages before it transmits a DIO, the secure DIO MUST
have the same security configuration as the last DIS it is
responding to.</t>
<t>When a node sends a DIO in response to a unicast secure DIS
(<xref target="DIOTransmission"></xref>), the DIO MUST be a secure
DIO.</t>
</list></t>
<t>The above rules allow a node to join a secured RPL Instance using
the preconfigured shared key. Once a node has joined the DODAG using
the preconfigured shared key, the 'A' bit of the Configuration option
determines its capabilities. If the 'A' bit of the Configuration is
cleared, then nodes can use this preinstalled, shared key to exchange
messages normally: it can issue DIOs, DAOs, etc.</t>
<t>If the 'A' bit of the Configuration option is set and the RPL
Instance is operating in authenticated mode:</t>
<t><list style="numbers">
<t>A node MUST NOT advertise a Rank besides INFINITE_RANK in
secure DIOs secured with Key Index 0x00. When processing DIO
messages secured with Key Index 0x00, a processing node MUST
consider the advertised Rank to be INFINITE_RANK. Any other value
results in the message being discarded.</t>
<t>Secure DAOs using Key Index 0x00 MUST NOT have a RPL Target
option with a prefix besides the node's address. If a node
receives a secured DAO message using the preinstalled, shared key
where the RPL Target option does not match the IPv6 source
address, it MUST discard the secured DAO message without further
processing.</t>
</list></t>
<t>The above rules mean that in RPL Instances where the 'A' bit is
set, using Key Index 0x00 a node can join the RPL Instance as a host
but not a router. A node must communicate with a key authority to
obtain a key that will enable it to act as a router.</t>
</section>
<section anchor="KeyInstallation" title="Installing Keys">
<t>Authenticated mode requires a would-be router to dynamically
install new keys once they have joined a network as a host. Having
joined as a host, the node uses standard IP messaging to communicate
with an authorization server, which can provide new keys.</t>
<t>The protocol to obtain such keys is the subject of a future
standard.</t>
</section>
<section anchor="ConsistencyChecks" title="Consistency Checks">
<t>RPL nodes send Consistency Check (CC) messages to protect against
replay attacks and synchronize counters.</t>
<t><list style="numbers">
<t>If a node receives a unicast CC message with the R bit cleared,
and it is a member of or is in the process of joining the
associated DODAG, it SHOULD respond with a unicast CC message to
the sender. This response MUST have the R bit set, and MUST have
the same Nonce, RPLInstanceID and DODAGID fields as the message it
received.</t>
<t>If a node receives a multicast CC message, it MUST discard the
message with no further processing.</t>
</list></t>
<t>Consistency Check messages allow nodes to issue a
challenge-response to validate a node's current Counter value. Because
the CC Nonce is generated by the challenger, an adversary replaying
messages is unlikely to be able to generate a correct response. The
Counter in the Consistency Check response allows the challenger to
validate the Counter values it hears.</t>
</section>
<section anchor="SecurityCounter" title="Counters">
<t>In the simplest case, the Counter value is an unsigned integer that
a node increments by one or more on each secured RPL transmission. The
Counter MAY represent a timestamp that has the following
properties:</t>
<t><list style="numbers">
<t>The timestamp MUST be at least six octets long.</t>
<t>The timestamp MUST be in 1024Hz (binary millisecond)
granularity.</t>
<t>The timestamp start time MUST be January 1, 1970, 12:00:00AM
UTC.</t>
<t>If the Counter represents such as timestamp, the Counter value
MUST be a value computed as follows. Let T be the timestamp, S be
the start time of the key in use, and E be the end time of the key
in use. Both S and E are represented using the same 3 rules as the
timestamp described above. If E > T < S, then the Counter is
invalid and a node MUST NOT generate a packet. Otherwise, the
Counter value is equal to T-S.</t>
<t>If the Counter represents such a timestamp, a node MAY set the
'T' flag of the security section of secured RPL packets.</t>
<t>If the Counter field does not present such a timestamp, then a
node MUST NOT set the 'T' flag.</t>
<t>If a node does not have a local timestamp that satisfies the
above requirements, it MUST ignore the 'T' flag.</t>
</list></t>
<t>If a node supports such timestamps and it receives a message with
the 'T' flag set, it MAY apply the temporal check on the received
message described in <xref target="TemporalCheck"></xref>. If a node
receives a message without the 'T' flag set, it MUST NOT apply this
temporal check. A node's security policy MAY, for application reasons,
include rejecting all messages without the 'T' flag set.</t>
<t>The 'T' flag is present because many LLNs today already maintain
global time synchronization at sub-millisecond granularity for
security, application, and other reasons. Allowing RPL to leverage
this existing functionality when present greatly simplifies solutions
to some security problems, such as delay protection.</t>
</section>
<section title="Transmission of Outgoing Packets">
<t>Given an outgoing RPL control packet and required security
protection, this section describes how RPL generates the secured
packet to transmit. It also describes the order of cryptographic
operations to provide the required protection.</t>
<t>The requirement for security protection and the level of security
to be applied to an outgoing RPL packet shall be determined by the
node's security policy database. The configuration of this security
policy database for outgoing packet processing is implementation
specific.</t>
<t>Where secured RPL messages are to be transmitted, a RPL node MUST
set the security section (T, Sec, KIM, and LVL) in the outgoing RPL
packet to describe the protection level and security settings that are
applied (see <xref target="RPLSecurityFields"></xref>). The Security
subfield bit of the RPL message Code field MUST be set to indicate the
secure RPL message.</t>
<t>The Counter value used in constructing the Nonce to secure the
outgoing packet MUST be an increment of the last Counter transmitted
to the particular destination address.</t>
<t>Where security policy specifies the application of delay
protection, the Timestamp Counter used in constructing the Nonce to
secure the outgoing packet MUST be incremented according to the rules
in <xref target="SecurityCounter"></xref>. Where a Timestamp Counter
is applied (indicated with the 'T' flag set) the locally maintained
Time Counter MUST be included as part of the transmitted secured RPL
message.</t>
<t>The cryptographic algorithm used in securing the outgoing packet
shall be specified by the node's security policy database and MUST be
indicated in the value of the Sec field set within the outgoing
message.</t>
<t>The security policy for the outgoing packet shall determine the
applicable Key Identifier Mode (KIM) and Key Identifier specifying the
security key to be used for the cryptographic packet processing,
including the optional use of signature keys (see <xref
target="RPLSecurityFields"></xref>). The security policy will also
specify the algorithm (Algorithm) and level of protection (Level) in
the form of authentication or authentication and encryption, and
potential use of signatures that shall apply to the outgoing
packet.</t>
<t>Where encryption is applied, a node MUST replace the original
packet payload with that payload encrypted using the security
protection, key, and nonce specified in the security section of the
packet.</t>
<t>All secured RPL messages include integrity protection. In
conjunction with the security algorithm processing, a node derives
either a Message Authentication Code (MAC) or signature that MUST be
included as part of the outgoing secured RPL packet.</t>
</section>
<section title="Reception of Incoming Packets">
<t>This section describes the reception and processing of a secured
RPL packet. Given an incoming secured RPL packet, where the Security
subfield bit of the RPL message Code field is set, this section
describes how RPL generates an unencrypted variant of the packet and
validates its integrity.</t>
<t>The receiver uses the RPL security control fields to determine the
necessary packet security processing. If the described level of
security for the message type and originator does not meet locally
maintained security policies, a node MAY discard the packet without
further processing. These policies can include security levels, keys
used, source identifiers, or the lack of timestamp-based counters (as
indicated by the 'T' flag). The configuration of the security policy
database for incoming packet processing is outside the scope of this
specification (it may, for example, be defined through DIO
Configuration or through out-of-band administrative router
configuration).</t>
<t>Where the message security level (LVL) indicates an encrypted RPL
message, the node uses the key information identified through the KIM
field as well as the Nonce as input to the message payload decryption
processing. The Nonce shall be derived from the message Counter field
and other received and locally maintained information (see <xref
target="SecurityNonce"></xref>). The plaintext message contents shall
be obtained by invoking the inverse cryptographic mode of operation
specified by the Sec field of the received packet.</t>
<t>The receiver shall use the Nonce and identified key information to
check the integrity of the incoming packet. If the integrity check
fails against the received message authentication code (MAC), a node
MUST discard the packet.</t>
<t>If the received message has an initialized (zero value) Counter
value and the receiver has an incoming Counter currently maintained
for the originator of the message, the receiver MUST initiate a
Counter resynchronization by sending a Consistency Check response
message (see <xref target="ConsistencyCheck"></xref>) to the message
source. The Consistency Check response message shall be protected with
the current full outgoing Counter maintained for the particular node
address. That outgoing Counter will be included within the security
section of the message while the incoming Counter will be included
within the Consistency Check message payload.</t>
<t>Based on the specified security policy a node MAY apply replay
protection for a received RPL message. The replay check SHOULD be
performed before the authentication of the received packet. The
Counter as obtained from the incoming packet shall be compared against
the watermark of the incoming Counter maintained for the given
origination node address. If the received message Counter value is
non-zero and less than the maintained incoming Counter watermark a
potential packet replay is indicated and the node MUST discard the
incoming packet.</t>
<t>If delay protection is specified as part of the incoming packet
security policy checks, the Timestamp Counter is used to validate the
timeliness of the received RPL message. If the incoming message
Timestamp Counter value indicates a message transmission time prior to
the locally maintained transmission time Counter for the originator
address, a replay violation is indicated and the node MUST discard the
incoming packet. If the received Timestamp Counter value indicates a
message transmission time that is earlier than the Current time less
the acceptable packet delay, a delay violation is indicated and the
node MUST discard the incoming packet.</t>
<t>Once a message has been decrypted, where applicable, and has
successfully passed its integrity check, replay, and optionally delay
protection checks, the node can update its local security information,
such as the source's expected Counter value for replay comparison.</t>
<t>A node MUST NOT update its security information on receipt of a
message that fails security policy checks or other applied integrity,
replay, or delay checks.</t>
<section anchor="TemporalCheck" title="Timestamp Key Checks">
<t>If the 'T' flag of a message is set and a node has a local
timestamp that follows the requirements in <xref
target="SecurityCounter"></xref>, then a node MAY check the temporal
consistency of the message. The node computes the transmit time of
the message by adding the Counter value to the start time of the
associated key. If this transmit time is past the end time of the
key, the node MAY discard the message without further processing. If
the transmit time is too far in the past or future compared to the
local time on the receiver, it MAY discard the message without
further processing.</t>
</section>
</section>
<section title="Coverage of Integrity and Confidentiality">
<t>For a RPL ICMPv6 message, the entire packet is within the scope of
RPL security.</t>
<t>Message authentication codes (MAC) and signatures are calculated
over the entire IPv6 packet. MAC and signature calculations are
performed before any compression that lower layers may apply.</t>
<t>When a RPL ICMPv6 message is encrypted, encryption starts at the
first byte after the security section and continues to the last byte
of the packet. The IPv6 header, ICMPv6 header, and RPL message Up to
the end of the security section are not encrypted, as they are needed
to correctly decrypt the packet.</t>
<t>For example, a node sending a message with LVL=5, KIM=0, and
Algorithm=0 uses the CCM* algorithm<xref target="CCMStar"></xref> to
create a packet with attributes ENC-MAC-32: it encrypts the packet and
appends a 32-bit MAC. The block cipher key is determined by the Key
Index; the Nonce is computed as described in <xref
target="SecurityNonce"></xref>; the message to authenticate and
encrypt is the RPL message starting at the first byte after the
security section and ends with the last byte of the packet; the
additional authentication data starts with the beginning of the IPv6
header and ends with the last byte of the RPL security section.</t>
</section>
<section anchor="CryptoMode" title="Cryptographic Mode of Operation">
<t>The cryptographic mode of operation described in this specification
(Algorithm = 0) is based on CCM and the block-cipher AES-128<xref
target="RFC3610"></xref>. This mode of operation is widely supported
by existing implementations and coincides with the CCM* mode of
operation<xref target="CCMStar"></xref>. CCM mode requires a
nonce.</t>
<section anchor="SecurityNonce" title="Nonce">
<t>A RPL node constructs a CCM nonce as follows:</t>
<t><figure anchor="CCM*Nonce" title="CCM* Nonce">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved | LVL |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Source Identifier:">8 bytes. Source Identifier is
set to the logical identifier of the originator of the protected
packet.</t>
<t hangText="Counter:">4 bytes. Counter is set to the
(uncompressed) value of the corresponding field in the Security
option of the RPL control message.</t>
<t hangText="Security Level (LVL):">3 bits. Security Level is
set to the value of the corresponding field in the Security
option of the RPL control message.</t>
</list></t>
<t>Unassigned bits of the nonce are reserved. They MUST be set to
zero when constructing the nonce.</t>
<t>All fields of the nonce are represented in most-significant-octet
and most-significant-bit first order.</t>
</section>
<section anchor="Signatures" title="Signatures">
<t>If the Key Identification Mode (KIM) mode indicates the use of
signatures (a value of 3), then a node appends a signature to the
data payload of the packet. The Security Level (LVL) field describes
the length of this signature.</t>
<t>The signature scheme in RPL for Security Mode 3 is an
instantiation of the RSA algorithm <xref target="RFC3447"></xref>.
It uses as public key the pair (n,e), where n is a 3072-bit RSA
modulus and where e=2^{16}+1. It uses CCM* mode<xref
target="CCMStar"></xref> as the encryption scheme with M=0 (as a
stream-cipher). It uses the SHA-2 hash function <xref
target="sha2"></xref>. It uses the message encoding rule of <xref
target="RFC3447"></xref>.</t>
<t>Let 'a' be a concatenation of a six-byte representation of
Counter and the message header. The packet payload is the
right-concatenation of packet data 'm' and the signature 's'. This
signature scheme is invoked with the right-concatenation of the
message parts a and m, whereas the signature verification is invoked
with the right-concatenation of the message parts a and m, and with
signature s.</t>
<t>RSA signatures of this form provide sufficient protection for RPL
networks. If needed, alternative signature schemes which produce
more concise signatures may be the subject of a future work.</t>
</section>
</section>
</section>
<section anchor="forwarding"
title="Packet Forwarding and Loop Avoidance/Detection">
<section anchor="PacketForwarding"
title="Suggestions for Packet Forwarding">
<t>When forwarding a packet to a destination, precedence is given to
selection of a next-hop successor as follows:</t>
<t><list style="numbers">
<t>This specification only covers how a successor is selected from
the DODAG Version that matches the RPLInstanceID marked in the
IPv6 header of the packet being forwarded. Routing outside the
instance can be done as long as additional rules are put in place
such as strict ordering of instances and routing protocols to
protect against loops. Such rules may be defined in a separate
document.</t>
<t>If a local administrative preference favors a route that has
been learned from a different routing protocol than RPL, then use
that successor.</t>
<t>If the packet header specifies a source route by including a
RH4 header as specified in <xref
target="I-D.ietf-6man-rpl-routing-header"></xref>, then use that
route. If the node fails to forward the packet with that specified
source route, then that packet SHOULD be dropped. The node MAY log
an error. The node MAY send an ICMPv6 Error in Source Routing
Header message to the source of the packet (See <xref
target="ICMPv6ErrSrcRte"></xref>).<!-- TBD the node SHOULD send a
no-PATH? --></t>
<t>If there is an entry in the routing table matching the
destination that has been learned from a multicast destination
advertisement (e.g. the destination is a one-hop neighbor), then
use that successor.</t>
<t>If there is an entry in the routing table matching the
destination that has been learned from a unicast destination
advertisement (e.g. the destination is located Down the
sub-DODAG), then use that successor. If there are DAO Path Control
bits associated with multiple successors, then consult the Path
Control bits to order the successors by preference when choosing.
If, for a given DAO Path Control bit, multiple successors are
recorded as having asserted that bit, precedence should be given
to the successor who most recently asserted that bit.</t>
<t>If there is a DODAG Version offering a route to a prefix
matching the destination, then select one of those DODAG parents
as a successor according to the OF and routing metrics.</t>
<t>Any other as-yet-unattempted DODAG parent may be chosen for the
next attempt to forward a unicast packet when no better match
exists.</t>
<t>Finally the packet is dropped. ICMP Destination Unreachable MAY
be invoked (an inconsistency is detected).</t>
</list></t>
<t>Hop Limit MUST be decremented when forwarding as per <xref
target="RFC2460"></xref>.</t>
<t>Note that the chosen successor MUST NOT be the neighbor that was
the predecessor of the packet (split horizon), except in the case
where it is intended for the packet to change from an upward to a
downward flow, as determined by the routing table of the node making
the change, such as switching from DIO routes to DAO routes as the
destination is neared in order to continue traveling toward the
destination.</t>
</section>
<section anchor="loopdetect" title="Loop Avoidance and Detection">
<t>RPL loop avoidance mechanisms are kept simple and designed to
minimize churn and states. Loops may form for a number of reasons,
e.g. control packet loss. RPL includes a reactive loop detection
technique that protects from meltdown and triggers repair of broken
paths.</t>
<t>RPL loop detection uses information that contained within the data
packet using the RPL Option <xref
target="I-D.ietf-6man-rpl-option"></xref>) in an IPv6 Hop-by-Hop
Option header. The RPL Option is a generic container for a list of
TLVs. This specification defines a new RPL Option type, called the RPL
Loop Detection. The RPL Loop Detection TLV is placed in the RPL Option
with Option Type = 1 (to be confirmed by IANA), Option Data Length = 4
octets, and the Value has the following format:</t>
<t><figure anchor="RPLPacketInformation"
title="RPL Packet Information">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Down 'O':">1-bit flag indicating whether the packet
is expected to progress Up or Down. A router sets the 'O' flag
when the packet is expected to progress Down (using DAO routes),
and clears it when forwarding toward the DODAG root (to a node
with a lower rank). A host or RPL leaf node MUST set the 'O' flag
to 0.</t>
<t hangText="Rank-Error 'R':">1-bit flag indicating whether a rank
error was detected. A rank error is detected when there is a
mismatch in the relative ranks and the direction as indicated in
the 'O' bit. A host or RPL leaf node MUST set the 'R' bit to
0.</t>
<t hangText="Forwarding-Error 'F':">1-bit flag indicating that
this node can not forward the packet further towards the
destination. The 'F' bit might be set by a child node that does
not have a route to destination for a packet with the Down 'O' bit
set. A host or RPL leaf node MUST set the 'F' bit to 0.</t>
<t hangText="RPLInstanceID:">8-bit field indicating the DODAG
instance along which the packet is sent.</t>
<t hangText="SenderRank:">16-bit field set to zero by the source
and to DAGRank(rank) by a router that forwards inside the RPL
network.</t>
</list></t>
<section anchor="sno" title="Source Node Operation">
<t>If the source is aware of the RPLInstanceID that is preferred for
the packet, then it MUST set the RPLInstanceID field associated with
the packet accordingly, otherwise it MUST set it to the
RPL_DEFAULT_INSTANCE.</t>
</section>
<section title="Router Operation">
<section anchor="RPLinstanceforwarding" title="Instance Forwarding">
<t>RPLInstanceIDs are used to avoid loops between DODAGs from
different origins. DODAGs that are constructed for antagonistic
constraints might contain paths that, if mixed together, would
yield loops. Those loops are avoided by forwarding a packet along
the DODAG that is associated to a given instance.</t>
<t>The RPLInstanceID is associated by the source with the packet.
This RPLInstanceID MUST match the RPL Instance onto which the
packet is placed by any node, be it a host or router.</t>
<t>For a packet that is originated from outside the RPL network,
the source of the packet might be aware of the RPL network, of the
constraints imposed on OFs, and of associated RPLInstanceIDs. In
that case, the source of the packet MAY tag the flow label with
the RPLInstanceID.</t>
<t>A RPL router that forwards a packet in the RPL network MUST
check if the packet includes the RPL Loop Detection TLV in a RPL
Option within the IPv6 Hop-by-Hop Option header. If one does not
exist, the RPL router MUST insert a RPL Loop Detection type as
specified in <xref target="I-D.ietf-6man-rpl-option"></xref>. If
the router is an ingress router that injects the packet into the
RPL network, the router MUST set the RPLInstanceID field in the
RPL Loop Detection TLV.</t>
<t>A router that forwards a packet to outside the RPL network MUST
remove the RPL Option as specified in <xref
target="I-D.ietf-6man-rpl-option"></xref>.</t>
<t>When a router receives a packet that specifies a given
RPLInstanceID and the node can forward the packet along the DODAG
associated to that instance, then the router MUST do so and leave
the RPLInstanceID value unchanged.</t>
<t>If any node can not forward a packet along the DODAG associated
to the RPLInstanceID, then the node SHOULD discard the packet and
send an ICMP error message.</t>
</section>
<section anchor="LoopDetectInconsistency"
title="DAG Inconsistency Loop Detection">
<t>The DODAG is inconsistent if the direction of a packet does not
match the rank relationship. A receiver detects an inconsistency
if it receives a packet with either: <list>
<t>the 'O' bit set (to Down) from a node of a higher rank.</t>
<t>the 'O' bit cleared (for Up) from a node of a lesser
rank.</t>
</list></t>
<t>When the DODAG root increments the DODAGVersionNumber, a
temporary rank discontinuity may form between the next DODAG
Version and the prior DODAG Version, in particular if nodes are
adjusting their rank in the next DODAG Version and deferring their
migration into the next DODAG Version. A router that is still a
member of the prior DODAG Version may choose to forward a packet
to a (future) parent that is in the next DODAG Version. In some
cases this could cause the parent to detect an inconsistency
because the rank-ordering in the prior DODAG Version is not
necessarily the same as in the next DODAG Version and the packet
may be judged to not be making forward progress. If the sending
router is aware that the chosen successor has already joined the
next DODAG Version, then the sending router MUST update the
SenderRank to INFINITE_RANK as it forwards the packets across the
discontinuity into the next DODAG Version in order to avoid a
false detection of rank inconsistency.</t>
<!--
<t>The propagation of a new version creates local
inconsistencies. In particular, it is possible for a router to
forward a packet to a future parent (same instance, same DODAGID,
higher version) without a loop, regardless of the rank of that
parent. In that case, the sending router MUST present itself as a
host on the future DODAG Version and use a rank of INFINITE_RANK
as it forwards the packets via a future parent to avoid a false
positive.</t>
-->
<t>One inconsistency along the path is not considered a
critical error and the packet may continue. But a second detection
along the path of a same packet should not occur and the packet
MUST be dropped.</t>
<t>This process is controlled by the Rank-Error bit associated
with the packet. When an inconsistency is detected on a packet, if
the Rank-Error bit was not set then the Rank-Error bit is set. If
it was set the packet MUST be discarded and the trickle timer MUST
be reset.</t>
</section>
<section title="DAO Inconsistency Loop Detection and Recovery">
<t>A DAO inconsistency happens when a router has a downward route
that was previously learned from a DAO message via a child, but
that downward route is not longer valid in the child, e.g. because
that related state in the child has been cleaned up. With DAO
inconsistency loop recovery, a packet can be used to recursively
explore and cleanup the obsolete DAO states along a sub-DODAG.</t>
<t>In a general manner, a packet that goes Down should never go Up
again. If DAO inconsistency loop recovery is applied, then the
router SHOULD send the packet back to the parent that passed it
with the Forwarding-Error 'F' bit set and the 'O' bit left
untouched. Otherwise the router MUST silently discard the
packet.</t>
</section>
<section title="Forward Path Recovery">
<t>Upon receiving a packet with a Forwarding-Error bit set, the
node MUST remove the routing states that caused forwarding to that
neighbor, clear the Forwarding-Error bit and attempt to send the
packet again. The packet may be sent to an alternate neighbor,
after the expiration of a user-configurable implementation
specific timer. If that alternate neighbor still has an
inconsistent DAO state via this node, the process will recurse,
this node will set the Forwarding-Error 'F' bit and the routing
state in the alternate neighbor will be cleaned up as well.</t>
</section>
</section>
</section>
</section>
<section title="Multicast Operation">
<t>This section describes further the multicast routing operations over
an IPv6 RPL network, and specifically how unicast DAOs can be used to
relay group registrations up. Wherever the following text mentions
Multicast Listener Discovery (MLD), one can read MLDv1 (<xref
target="RFC2710"></xref>) or MLDv2 (<xref target="RFC3810"></xref>).</t>
<t>Nodes that support the RPL storing mode of operation SHOULD also
support multicast DAO operations as described below. Nodes that only
support the non-storing mode of operation are not expected to support
this section.</t>
<t>The multicast operation is controlled by the MOP field in the DIO.
<list>
<t>If the MOP field requires multicast support, then a node that
joins the RPL network as a router must operate as described in this
section for multicast signaling and forwarding within the RPL
network. A node that does not support the multicast operation
required by the MOP field can only join as a leaf.</t>
<t>If the MOP field does not require multicast support, then
multicast is handled by some other way that is out of scope for this
specification. (Examples may include a series of unicast copies or
limited-scope flooding).</t>
</list></t>
<t>As is traditional, a listener uses a protocol such as MLD with a
router to register to a multicast group.</t>
<t>Along the path between the router and the DODAG root, MLD requests
are mapped and transported as DAO messages within RPL; each hop
coalesces the multiple requests for a same group as a single DAO message
to the parent(s), in a fashion similar to proxy IGMP, but recursively
between child router and parent Up to the DODAG root.</t>
<t>A router might select to pass a listener registration DAO message to
its preferred parent only, in which case multicast packets coming back
might be lost for all of its sub-DODAG if the transmission fails over
that link. Alternatively the router might select to copy additional
parents as it would do for DAO messages advertising unicast
destinations, in which case there might be duplicates that the router
will need to prune.</t>
<t>As a result, multicast routing states are installed in each router on
the way from the listeners to the DODAG root, enabling the root to copy
a multicast packet to all its children routers that had issued a DAO
message including a Target option for that multicast group, as well as
all the attached nodes that registered over MLD.</t>
<t>For unicast traffic, it is expected that the grounded DODAG root acts
as an LBR and MAY redistribute the RPL routes over the external
infrastructure using whatever routing protocol is used in the other
routing domain. For multicast traffic, the root MAY proxy MLD for all
the nodes attached to the RPL domain (this would be needed if the
multicast source is located in the external infrastructure). For such a
source, the packet will be replicated as it flows Down the DODAG based
on the multicast routing table entries installed from the DAO
message.</t>
<t>For a multicast packet sourced from inside the DODAG, the packet is
passed to the preferred parents, and if that fails then to the
alternates in the DODAG. The packet is also copied to all the registered
children, except for the one that passed the packet. Finally, if there
is a listener in the external infrastructure then the DODAG root has to
further propagate the packet into the external infrastructure.</t>
<t>As a result, the DODAG Root acts as an automatic proxy Rendezvous
Point for the RPL network, and as source towards the non-RPL domain for
all multicast flows started in the RPL domain. So regardless of whether
the root is actually attached to a non-RPL domain, and regardless of
whether the DODAG is grounded or floating, the root can serve inner
multicast streams at all times.</t>
</section>
<section anchor="MaintenanceRoutingAdjacency"
title="Maintenance of Routing Adjacency">
<t>The selection of successors, along the default paths Up along the
DODAG, or along the paths learned from destination advertisements Down
along the DODAG, leads to the formation of routing adjacencies that
require maintenance.</t>
<t>In IGPs such as OSPF <xref target="RFC4915"></xref> or IS-IS <xref
target="RFC5120"></xref>, the maintenance of a routing adjacency
involves the use of Keepalive mechanisms (Hellos) or other protocols
such as BFD (<xref target="RFC5880"></xref>) and MANET Neighborhood
Discovery Protocol (NHDP <xref target="I-D.ietf-manet-nhdp"></xref>).
Unfortunately, such an approach is not desirable in constrained
environments such as LLN and would lead to excessive control traffic in
light of the data traffic with a negative impact on both link loads and
nodes resources. Overhead to maintain the routing adjacency should be
minimized. Furthermore, it is not always possible to rely on the link or
transport layer to provide information of the associated link state. The
network layer needs to fall back on its own mechanism.</t>
<t>Thus RPL makes use of a different approach consisting of probing the
neighbor using a Neighbor Solicitation message (see <xref
target="RFC4861"></xref>). The reception of a Neighbor Advertisement
(NA) message with the "Solicited Flag" set is used to verify the
validity of the routing adjacency. Such mechanism MAY be used prior to
sending a data packet. This allows for detecting whether or not the
routing adjacency is still valid, and should it not be the case, select
another feasible successor to forward the packet. Under specific
circumstances and according to the network resources, a RPL
implementation MAY decide to augment this mechanism with Keep-Alive
messages.</t>
</section>
<section anchor="OFGuide" title="Guidelines for Objective Functions">
<t>An Objective Function (OF), in conjunction with routing metrics and
constraints, allows for the selection of a DODAG to join, and a number
of peers in that DODAG as parents. The OF is used to compute an ordered
list of parents. The OF is also responsible to compute the rank of the
device within the DODAG Version.</t>
<t>The Objective Function is indicated in the DIO message using an
Objective Code Point (OCP), and indicates the method that must be used
to construct the DODAG. The Objective Code Points are specified in <xref
target="I-D.ietf-roll-of0"></xref>, and related companion
specifications.</t>
<section title="Objective Function Behavior">
<t>Most Objective Functions are expected to follow the same abstract
behavior: <list style="symbols">
<t>The parent selection is triggered each time an event indicates
that a potential next hop information is updated. This might
happen upon the reception of a DIO message, a timer elapse, all
DODAG parents are unavailable, or a trigger indicating that the
state of a candidate neighbor has changed.</t>
<!-- CUT? 'Finally an interface...' -->
<t>An OF scans all the interfaces on the device. Although there
may typically be only one interface in most application scenarios,
there might be multiple of them and an interface might be
configured to be usable or not for RPL operation. An interface can
also be configured with a preference or dynamically learned to be
better than another by some heuristics that might be link-layer
dependent and are out of scope. Finally an interface might or not
match a required criterion for an Objective Function, for instance
a degree of security. As a result, some interfaces might be
completely excluded from the computation, for example if those
interfaces cannot satisfy some advertised constraints, while
others might be more or less preferred.</t>
<t>An OF scans all the candidate neighbors on the possible
interfaces to check whether they can act as a router for a DODAG.
There might be multiple of them and a candidate neighbor might
need to pass some validation tests before it can be used. In
particular, some link layers require experience on the activity
with a router to enable the router as a next hop.</t>
<t>An OF computes self's rank by adding to the rank of the
candidate a value representing the relative locations of self and
the candidate in the DODAG Version.<list style="symbols">
<t>The increase in rank must be at least
MinHopRankIncrease.</t>
<t>To keep loop avoidance and metric optimization in
alignment, the increase in rank should reflect any increase in
the metric value. For example, with a purely additive metric
such as ETX, the increase in rank can be made proportional to
the increase in the metric.</t>
<t>Candidate neighbors that would cause self's rank to
increase are not considered for parent selection.</t>
</list></t>
<t>Candidate neighbors that advertise an OF incompatible with the
set of OF specified by the policy functions are ignored.</t>
<t>As it scans all the candidate neighbors, the OF keeps the
current best parent and compares its capabilities with the current
candidate neighbor. The OF defines a number of tests that are
critical to reach the objective. A test between the routers
determines an order relation. <list style="symbols">
<t>If the routers are equal for that relation then the next
test is attempted between the routers,</t>
<t>Else the best of the two routers becomes the current best
parent and the scan continues with the next candidate
neighbor.</t>
<t>Some OFs may include a test to compare the ranks that would
result if the node joined either router.</t>
</list></t>
<t>When the scan is complete, the preferred parent is elected and
self's rank is computed as the preferred parent rank plus the step
in rank with that parent.</t>
<t>Other rounds of scans might be necessary to elect alternate
parents. In the next rounds: <list style="symbols">
<t>Candidate neighbors that are not in the same DODAG are
ignored.</t>
<t>Candidate neighbors that are of greater rank than self are
ignored.</t>
<t>Candidate neighbors of an equal rank to self are ignored
for parent selection.</t>
<t>Candidate neighbors of a lesser rank than self are
preferred.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="NDGuide"
title="Suggestions for Interoperation with Neighbor Discovery">
<t>This specification directly borrows the Prefix Information Option
(PIO) and the Routing Information Option (RIO) from IPv6 ND. It is
envisioned that, as future specifications build on this base, there may
be additional cause to leverage parts of IPv6 ND. This section provides
some suggestions for future specifications.</t>
<t>First and foremost RPL is a routing protocol. One should take great
care to preserve architecture when mapping functionalities between RPL
and ND. RPL is for routing only. That said, there may be persuading
technical reasons to allow for sharing options between RPL and IPv6 ND
in a particular implementation/deployment.</t>
<t>In general the following guidelines apply: <list style="symbols">
<t>RPL Type codes must be allocated from the RPL Control Message
Options registry.</t>
<t>RPL Length fields must be expressed in units of single octets, as
opposed to ND Length fields which are expressed in units of 8
octets.</t>
<t>RPL Options are generally not required to be aligned to 8 octet
boundaries.</t>
<t>When mapping/transposing an IPv6 ND option for redistribution as
a RPL option, any padding octets should be removed when possible.
For example, the Prefix Length field in the PIO is sufficient to
describe the length of the Prefix field. When mapping/transposing a
RPL option for redistribution as an IPv6 ND option, any such padding
octets should be restored. This procedure must be unambiguous.</t>
</list></t>
</section>
<section title="RPL Constants and Variables">
<t>Following is a summary of RPL constants and variables:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="BASE_RANK">This is the rank for a virtual root that
might be used to coordinate multiple roots. BASE_RANK has a value of
0.</t>
<t hangText="ROOT_RANK">This is the rank for a DODAG root. ROOT_RANK
has a value of MinHopRankIncrease (as advertised by the DODAG root),
such that DAGRank(ROOT_RANK) is 1.</t>
<t hangText="INFINITE_RANK">This is the constant maximum for the
rank. INFINITE_RANK has a value of 0xFFFF.</t>
<t hangText="RPL_DEFAULT_INSTANCE">This is the RPLInstanceID that is
used by this protocol by a node without any overriding policy.
RPL_DEFAULT_INSTANCE has a value of 0.</t>
<t hangText="DEFAULT_PATH_CONTROL_SIZE">This is the default value
used to configure PCS in the DODAG Configuration Option, which
dictates the number of significant bits in the Path Control field of
the Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a
value of 0. This configures the simplest case limiting the fan-out
to 1 and limiting a node to send a DAO message to only one
parent.</t>
<t hangText="DEFAULT_DIO_INTERVAL_MIN">This is the default value
used to configure Imin for the DIO trickle timer.
DEFAULT_DIO_INTERVAL_MIN has a value of 3. This configuration
results in Imin of 8ms.</t>
<t hangText="DEFAULT_DIO_INTERVAL_DOUBLINGS">This is the default
value used to configure Imax for the DIO trickle timer.
DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This configuration
results in a maximum interval of 2.3 hours.</t>
<t hangText="DEFAULT_DIO_REDUNDANCY_CONSTANT">This is the default
value used to configure k for the DIO trickle timer.
DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This
configuration is a conservative value for trickle suppression
mechanism.</t>
<t hangText="DEFAULT_MIN_HOP_RANK_INCREASE">This is the default
value of MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a
value of 256. This configuration results in an 8-bit wide integer
part of Rank.</t>
<t hangText="DIO Timer">One instance per DODAG that a node is a
member of. Expiry triggers DIO message transmission. Trickle timer
with variable interval in [0,
DIOIntervalMin..2^DIOIntervalDoublings]. See <xref
target="TrickleParameters"></xref></t>
<t hangText="DAG Version Increment Timer">Up to one instance per
DODAG that the node is acting as DODAG root of. May not be supported
in all implementations. Expiry triggers increment of
DODAGVersionNumber, causing a new series of updated DIO message to
be sent. Interval should be chosen appropriate to propagation time
of DODAG and as appropriate to application requirements (e.g.
response time vs. overhead).</t>
<t hangText="DelayDAO Timer">Up to one timer per DAO parent (the
subset of DODAG parents chosen to receive destination
advertisements) per DODAG. Expiry triggers sending of DAO message to
the DAO parent. See <xref target="ScheduleDAO"></xref></t>
<t hangText="RemoveTimer">Up to one timer per DAO entry per neighbor
(i.e. those neighbors that have given DAO messages to this node as a
DODAG parent) Expiry may trigger No-Path advertisements or
immediately deallocate the DAO entry if there are no DAO
parents.</t>
</list></t>
</section>
<section anchor="Manageability" title="Manageability Considerations">
<t>The aim of this section is to give consideration to the manageability
of RPL, and how RPL will be operated in a LLN. The scope of this section
is to consider the following aspects of manageability: configuration,
monitoring, fault management, accounting, and performance of the
protocol in light of the recommendations set forth in <xref
target="RFC5706"></xref>.</t>
<section title="Introduction">
<t>Most of the existing IETF management standards are Structure of
Management Information (SMI) based data models (MIB modules) to
monitor and manage networking devices.</t>
<t>For a number of protocols, the IETF community has used the IETF
Standard Management Framework, including the Simple Network Management
Protocol <xref target="RFC3410"></xref>, the Structure of Management
Information <xref target="RFC2578"></xref>, and MIB data models for
managing new protocols.</t>
<t>As pointed out in <xref target="RFC5706"></xref>, the common policy
in terms of operation and management has been expanded to a policy
that is more open to a set of tools and management protocols rather
than strictly relying on a single protocol such as SNMP.</t>
<t>In 2003, the Internet Architecture Board (IAB) held a workshop on
Network Management <xref target="RFC3535"></xref> that discussed the
strengths and weaknesses of some IETF network management protocols and
compared them to operational needs, especially configuration.</t>
<t>One issue discussed was the user-unfriendliness of the binary
format of SNMP <xref target="RFC3410"></xref>. In the case of LLNs, it
must be noted that at the time of writing, the CoRE Working Group is
actively working on resource management of devices in LLNs. Still, it
is felt that this section provides important guidance on how RPL
should be deployed, operated, and managed.</t>
<t>As stated in <xref target="RFC5706"></xref>, "A management
information model should include a discussion of what is manageable,
which aspects of the protocol need to be configured, what types of
operations are allowed, what protocol-specific events might occur,
which events can be counted, and for which events an operator should
be notified". These aspects are discussed in detail in the following
sections.</t>
<t>RPL will be used on a variety of devices that may have resources
such as memory varying from a few Kbytes to several hundreds of Kbytes
and even Mbytes. When memory is highly constrained, it may not be
possible to satisfy all the requirements listed in this section. Still
it is worth listing all of these in an exhaustive fashion, and
implementers will then determine which of these requirements could be
satisfied according to the available resources on the device.</t>
</section>
<section title="Configuration Management">
<t>This section discusses the configuration management, listing the
protocol parameters for which configuration management is
relevant.</t>
<t>Some of the RPL parameters are optional. The requirements for
configuration are only applicable for the options that are used.</t>
<section title="Initialization Mode">
<t>"Architectural Principles of the Internet" <xref
target="RFC1958"></xref>, Section 3.8, states: "Avoid options and
parameters whenever possible. Any options and parameters should be
configured or negotiated dynamically rather than manually. This is
especially true in LLNs where the number of devices may be large and
manual configuration is infeasible. This has been taken into account
in the design of RPL whereby the DODAG root provides a number of
parameters to the devices joining the DODAG, thus avoiding
cumbersome configuration on the routers and potential sources of
misconfiguration (e.g. values of trickle timers, ...). Still there
are additional RPL parameters that a RPL implementation should allow
to be configured, which are discussed in this section.</t>
<section title="DIS mode of operation upon boot-up">
<t>When a node is first powered up:<list style="numbers">
<t>The node may decide to stay silent, waiting to receive DIO
messages from DODAG of interest (advertising a supported OF
and metrics/constraints) and not send any multicast DIO
messages until it has joined a DODAG.</t>
<t>The node may decide to send one or more DIS messages
(optionally requesting DIO for a specific DODAG) as an
initial probe for nearby DODAGs, and in the absence of DIO
messages in reply after some configurable period of time, the
node may decide to root a floating DODAG and start sending
multicast DIO messages.</t>
</list></t>
<t>A RPL implementation SHOULD allow configuring the preferred
mode of operation listed above along with the required parameters
(in the second mode: the number of DIS messages and related
timer).</t>
</section>
</section>
<section title="DIO and DAO Base Message and Options Configuration">
<t>RPL specifies a number of protocol parameters considering the
large spectrum of applications where it will be used. That said,
particular attention has been given to limiting the number of these
parameters that must be configured on each RPL router. Instead, a
number of the default values can be used, and when required these
parameters can be provided by the DODAG root thus allowing for
dynamic parameter setting.</t>
<t>A RPL implementation SHOULD allow configuring the following
routing protocol parameters. As pointed out above, note that a large
set of parameters is configured on the DODAG root.</t>
</section>
<section title="Protocol Parameters to be configured on every router in the LLN">
<t>A RPL implementation MUST allow configuring the following RPL
parameters:</t>
<t><list style="symbols">
<t>RPLInstanceID [DIO message, in DIO base message]. Although
the RPLInstanceID must be configured on the DODAG root, it must
also be configured as a policy on every node in order to
determine whether or not the node should join a particular
DODAG. Note that a second RPLInstance can be configured on the
node, should it become root of a floating DODAG.</t>
<t>List of supported Objective Code Points (OCPs)</t>
<t>List of supported metrics: <xref
target="I-D.ietf-roll-routing-metrics"></xref> specifies a
number of metrics and constraints used for the DODAG formation.
Thus a RPL implementation should allow configuring the list of
metrics that a node can accept and understand. If a DIO is
received with a metric and/or constraint that is not understood
or supported, as specified in <xref
target="OperationAsALeaf"></xref>, the node would join as a leaf
node.</t>
<t>Prefix information, along with valid and preferred lifetime
and the L and A flags. [DIO message, Prefix Information option].
A RPL implementation SHOULD allow configuring if the Prefix
Information Option must be carried with the DIO message to
distribute the prefix information for auto-configuration. In
that case, the RPL implementation MUST allow the list of
prefixes to be advertised in the Prefix Information Option along
with the corresponding flags.</t>
<t>Solicited Information [DIS message, in Solicited Information
option]. Note that an RPL implementation SHOULD allow
configuring when such messages should be sent and under which
circumstances, along with the value of the RPLInstance ID, V/I/D
flags.</t>
<t>'K' flag: when a node should set the 'K' flag in a DAO
message [DAO message, in DAO base message].</t>
<t>MOP (Mode of Operation) [DIO message, in DIO base
message].</t>
<t>Route Information (and preference) [DIO message, in Route
Information option]</t>
</list></t>
</section>
<section title="Protocol Parameters to be configured on every non-DODAG-root router in the LLN">
<t>A RPL implementation MUST allow configuring the Target prefix
[DAO message, in RPL Target option].</t>
<t>Furthermore, there are circumstances where a node may want to
designate a Target to allow for specific processing of the Target
(prioritization, ...). Such processing rules are out of the scope of
this document. When used, a RPL implementation SHOULD allow
configuring the Target Descriptor on a per-Target basis (for example
using access lists).</t>
<t>A node whose DODAG parent set is empty may become the DODAG root
of a floating DODAG. It may also set its DAGPreference such that it
is less preferred. Thus a RPL implementation MUST allow configuring
the set of actions that the node should initiate in this case:</t>
<t><list style="symbols">
<t>Start its own (floating) DODAG: the new DODAGID must be
configured in addition to its DAGPreference.</t>
<t>Poison the broken path (see procedure in <xref
target="DAGDiscoveryRulesPoison"></xref>).</t>
<t>Trigger a local repair.</t>
</list></t>
</section>
<section title="Parameters to be configured on the DODAG root">
<t>In addition, several other parameters are configured only on the
DODAG root and advertised in options carried in DIO messages.</t>
<t>As specified in <xref target="DIOTransmission"></xref>, a RPL
implementation makes use of trickle timers to govern the sending of
DIO messages. The operation of the trickle algorithm is determined
by a set of configurable parameters, which MUST be configurable and
that are then advertised by the DODAG root along the DODAG in DIO
messages.</t>
<t><list style="symbols">
<t>DIOIntervalDoublings [DIO message, in DODAG configuration
option]</t>
<t>DIOIntervalMin [DIO message, in DODAG configuration
option]</t>
<t>DIORedundancyConstant [DIO message, in DODAG configuration
option]</t>
</list></t>
<t>In addition, a RPL implementation SHOULD allow for configuring
the following set of RPL parameters:</t>
<t><list style="symbols">
<t>Path Control Size [DIO message, in DODAG configuration
option]</t>
<t>MinHopRankIncrease [DIO message, in DODAG configuration
option]</t>
<t>The DODAGPreference field [DIO message, DIO Base object]</t>
<t>DODAGID [DIO message, in DIO base option] and [DAO message,
when the 'D' flag of the DAO message is set]</t>
</list></t>
<t>DAG Root behavior: in some cases, a node may not want to
permanently act as a floating DODAG root if it cannot join a
grounded DODAG. For example a battery-operated node may not want to
act as a floating DODAG root for a long period of time. Thus a RPL
implementation MAY support the ability to configure whether or not a
node could act as a floating DODAG root for a configured period of
time.</t>
<t>DAG Version Number Increment: a RPL implementation may allow by
configuration at the DODAG root to refresh the DODAG states by
updating the DODAGVersionNumber. A RPL implementation SHOULD allow
configuring whether or not periodic or event triggered mechanisms
are used by the DODAG root to control DODAGVersionNumber change
(which triggers a global repair as specified in <xref
target="DODAGRepair"></xref>.</t>
</section>
<section title="Configuration of RPL Parameters related to DAO-based mechanisms">
<t>DAO messages are optional and used in DODAGs that require
downward routing operation. This section deals with the set of
parameters related to DAO message and provides recommendations on
their configuration.</t>
<t>As stated in <xref target="ScheduleDAO"></xref>, it is
recommended to delay the sending of DAO message to DAO parents in
order to maximize the chances to perform route aggregation. Upon
receiving a DAO message, the node should thus start a DelayDAO
timer. A RPL implementation MAY allow for configuring the DelayDAO
timer.</t>
<t>In a storing mode of operation, a storing node may increment DTSN
in order to reliably trigger a set of DAO updates from its immediate
children, as part of routine routing table updates and maintenance.
A RPL implementation MAY allow for configuring a set of rules
specifying the triggers for DTSN increment (manual or
event-based).</t>
<!-- OBSOLETE : FSM removed
<t>An implementation SHOULD bound the time that the entry is
allocated in the UNREACHABLE state. Upon the equivalent expiry of
the related timer (RemoveTimer), the entry SHOULD be suppressed.
Thus a RPL implementation MAY allow for the configuration of the
RemoveTimer.</t>
-->
<t>When a DAO entry times out or is invalidated, a node SHOULD make
a reasonable attempt to report a No-Path to each of the DAO parents.
That number of attempts MAY be configurable.</t>
<!-- OBSOLETE : FSM removed
<t>When the associated Retry Counter for a REACHABLE(Pending) entry
reaches a maximum threshold, the entry is placed into the
UNREACHABLE state and No-Path should be scheduled to send to the
node's DAO Parents. The maximum threshold MAY be configurable.</t>
-->
<t>An implementation should support rate-limiting the sending of DAO
messages. The related parameters MAY be configurable.</t>
<!--
<t>A RPL implementation SHOULD allow for the configuration of the "Route Tag" field of the DAO messages.</t>
-->
</section>
<section title="Default Values">
<t>This document specifies default values for the following set of
RPL variables: <?rfc subcompact="yes"?><list>
<t>DEFAULT_PATH_CONTROL_SIZE</t>
<t>DEFAULT_DIO_INTERVAL_MIN</t>
<t>DEFAULT_DIO_INTERVAL_DOUBLINGS</t>
<t>DEFAULT_DIO_REDUNDANCY_CONSTANT</t>
<t>DEFAULT_MIN_HOP_RANK_INCREASE</t>
</list><?rfc subcompact="no"?></t>
<t>It is recommended to specify default values in protocols; that
being said, as discussed in <xref target="RFC5706"></xref>, default
values may make less and less sense. RPL is a routing protocol that
is expected to be used in a number of contexts where network
characteristics such as the number of nodes, link and nodes types
are expected to vary significantly. Thus, these default values are
likely to change with the context and as the technology will evolve.
Indeed, LLNs' related technology (e.g. hardware, link layers) have
been evolving dramatically over the past few years and such
technologies are expected to change and evolve considerably in the
coming years.</t>
<t>The proposed values are not based on extensive best current
practices and are considered to be conservative.</t>
</section>
</section>
<section title="Monitoring of RPL Operation">
<t>Several RPL parameters should be monitored to verify the correct
operation of the routing protocol and the network itself. This section
lists the set of monitoring parameters of interest.</t>
<section title="Monitoring a DODAG parameters">
<t>A RPL implementation SHOULD provide information about the
following parameters:</t>
<t><list style="symbols">
<t>DODAG Version number [DIO message, in DIO base message]</t>
<t>Status of the G flag [DIO message, in DIO base message]</t>
<t>Status of the MOP field [DIO message, in DIO base
message]</t>
<t>Value of the DTSN [DIO message, in DIO base message]</t>
<t>Value of the rank [DIO message, in DIO base message]</t>
<t>DAOSequence: Incremented at each unique DAO message, echoed
in the DAO-ACK message [DAO and DAO-ACK messages]</t>
<t>Route Information [DIO message, Route Information option]
(list of IPv6 prefixes per parent along with lifetime and
preference]</t>
<t>Trickle parameters: <list style="symbols">
<t>DIOIntervalDoublings [DIO message, in DODAG configuration
option]</t>
<t>DIOIntervalMin [DIO message, in DODAG configuration
option]</t>
<t>DIORedundancyConstant [DIO message, in DODAG
configuration option]</t>
</list></t>
<t>Path Control Size [DIO message, in DODAG configuration
option]</t>
<t>MinHopRankIncrease [DIO message, in DODAG configuration
option]</t>
</list></t>
<t>Values that may be monitored only on the DODAG root</t>
<t><list style="symbols">
<t>Transit Information [DAO, Transit Information option]: A RPL
implementation SHOULD allow configuring whether the set of
received Transit Information options should be displayed on the
DODAG root. In this case, the RPL database of received Transit
Information should also contain: the path-sequence, path
control, path lifetime and parent address.</t>
</list></t>
</section>
<section title="Monitoring a DODAG inconsistencies and loop detection">
<t>Detection of DODAG inconsistencies is particularly critical in
RPL networks. Thus it is recommended for a RPL implementation to
provide appropriate monitoring tools. A RPL implementation SHOULD
provide a counter reporting the number of a times the node has
detected an inconsistency with respect to a DODAG parent, e.g. if
the DODAGID has changed.</t>
<t>When possible more granular information about inconsistency
detection should be provided. A RPL implementation MAY provide
counters reporting the number of following inconsistencies:</t>
<t><list style="symbols">
<t>Packets received with 'O' bit set (to Down) from a node with
a higher rank</t>
<t>Packets received with 'O' bit cleared (to Up) from a node
with a lower rank</t>
<t>Number of packets with the 'F' bit set</t>
<t>Number of packets with the 'R' bit set</t>
</list></t>
</section>
</section>
<section title="Monitoring of the RPL data structures">
<section title="Candidate Neighbor Data Structure">
<t>A node in the candidate neighbor list is a node discovered by the
some means and qualified to potentially become a parent (with high
enough local confidence). A RPL implementation SHOULD provide a way
to monitor the candidate neighbor list with some metric reflecting
local confidence (the degree of stability of the neighbors) as
measured by some metrics.</t>
<t>A RPL implementation MAY provide a counter reporting the number
of times a candidate neighbor has been ignored, should the number of
candidate neighbors exceeds the maximum authorized value.</t>
</section>
<section title="Destination Oriented Directed Acyclic Graph (DAG) Table">
<t>For each DODAG, a RPL implementation is expected to keep track of
the following DODAG table values:</t>
<t><list style="symbols">
<t>RPLInstanceID</t>
<t>DODAGID</t>
<t>DODAGVersionNumber</t>
<t>Rank</t>
<t>Objective Code Point</t>
<t>A set of DODAG Parents</t>
<t>A set of prefixes offered upwards along the DODAG</t>
<t>Trickle timers used to govern the sending of DIO messages for
the DODAG</t>
<t>List of DAO parents</t>
<t>DTSN</t>
<t>Node status (router versus leaf)</t>
</list></t>
<t>A RPL implementation SHOULD allow for monitoring the set of
parameters listed above.</t>
</section>
<section title="Routing Table and DAO Routing Entries">
<t>A RPL implementation maintains several information elements
related to the DODAG and the DAO entries (for storing nodes). In the
case of a non storing node, a limited amount of information is
maintained (the routing table is mostly reduced to a set of DODAG
parents along with characteristics of the DODAG as mentioned above)
whereas in the case of storing nodes, this information is augmented
with routing entries.</t>
<t>A RPL implementation SHOULD provide the ability to monitor the
following parameters:</t>
<t><list style="symbols">
<t>Next Hop (DODAG parent)</t>
<t>Next Hop Interface</t>
<t>Path metrics value for each DODAG parent</t>
</list></t>
<t>A DAO Routing Table Entry conceptually contains the following
elements (for storing nodes only):</t>
<t><list style="symbols">
<t>Advertising Neighbor Information</t>
<t>IPv6 Address</t>
<t>Interface ID to which DAO Parents has this entry been
reported</t>
<t>Retry Counter</t>
<t>Logical equivalent of DAO Content: <list style="symbols">
<t>DAO-Sequence</t>
<t>Path Sequence</t>
<t>DAO Lifetime</t>
<t>DAO Path Control</t>
</list></t>
<t>Destination Prefix (or Address or Mcast Group)</t>
</list></t>
<t>A RPL implementation SHOULD provide information about the state
of each DAO Routing Table entry states.</t>
</section>
</section>
<section anchor="mgmtFault" title="Fault Management">
<t>Fault management is a critical component used for troubleshooting,
verification of the correct mode of operation of the protocol, network
design, and is also a key component of network performance monitoring.
A RPL implementation SHOULD allow providing the following information
related to fault managements:</t>
<t><list style="symbols">
<t>Memory overflow along with the cause (e.g. routing tables
overflow, ...)</t>
<t>Number of times a packet could not be sent to a DODAG parent
flagged as valid</t>
<t>Number of times a packet has been received for which the router
did not have a corresponding RPLInstanceID</t>
<t>Number of times a local repair procedure was triggered</t>
<t>Number of times a global repair was triggered by the DODAG
root</t>
<t>Number of received malformed messages</t>
<t>Number of seconds with packets to forward and no next hop
(DODAG parent)</t>
<t>Number of seconds without next hop (DODAG parent)</t>
<t>Number of times a node has joined a DODAG as a leaf because it
received a DIO with metric/constraint not understood and it was
configured to join as a leaf node in this case (see <xref
target="mgmtPolicy"></xref>).</t>
</list></t>
<t>It is RECOMMENDED to report faults via at least error log messages.
Other protocols may be used to report such faults.</t>
</section>
<section anchor="mgmtPolicy" title="Policy">
<t>Policy rules can be used by a RPL implementation to determine
whether or not the node is allowed to join a particular DODAG
advertised by a neighbor by means of DIO messages.</t>
<t>This document specifies operation within a single DODAG. A DODAG is
characterized by the following tuple (RPLInstanceID, DODAGID).
Furthermore, as pointed out above, DIO messages are used to advertise
other DODAG characteristics such as the routing metrics and
constraints used to build to the DODAG and the Objective Function in
use (specified by OCP).</t>
<t>The first policy rules consist of specifying the following
conditions that a RPL node must satisfy to join a DODAG:</t>
<t><list style="symbols">
<t>RPLInstanceID</t>
<t>List of supported routing metrics and constraints</t>
<t>Objective Function (OCP values)</t>
</list></t>
<t>A RPL implementation MUST allow configuring these parameters and
SHOULD specify whether the node must simply ignore the DIO if the
advertised DODAG is not compliant with the local policy or whether the
node should join as the leaf node if only the list of supported
routing metrics and constraints, and the OF is not supported.
Additionally a RPL implementation SHOULD allow for the addition of the
DODAGID as part of the policy.</t>
<t>A RPL implementation SHOULD allow configuring the set of acceptable
or preferred Objective Functions (OF) referenced by their Objective
Codepoints (OCPs) for a node to join a DODAG, and what action should
be taken if none of a node's candidate neighbors advertise one of the
configured allowable Objective Functions, or if the advertised
metrics/constraint is not understood/supported. Two actions can be
taken in this case:</t>
<t><list style="symbols">
<t>The node joins the DODAG as a leaf node as specified in <xref
target="OperationAsALeaf"></xref></t>
<t>The node does not join the DODAG</t>
</list></t>
<t>A node in an LLN may learn routing information from different
routing protocols including RPL. It is in this case desirable to
control via administrative preference which route should be favored.
An implementation SHOULD allow for specifying an administrative
preference for the routing protocol from which the route was
learned.</t>
<!--
<t>A RPL implementation SHOULD allow for the configuration of the "Route Tag" field of the DAO messages and SHOULD define the related policy.</t> -->
<t>Internal Data Structures: some RPL implementations may limit the
size of the candidate neighbor list in order to bound the memory
usage, in which case some otherwise viable candidate neighbors may not
be considered and simply dropped from the candidate neighbor list.</t>
<t>A RPL implementation MAY provide an indicator on the size of the
candidate neighbor list.</t>
</section>
<section title="Liveness Detection and Monitoring">
<t>By contrast with several other routing protocols, RPL does not
define any 'keep-alive' mechanisms to detect routing adjacency
failure: this is in most cases, because such a mechanism may be too
expensive in terms of bandwidth and even more importantly energy (a
battery operated device could not afford to send periodic Keep alive).
Still RPL requires mechanisms to detect that a neighbor is no longer
reachable: this can be performed by using mechanisms such as NUD
(Neighbor Unreachability Detection) or even some form of Keep-alive
that are outside of this document.</t>
</section>
<section title="Fault Isolation">
<t>It is RECOMMENDED to quarantine neighbors that start emitting
malformed messages at unacceptable rates.</t>
</section>
<section title="Impact on Other Protocols">
<t>RPL has very limited impact on other protocols. Where more than one
routing protocol is required on a router such as a LBR, it is expected
for the device to support routing redistribution functions between the
routing protocols to allow for reachability between the two routing
domains. Such redistribution SHOULD be governed by the use of user
configurable policy.</t>
<t>With regards to the impact in terms of traffic on the network, RPL
has been designed to limit the control traffic thanks to mechanisms
such as Trickle timers (<xref target="DIOTransmission"></xref>). Thus
the impact of RPL on other protocols should be extremely limited.</t>
</section>
<section title="Performance Management">
<t>Performance management is always an important aspect of a protocol
and RPL is not an exception. Several metrics of interest have been
specified by the IP Performance Monitoring (IPPM) Working Group: that
being said, they will be hardly applicable to LLN considering the cost
of monitoring these metrics in terms of resources on the devices and
required bandwidth. Still, RPL implementation MAY support some of
these, and other parameters of interest are listed below:</t>
<t><list style="symbols">
<t>Number of repairs and time to repair in seconds (average,
variance)</t>
<t>Number of times and duration during which a devices could not
forward a packet because of a lack of reachable neighbor in its
routing table</t>
<t>Monitoring of resources consumption by RPL itself in terms of
bandwidth and required memory</t>
<t>Number of RPL control messages sent and received</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Overview">
<t>From a security perspective, RPL networks are no different from any
other network. They are vulnerable to passive eavesdropping attacks
and potentially even active tampering when physical access to a wire
is not required to participate in communications. The very nature of
ad hoc networks and their cost objectives impose additional security
constraints, which perhaps make these networks the most difficult
environments to secure. Devices are low-cost and have limited
capabilities in terms of computing power, available storage, and power
drain; and it cannot always be assumed they have neither a trusted
computing base nor a high-quality random number generator aboard.
Communications cannot rely on the online availability of a fixed
infrastructure and might involve short-term relationships between
devices that may never have communicated before. These constraints
might severely limit the choice of cryptographic algorithms and
protocols and influence the design of the security architecture
because the establishment and maintenance of trust relationships
between devices need to be addressed with care. In addition, battery
lifetime and cost constraints put severe limits on the security
overhead these networks can tolerate, something that is of far less
concern with higher bandwidth networks. Most of these security
architectural elements can be implemented at higher layers and may,
therefore, be considered to be outside the scope of this standard.
Special care, however, needs to be exercised with respect to
interfaces to these higher layers.</t>
<t>The security mechanisms in this standard are based on symmetric-key
and public-key cryptography and use keys that are to be provided by
higher layer processes. The establishment and maintenance of these
keys are outside the scope of this standard. The mechanisms assume a
secure implementation of cryptographic operations and secure and
authentic storage of keying material.</t>
<t>The security mechanisms specified provide particular combinations
of the following security services:</t>
<t><list hangIndent="12" style="hanging">
<t hangText="Data confidentiality:">Assurance that transmitted
information is only disclosed to parties for which it is
intended.</t>
<t hangText="Data authenticity:">Assurance of the source of
transmitted information (and, hereby, that information was not
modified in transit).</t>
<t hangText="Replay protection:">Assurance that a duplicate of
transmitted information is detected.</t>
<t hangText="Timeliness (delay protection):">Assurance that
transmitted information was received in a timely manner.</t>
</list></t>
<t>The actual protection provided can be adapted on a per-packet basis
and allows for varying levels of data authenticity (to minimize
security overhead in transmitted packets where required) and for
optional data confidentiality. When nontrivial protection is required,
replay protection is always provided.</t>
<t>Replay protection is provided via the use of a non-repeating value
(nonce) in the packet protection process and storage of some status
information for each originating device on the receiving device, which
allows detection of whether this particular nonce value was used
previously by the originating device. In addition, so-called delay
protection is provided amongst those devices that have a loosely
synchronized clock on board. The acceptable time delay can be adapted
on a per-packet basis and allows for varying latencies (to facilitate
longer latencies in packets transmitted over a multi-hop communication
path).</t>
<t>Cryptographic protection may use a key shared between two peer
devices (link key) or a key shared among a group of devices (group
key), thus allowing some flexibility and application-specific
tradeoffs between key storage and key maintenance costs versus the
cryptographic protection provided. If a group key is used for
peer-to-peer communication, protection is provided only against
outsider devices and not against potential malicious devices in the
key-sharing group.</t>
<t>Data authenticity may be provided using symmetric-key based or
public-key based techniques. With public-key based techniques (via
signatures), one corroborates evidence as to the unique originator of
transmitted information, whereas with symmetric-key based techniques
data authenticity is only provided relative to devices in a
key-sharing group. Thus, public-key based authentication may be useful
in scenarios that require a more fine-grained authentication than can
be provided with symmetric-key based authentication techniques alone,
such as with group communications (broadcast, multicast), or in
scenarios that require non-repudiation.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="RPL Control Message">
<t>The RPL Control Message is an ICMP information message type that is
to be used carry DODAG Information Objects, DODAG Information
Solicitations, and Destination Advertisement Objects in support of RPL
operation.</t>
<t>IANA has defined an ICMPv6 Type Number Registry. The suggested type
value for the RPL Control Message is 155, to be confirmed by IANA.</t>
</section>
<section anchor="RPLCtrlCodeReg"
title="New Registry for RPL Control Codes">
<t>IANA is requested to create a registry, RPL Control Codes, for the
Code field of the ICMPv6 RPL Control Message.</t>
<t>New codes may be allocated only by an IETF Consensus action. Each
code should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Code</t>
<t>Description</t>
<t>Defining RFC</t>
</list></t>
<t>Three codes are currently defined:</t>
<texttable title="RPL Control Codes">
<ttcol align="center">Code</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0x00</c>
<c>DODAG Information Solicitation</c>
<c>This document</c>
<c>0x01</c>
<c>DODAG Information Object</c>
<c>This document</c>
<c>0x02</c>
<c>Destination Advertisement Object</c>
<c>This document</c>
<c>0x03</c>
<c>Destination Advertisement Object Acknowledgment</c>
<c>This document</c>
<c>0x80</c>
<c>Secure DODAG Information Solicitation</c>
<c>This document</c>
<c>0x81</c>
<c>Secure DODAG Information Object</c>
<c>This document</c>
<c>0x82</c>
<c>Secure Destination Advertisement Object</c>
<c>This document</c>
<c>0x83</c>
<c>Secure Destination Advertisement Object Acknowledgment</c>
<c>This document</c>
</texttable>
</section>
<section title="New Registry for the Mode of Operation (MOP) DIO Control Field">
<t>IANA is requested to create a registry for the Mode of Operation
(MOP) DIO Control Field, which is contained in the DIO Base.</t>
<t>New fields may be allocated only by an IETF Consensus action. Each
field should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Mode of Operation</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>Three values are currently defined:</t>
<texttable title="DIO Mode of operation">
<ttcol align="center">MOP</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>000</c>
<c>No downward routes maintained by RPL</c>
<c>This document</c>
<c>001</c>
<c>Non-Storing mode of operation</c>
<c>This document</c>
<c>010</c>
<c>Storing mode of operation with no multicast support</c>
<c>This document</c>
<c>011</c>
<c>Storing mode of operation with multicast support</c>
<c>This document</c>
</texttable>
</section>
<section anchor="RPLCtrlMsgOptionsReg"
title="RPL Control Message Option">
<t>IANA is requested to create a registry for the RPL Control Message
Options</t>
<texttable title="RPL Control Message Options">
<ttcol align="center">Value</ttcol>
<ttcol align="left">Meaning</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>Pad1</c>
<c>This document</c>
<c>1</c>
<c>PadN</c>
<c>This document</c>
<c>2</c>
<c>DAG Metric Container</c>
<c>This Document</c>
<c>3</c>
<c>Routing Information</c>
<c>This Document</c>
<c>4</c>
<c>DODAG Configuration</c>
<c>This Document</c>
<c>5</c>
<c>RPL Target</c>
<c>This Document</c>
<c>6</c>
<c>Transit Information</c>
<c>This Document</c>
<c>7</c>
<c>Solicited Information</c>
<c>This Document</c>
<c>8</c>
<c>Prefix Information</c>
<c>This Document</c>
<c>9</c>
<c>Target Descriptor</c>
<c>This Document</c>
</texttable>
</section>
<section anchor="OCPReg" title="Objective Code Point (OCP) Registry">
<t>IANA is requested to create a registry to manage the codespace of
the Objective Code Point (OCP) field.</t>
<t>No OCP codepoints are defined in this specification.</t>
</section>
<section anchor="SecSecflggreg"
title="New Registry for the Security Section Flags">
<t>IANA is requested to create a registry for the 8-bit
Security Section Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>No bit is currently defined for the Security Section Flags.</t>
</section>
<section anchor="SecSeckimflggreg"
title="New Registry for the Key Identification Mode">
<t>IANA is requested to create a registry for the 3-bit
Key Identification Mode Field.</t>
<t>New values may be allocated only by an IETF Consensus action.
Each value should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Value</t>
<t>Description</t>
<t>Defining RFC</t>
</list></t>
<t>The following values are currently defined:</t>
<texttable title="Key Identification Mode">
<ttcol align="center">Value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>See <xref target="KIMEncoding"/></c>
<c>This document</c>
<c>1</c>
<c>See <xref target="KIMEncoding"/></c>
<c>This document</c>
<c>2</c>
<c>See <xref target="KIMEncoding"/></c>
<c>This document</c>
<c>3</c>
<c>See <xref target="KIMEncoding"/></c>
<c>This document</c>
</texttable>
</section>
<section anchor="SecSeckimlevelflggreg"
title="New Registry for the KIM levels">
<t>IANA is requested to create one registry for the 7-bit
KIM level Field per allocated KIM value.</t>
<t>For a given KIM value, new levels may be allocated only
by an IETF Consensus action.
Each level should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Level</t>
<t>KIM value</t>
<t>Description</t>
<t>Defining RFC</t>
</list></t>
<t>The following levels pre KIM value are currently defined:</t>
<texttable title=" KIM levels">
<ttcol align="center">Level</ttcol>
<ttcol align="center">KIM value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>0</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>1</c>
<c>0</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>2</c>
<c>0</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>3</c>
<c>0</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>0</c>
<c>1</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>1</c>
<c>1</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>2</c>
<c>1</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>3</c>
<c>1</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>0</c>
<c>2</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>1</c>
<c>2</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>2</c>
<c>2</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>3</c>
<c>2</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>0</c>
<c>3</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
<c>1</c>
<c>3</c>
<c>See <xref target="LVLEncoding"/></c>
<c>This document</c>
</texttable>
</section>
<section anchor="DISflggreg"
title="New Registry for the DIS (DODAG Informational Solicitation) Flags">
<t>IANA is requested to create a registry for the DIS (DODAG
Informational Solicitation) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags.</t>
</section>
<section anchor="DIOflggreg"
title="New Registry for the DODAG Information Object (DIO) Flags">
<t>IANA is requested to create a registry for the 8-bit DODAG
Information Object (DIO) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags.</t>
</section>
<section anchor="DAOflggreg"
title="New Registry for the Destination Advertisement Object (DAO) Flags">
<t>IANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following bits are currently defined:</t>
<texttable title="DAO Base Flags">
<ttcol align="center">Bit number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>DAO-ACK request</c>
<c>This document</c>
<c>1</c>
<c>DODAGID field is present</c>
<c>This document</c>
</texttable>
</section>
<section anchor="DAOackflggreg"
title="New Registry for the Destination Advertisement Object (DAO) Flags">
<t>IANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following bit is currently defined:</t>
<texttable title="DAO-Ack Base Flags">
<ttcol align="center">Bit number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>DODAGID field is present</c>
<c>This document</c>
</texttable>
</section>
<section anchor="CCflggreg"
title="New Registry for the Consistency Check (CC) Flags">
<t>IANA is requested to create a registry for the 8-bit Consistency
Check (CC) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following bit is currently defined:</t>
<texttable title="Consistency Check Base Flags">
<ttcol align="center">Bit number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>CC Response</c>
<c>This document</c>
</texttable>
</section>
<section anchor="DODAGCflggreg"
title="New Registry for the DODAG Configuration Option Flags">
<t>IANA is requested to create a registry for the 8-bit DODAG
Configuration Option Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following bits are currently defined:</t>
<texttable title="DODAG Configuration Option Flags">
<ttcol align="center">Bit number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>4</c>
<c>Authentication Enabled</c>
<c>This document</c>
<c>5-7</c>
<c>Path Control Size</c>
<c>This document</c>
</texttable>
</section>
<section anchor="targetflggreg"
title="New Registry for the RPL Target Option Flags">
<t>IANA is requested to create a registry for the 8-bit RPL Target
Option Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>No bit is currently defined for the RPL Target Option Flags.</t>
</section>
<section anchor="TIOflggreg"
title="New Registry for the Transit Information Option Flags">
<t>IANA is requested to create a registry for the 8-bit Transit
Information Option (RIO) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following bits are currently defined:</t>
<texttable title="Transit Information Option Flags">
<ttcol align="center">Bit number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>External</c>
<c>This document</c>
</texttable>
</section>
<section anchor="SIOflggreg"
title="New Registry for the Solicited Information Option Flags">
<t>IANA is requested to create a registry for the 8-bit Solicited
Information Option (RIO) Flag Field.</t>
<t>New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:</t>
<t><list style="symbols">
<t>Bit number (counting from bit 0 as the most significant
bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<t>The following bits are currently defined:</t>
<texttable title="Solicited Information Option Flags">
<ttcol align="center">Bit number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>Version Predicate match</c>
<c>This document</c>
<c>1</c>
<c>InstanceID Predicate match</c>
<c>This document</c>
<c>2</c>
<c>DODAGID Predicate match</c>
<c>This document</c>
</texttable>
</section>
<section anchor="ICMPv6ErrSrcRte"
title="ICMPv6: Error in Source Routing Header">
<t>In some cases RPL will return an ICMPv6 error message when a
message cannot be delivered as specified by its source routing header.
This ICMPv6 error message is "Error in Source Routing Header".</t>
<t>IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6
Message Types. ICMPv6 Message Type 1 describes "Destination
Unreachable" codes. The "Error in Source Routing Header" code is
suggested to be allocated from the ICMPv6 Code Fields Registry for
ICMPv6 Message Type 1, with a suggested code value of 7, to be
confirmed by IANA.</t>
</section>
<section anchor="Multicastgroup"
title="Link-Local Scope multicast address">
<t>The rules for assigning new IPv6 multicast addresses are defined in
<xref target="RFC3307"></xref>. This specification requires the
allocation of a new permanent multicast address with a link local
scope for RPL nodes called all-RPL-nodes, with a suggested value of
FF02::1A, to be confirmed by IANA.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to acknowledge the review, feedback, and
comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel,
Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Mischa Dohler, Mathilde
Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Mukul Goyal,
Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Ajay Kumar, Quentin
Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, Joseph Reddy,
Michael Richardson, Don Sturek, Joydeep Tripathi, and Nicolas
Tsiftes.</t>
<t>The authors would like to acknowledge the guidance and input provided
by the ROLL Chairs, David Culler and JP Vasseur.</t>
<t>The authors would like to acknowledge prior contributions of Robert
Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Jim
Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom have
provided useful design considerations to RPL.</t>
<t>RPL Security Design, found in <xref
target="SecurityMechanisms"></xref>, <xref target="Security"></xref>,
and elsewhere throughout the document, is primarily the contribution of
the Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
Levis, Kris Pister, and Rene Struik.</t>
</section>
<section title="Contributors">
<t>RPL is the result of the contribution of the following members of the
RPL Author Team, including the editors, and additional contributors as
listed below in alphabetical order:</t>
<figure>
<artwork><![CDATA[
Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen, DK-2100
Denmark
Email: abr@sdesigns.dk
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Stephen Dawson-Haggerty
UC Berkeley
Soda Hall, UC Berkeley
Berkeley, CA 94720
USA
Email: stevedh@cs.berkeley.edu
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, CA 94107
USA
Email: jhui@archrock.com
Richard Kelsey
Ember Corporation
Boston, MA
USA
Phone: +1 617 951 1225
Email: kelsey@ember.com
Philip Levis
Stanford University
358 Gates Hall, Stanford University
Stanford, CA 94305-9030
USA
Email: pal@cs.stanford.edu
Kris Pister
Dust Networks
30695 Huntwood Ave.
Hayward, 94544
USA
Email: kpister@dustnetworks.com
R. Struik
Email: rstruik.ext@gmail.com
JP Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782
France
Email: jpv@cisco.com
]]></artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.3447"?>
<?rfc include="reference.RFC.3775"?>
<?rfc include="reference.RFC.4191"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include='reference.I-D.ietf-roll-routing-metrics.xml'?>
<?rfc include="reference.I-D.ietf-roll-trickle.xml"?>
<?rfc include="reference.I-D.ietf-6man-rpl-option.xml"?>
<?rfc include="reference.I-D.ietf-6man-rpl-routing-header.xml"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5867'?>
<?rfc include='reference.RFC.5673'?>
<?rfc include="reference.RFC.5548"?>
<?rfc include="reference.RFC.5826"?>
<?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
<?rfc include='reference.I-D.ietf-roll-of0.xml'?>
<?rfc include="reference.RFC.3819"?>
<?rfc include="reference.RFC.4101"?>
<?rfc include="reference.RFC.4862"?>
<?rfc include="reference.RFC.4443"?>
<?rfc include="reference.RFC.4915"?>
<?rfc include="reference.RFC.5120"?>
<?rfc include="reference.RFC.1982"?>
<?rfc include='reference.RFC.2710'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.5706'?>
<?rfc include='reference.RFC.3410'?>
<?rfc include='reference.RFC.3610'?>
<?rfc include='reference.RFC.2578'?>
<?rfc include='reference.RFC.3535'?>
<?rfc include='reference.RFC.1958'?>
<?rfc include="reference.RFC.5880"?>
<?rfc include="reference.RFC.3307"?>
<?rfc include="reference.I-D.ietf-manet-nhdp.xml"?>
<reference anchor="Perlman83"
target="http://www.cs.illinois.edu/~pbg/courses/cs598fa09/readings/p83.pdf">
<front>
<title abbrev="Perlman83">Fault-Tolerant Broadcast of Routing
Information</title>
<author fullname="Radia Perlman" initials="R." surname="Perlman">
<organization>Digital Equipment Corp.</organization>
</author>
<date year="1983" />
</front>
<seriesInfo name="North-Holland Computer Networks 7:" value="395-405" />
<format target="http://www.cs.illinois.edu/~pbg/courses/cs598fa09/readings/p83.pdf"
type="HTML" />
</reference>
<reference anchor="sha2" target="">
<front>
<title abbrev="FIPS Pub 180-3">FIPS Pub 180-3, Secure Hash Standard
(SHS)</title>
<author fullname="Federal Information Processing Standards 180-3, US Department of Commerce/National Institute of Standards and Technology"
initials="" surname=""></author>
<date month="February" year="2008" />
</front>
<seriesInfo name="" value="" />
</reference>
<reference anchor="CCMStar" target="">
<front>
<title abbrev="CCM*">IEEE Std. 802.15.4-2006, IEEE Standard for
Information Technology - Telecommunications and Information Exchange
between Systems - Local and Metropolitan Area Networks - Specific
requirements Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)</title>
<author fullname="Institute of Electrical and Electronics Engineers, Inc."
initials="" surname="IEEE"></author>
<date year="2006" />
</front>
<seriesInfo name="IEEE Press"
value="Revision of IEEE Std 802.15.4-2003" />
</reference>
<!--
<reference anchor="X9.92">
<front>
<title abbrev="X9.92">ANSI X9.92, Public Key Cryptography for the
Financial Services Industry - Digital Signature Algorithms Giving
Partial Message Recovery - Part 1: Elliptic Curve Pintsov-Vanstone
Signatures (ECPVS)</title>
<author fullname="American Bankers Association"></author>
<date year="2009" />
</front>
</reference>
<reference anchor="X9.63-2001">
<front>
<title abbrev="X9.63-2001">ANSI X9.63-2001, Public Key Cryptography
for the Financial Services Industry - Key Agreement and Key
Transport Using Elliptic Curve Cryptography</title>
<author fullname="American Bankers Association"></author>
<date year="2001" />
</front>
</reference>
<reference anchor="AppliedCryptography">
<front>
<title abbrev="AppliedCryptography">Handbook of Applied
Cryptography</title>
<author fullname="A. J. Menzes" initials="AJ" surname="Menzes"></author>
<author fullname="P. C. van Oorschot" initials="PC"
surname="van Oorschot"></author>
<author fullname="S. A. Vanstone" initials="SA" surname="Vanstone"></author>
<date year="1997" />
</front>
<seriesInfo name="CRC Press" value="" />
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:59:48 |