One document matched: draft-ietf-roll-rpl-09.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="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="std" docName="draft-ietf-roll-rpl-09" ipr="trust200902">
<front>
<title abbrev="draft-ietf-roll-rpl-09">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="11" month="Jun" 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). 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="I-D.ietf-roll-building-routing-reqs"></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="I-D.ietf-roll-building-routing-reqs"></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 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 edges. 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="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 identifies its distance from 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). Rank can be a
simple topological distance, may be calculated as a function of link
metrics, and may consider other properties such as contraints.</t>
<t hangText="Objective Function (OF):">Defines which routing
metrics, optimization objectives, and related functions a DAG uses
to compute Rank.</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.
Two 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
must be 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 sequence number 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 a 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 ETX 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 is not Grounded. A
floating DODAG is not expected to have IP connectivity to 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>
</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 how the basic RPL topologies, and the rules
by which these are constructed, i.e. the rules governing DODAG
formation.</t>
<section anchor="TopologyIdentifiers" title="Topology Identifiers">
<t>RPL uses four identifiers to maintain the topology: <list
style="symbols">
<t>The first is a RPLInstanceID. A RPLInstanceID identifies a
set of one or more DODAGs. All DODAGs in the same RPL Instance
use the same Objective Function. A network may have multiple
RPLInstanceIDs, each of which defines an independent set of
DODAGs, which may be optimized for different OFs and/or
applications. The set of DODAGs identified by a RPLInstanceID is
called a RPL Instance.</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 Destination Oriented DAG
(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 non-LLN backchannel.</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 an always-on
backbone suitable to coordinate to form a single DODAG, and
further 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 single virtual root coordinating LLN
sinks (with the same DODAGID) over some non-LLN backbone <list>
<t>For example, multiple border routers operating with a
reliable backbone, e.g. in support of a 6LowPAN application,
that are capable to act as logically equivalent sinks to 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 has meta-data that associates it with a particular
RPLInstanceID and therefore RPL Instance.(<xref
target="loopdetect"></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.
<xref target="figDODAGVersion"></xref> depicts how a DODAG version
number increment leads to a new DODAG Version.</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>
<!-- TBD TODO
<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 the DODAG root, as controlled by
policy at the 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.</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 application-level goals. A floating DODAG offers no such
connectivity, and provides routes only 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 uses a hop-by-hop IPv6 header to detect possible loops within
a DODAG. Each data packet includes the Rank of the transmitter. If a
node receives a data packet with a Rank less than or equal to its
own, this indicates a possible loop. On receiving such a packet, a
node institutes a local repair operation.</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.</t>
<t>Nodes listen for DIOs and use their information to join a new
DODAG, or to maintain an existing DODAG, as according to the
specified Objective Function and Rank of their neighbors.</t>
<!-- TBD TODO -->
<t>Nodes provision routing table entries, for the destinations
specified by the DIO, via their DODAG parents in the DODAG
version. Nodes 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 from DODAG roots. 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 to a
DODAG Root then down to the final destination (unless the destination
is on the upward route).</t>
</section>
<!-- TBD TODO -->
<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.</t>
</section>
<!-- TBD TODO -->
<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 list, thus leading to a constrained shortest path.</t>
<t>An Objective Function specifies the objectives used to compute the
(constrained) path. 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 to select a DODAG parent 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:">Constrained shortest path: the path that
does not traverse any battery-operated node and that optimizes the
path reliability</t>
</list></t>
<!-- TBD TODO -->
<section title="Loop Avoidance">
<t>RPL guarantees neither loop free path selection nor tight delay
convergence times. In order to reduce control overhead, however,
such as the cost of the count-to-infinity problem, RPL avoids
creating loops when undergoing topology changes. Furthermore, RPL
includes rank-based datapath validation mechanisms for detecting
loops when they do occur. RPL uses this loop detection to ensure
that packets make forward progress within the DODAG version and
trigger repairs when necessary.</t>
<!-- TBD TODO -->
<section title="Greediness and Rank-based Instabilities">
<t>A node is greedy if it attempts to move deeper in the DODAG
version, in order to increase the size of the parent set or
improve some other metric. Moving deeper in within a DODAG version
in this manner could result in instability and be detrimental to
other nodes.</t>
<t>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 messages
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>
</section>
<!-- TBD TODO -->
<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>
</section>
<!-- TBD TODO -->
<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>
</section>
<!-- TBD TODO -->
<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, and the node configuration and
policies.</t>
<t>The rank is not a cost metric, although its value can be derived
from and influenced by 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 decimal 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 cost to the root.</t>
<t hangText="Stability:">The stability of the rank determines
the stability of the routing topology. Some dampening or
filtering might be applied to keep the topology stable, and thus
the rank does not necessarily change as fast as some physical
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 strictly monotonic, 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>
<!-- TBD TODO -->
<section anchor="RankComparison" title="Rank Comparison (DAGRank())">
<t>Rank may be thought of as a fixed point number, where the
position of the decimal 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. 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>MinHopRankIncrease is provisioned at the DODAG Root and
propagated in the DIO message. For efficient implementation the
MinHopRankIncrease MUST be a power of 2. An implementation may
configure a value MinHopRankIncrease as appropriate to balance
between the loop avoidance logic of RPL (i.e. selection of
eligible parents) and the metrics in use.</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>
<!-- TBD TODO -->
<section title="Rank Relationships">
<t>The computation of the rank MUST be done in such a way so as to
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). In some cases, Node M may
be used as a successor by Node N, which however entails the
chance of creating a loop (which must be detected and resolved
by some other means).</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 objective
function is to minimize ETX, or latency when the objective
function is to minimize latency, or in a more complicated way as
appropriate to the objective function being used within the
DODAG.</t>
</section>
</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="I-D.ietf-roll-building-routing-reqs"></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="I-D.ietf-roll-building-routing-reqs"></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 routes toward
destination prefixes 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>
<section anchor="RPLInstance" title="RPL Instance">
<!-- TBD need to refactor other text for local / global Instance -->
<!-- TBD need to check that DODAGID is conveyed/available whenever
local instance is used -->
<t>Within a given LLN, there may be multiple, logically independent RPL
instances. This document describes how a single instance behaves.</t>
<t>A node may belong to multiple RPL Instances.</t>
<!-- TBD TODO -->
<t>Control and data packets in RPL network MUST be tagged to
unambiguously identify what RPL Instance they are part of. The
identifiers include the RPLInstanceID and, for local instances, the
DODAGID. In some uses the DODAGID is implicit, in other uses it must be
given explicitly. Every RPL control message has a RPLInstanceID field.
Some RPL control messages may optionally include a DODAGID. Data
messages routed with RPL have a RPL Hop-by-hop option (<xref
target="I-D.hui-6man-rpl-option"></xref>).</t>
<t>There are two types of RPL Instances: local and global. Local RPL
Instances are always a single DODAG whose singular root owns the
corresponding DODAGID. Local RPL Instances are intended for constructing
temporary DODAGs to support on-demand P2P traffic. Global RPL Instances
have one or more DODAGs and are typically long-lived. RPL divides the
RPLInstanceID space between global and local instances to prevent
identifier collisions.</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, and up 64 local instances per DODAGID.</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. In that case, the
DODAGID MUST be a valid address of the root that is used as an
endpoint of all communications within that 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 clear then the source address of the
IPv6 packet MUST be the DODAGID.</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 all routers
multicast address (FF02::2) or a link local address.</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 the 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 version. The secure versions provide
integrity and confidentiality. 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 Figure
<xref target="RPLSecureCtrlICMPFormat"></xref>.</t>
<t>The format of the security section is as follows:</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|T| Rsrvd |Sec|KIM|Rsrvd| LVL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Counter |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Message Authentication Code .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>All fields are considered as packet payload from a security
processing perspective. The exact placement and format of message
integrity/authentication codes has not yet been determined.</t>
<t>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 Compression (C):">If the Counter
Compression flag is set then the Counter field is compressed
from 4 bytes into 1 byte. If the Counter Compression flag is
clear then the Counter field is 4 bytes and uncompressed.</t>
<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 Mode (Sec):">The security algorithm
field specifies what security mode and algorithms the network
uses. Supported values of this field are as follows: <figure
title="">
<artwork><![CDATA[
+----+-----+-------------------+
| ID | Sec | Algorithm |
+----+-----+-------------------+
| 0 | 00 | CCM* with AES-128 |
| 1 | 01 | Reserved |
| 2 | 10 | Reserved |
| 3 | 11 | Reserved |
+----+-----+-------------------+
Security Mode (Sec) Encoding
]]></artwork>
</figure></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 title="">
<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, |
| | | group key used. Group key | |
| | | determined by Key Index and | |
| | | Key Source Identifier. | |
| | | | |
| | | Key Source may be present. | |
| | | Key Index may be present. | |
+------+-----+-----------------------------+------------+
Key Identifier Mode (KIM) Encoding
]]></artwork>
</figure></t>
<t hangText="Security Level (LVL):">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. The
Security Level is set to one of the non-reserved values in the
table below: <figure title="">
<artwork><![CDATA[
+---------------------------+--------------------+
| Without Signatures | With Signatures |
+----+-----+--------------------+------+--------------+-----+
| ID | LVL | Attributes | Auth | Attributes | Sig |
| | | | Len | | Len |
+----+-----+--------------------+------+--------------+-----+
| 0 | 000 | Reserved | N/A | Reserved | N/A |
| 1 | 001 | MAC-32 | 4 | Sign-32 | 40 |
| 2 | 010 | MAC-64 | 8 | Sign-64 | 44 |
| 3 | 011 | Reserved | N/A | Sign-128 | 52 |
| 4 | 100 | Reserved | N/A | Reserved | N/A |
| 5 | 101 | ENC-MAC-32 | 4 | ENC-Sign-32 | 40 |
| 6 | 110 | ENC-MAC-64 | 8 | ENC-Sign-64 | 44 |
| 7 | 111 | Reserved | N/A | ENC-Sign-128 | 52 |
+----+-----+--------------------+------+-------------+------+
Security Level (LVL) Encoding
]]></artwork>
</figure></t>
</list></t>
<t hangText="Counter:">The Counter field indicates the
non-repeating value (nonce) used with the cryptographic mechanism
that implements packet protection and allows for the provision of
semantic security. This value is compressed from 4 octets to 1
octet if the Counter Compression field of the Security Control
Field is set to one.</t>
<t hangText="Message Authentication Code:">The Message
Authentication Code field contains a cryptographic MAC. The length
of the MAC is defined by a combination of the LVL and Sec fields:
it can be 0, 4, or 8 octets long. In the case of Security Modes
where the MAC is computed as part of the ciphertext (as in
Security Mode 0, CCM*), the MAC field is zero bytes long.</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></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 Figure <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DIS message shown in Figure <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>0x05 RPL Target</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 upward routing topology.</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 | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|A|T|MOP| Prf | DTSN | 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 upward routes this node advertises provide
connectivity to the set of addresses which are
application-defined goals. If the flag is set, the DODAG is
grounded and provides such connectivity. If the flag is
cleared, the DODAG is floating and may not provide such
connectivity.</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 table below:<figure
title="Mode of Operation (MOP) Encoding">
<artwork><![CDATA[
+-----+-------------------------------------------------+
| MOP | Meaning |
+-----+-------------------------------------------------+
| 00 | Non-storing |
| 01 | Storing |
| 10 | Reserved |
| 11 | Reserved |
+-----+-------------------------------------------------+
]]></artwork>
</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. <xref target="DAGDiscovery"></xref> describes the
rules for 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="DODAGID:">128-bit unsigned integer set by a DODAG
root which uniquely identifies a DODAG. Possibly derived from
the IPv6 address of 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 Figure <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DIS message shown in Figure <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>0x09 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. The DAO message is
unicast by the child to the selected parent(s). The DAO message may
optionally, upon explicit request or error, be acknowledged by the
parent with a Destination Advertisement Acknowledgement (DAO-ACK)
message back to the child.</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| Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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="K:">The 'K' flag indicates that the parent is
expected to send a DAO-ACK back.</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="DAOSequence:">Incremented at each unique DAO
message, 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 Figure <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DAO message shown in Figure <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>
</list><?rfc subcompact="no"?></t>
<t>A special case of the DAO message, termed a No-Path, is used to
clear downward routing state that has been provisioned through DAO
operation. The No-Path carries a RPL Transit Information option,
which identifies the destination to which the DAO is associated,
with a lifetime of 0x00000000 to indicate a loss of
reachability.</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 parent in
response to a unicast DAO message from a child.</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>
</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="DAOSequence:">Incremented at each DAO message from
a given child, echoed in the DAO-ACK by the parent. The
DAOSequence serves in the parent-child communication and is not
to be confused with the Transit Information option Sequence that
is associated to a given target down the DODAG.</t>
<t hangText="Status:">Indicates the completion. 0 is unqualified
acceptance, above 128 are rejection code indicating 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 Figure <xref
target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
the DAO-ACK message shown in Figure <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.</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| Reserved | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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="Nonce:">16-bit unsigned integer set by a CC
request. The corresponding CC response includes the same nonce
value as the request.</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>
</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 the 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 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 ND Route Information option as
defined in <xref target="RFC4191"></xref>. The format of the option
is modified slightly (Type, Length) 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 is 0, 8, or 16 octets depending
on Length.</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.</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 IP 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.</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 | Option Length | Resrvd|A| PCS | DIOIntDoubl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIOIntMin. | DIORedun. | MaxRankIncrease |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinHopRankIncrease | OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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:">8 bytes</t>
<t hangText="Authentication Enabled (A):">One bit 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>).</t>
<t hangText="DIOIntervalDoublings:">8-bit unsigned integer used
to configure Imax of the DIO trickle timer (see <xref
target="TrickleParameters"></xref>).</t>
<t hangText="DIOIntervalMin:">8-bit unsigned integer used to
configure Imin of the DIO trickle timer (see <xref
target="TrickleParameters"></xref>).</t>
<t hangText="DIORedundancyConstant:">8-bit unsigned integer used
to configure k of the DIO trickle timer (see <xref
target="TrickleParameters"></xref>).</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>.</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 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 | Reserved | 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 DIO, the RPL Target Option identifies a resource that
the root is trying to reach. In a DAO, the RPL Target option
indicates reachability.</t>
<t>A set of one or more Transit Information options MAY directly
follow the Target option in a DAO message in support of constructing
source routes in a non-storing mode of operation <xref
target="I-D.hui-6man-rpl-routing-header"></xref>. When the same set
of Transit Information options apply equally to a set of DODAG
Target options, the group of Target options MUST appear first,
followed by the Transit Information options which apply to those
Targets.</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="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 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 | Path Sequence | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Parent Address* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</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 as by one or more Target options that immediately
precede the Transit Information option(s).</t>
<t>The Transit Information option can 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. 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 code
the Path Control field in order to signal a preference among
parents.</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.</t>
<t>A typical non-storing node will use multiple Transit Information
options, and it will send the DAO thus formed to only one parent
that will forward it to the root. A typical storing node with use
one Transit Information option with no parent field, and will send
the DAO thus formed to multiple parents.</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="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.</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 fan-out in the LLN. The
leftmost bit is associated with a path that contains a
most-preferred link, and the subsequent bits are ordered down to
the rightmost bit which is least preferred.</t>
<t hangText="Path 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. A value of all zero
bits (0x00000000) indicates a loss of reachability. This is
referred as a No-Path 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 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 | Option Length | RPLInstanceID |V|I|D| Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+
]]></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. 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 bytes</t>
<t hangText="Control Field:">The Solicited Information option
Control Field has three flags: <list hangIndent="6"
style="hanging">
<t hangText="V:">If the V flag is set then the Version field
is valid and a node matches the predicate if its
DODAGVersionNumber matches the requested version. If the V
flag is clear 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:">If the I flag is set then the RPLInstanceID
field is valid and a node matches the predicate if it
matches the requested RPLInstanceID. If the I flag is clear
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:">If the D flag is set then the DODAGID field
is valid and a node matches the predicate if it matches the
requested DODAGID. If the D flag is clear then the DODAGID
field is not valid and the DODAGID field MUST be set to zero
on transmission and ignored upon receipt.</t>
</list></t>
<t hangText="Version:">8-bit unsigned integer containing the
DODAG Version number 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) 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 | Option Length | Prefix Length |L|A| 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> 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="Reserved1">6-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 IP address or a prefix of an IP 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.</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>
</section>
<section anchor="SequenceNumbers" title="Sequence Counters">
<t>RPL makes use of sequence counters for the DODAGVersionNumber in the
DIO message, the DAOSequence in the DAO message, and the Path-Sequence
in the Transit Information option.</t>
<t>This section describes the general scheme for bootstrap and operation
of sequence counters in RPL. The general operations described here are
to applied to RPL's various sequence counters as enumerated above.</t>
<t>RPL sequence counters are subdivided in a 'lollipop' fashion (<xref
target="Perlman83"></xref>), where the values from 0 to 15 are used as a
short linear sequence to indicate a restart and bootstrap the counter,
and the remaining values are used as a circular sequence number space as
in <xref target="RFC1982"></xref>.</t>
<t>When a sequence counter is initialized, if the node has no other
basis of persistence for that counter, then the sequence counter is
initialized to zero.</t>
<t>When a sequence counter increments past its maximum value, the
sequence counter wraps back to 16 instead of zero.</t>
<t>When two sequence counters to be compared are both in [0..15] (the
'straight' part of the lollipop), a normal arithmetic comparison is
applied for greater than, less than, and equal.</t>
<t>When a first sequence counter is in [0..15], and a second sequence
counter to be compared is >15, then the first sequence counter is
taken to be fresher, and thus greater, than the second. The second
sequence counter is less than the first, and the two are not equal.</t>
<t>When two sequence counters to be compared are both outside of [0..15]
(the 'circular' part of the lollipop), a comparison as described in
<xref target="RFC1982"></xref> may be used to determine the
relationships greater than, less than, and equal, with the modification
that the sequence counters should be compared as if the minimum value is
16 and not 0.</t>
</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>If the 'A' flag of a DIO Base is cleared, the 'T' flag MUST
also be cleared.</t>
<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>). Therefore, if a
DODAG root does not change these values, every node in a route to
that DODAG root eventually advertises the same values for these
fields. These fields are: <?rfc subcompact="yes"?><list>
<t>Grounded (G)</t>
<t>Destination Advertisement Supported (A)</t>
<t>Destination Advertisement Trigger (T)</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.</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, a set of size one, is an element of the parent set
that is the preferred next hop in upward routes.</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), 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>
<!-- TBD TODO -->
<t>The OF can guide candidate neighbor set and parent set selection,
as discussed in <xref target="I-D.ietf-roll-routing-metrics"></xref>
and <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>.</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 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>
<!-- TBD TODO
<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>
-->
<!-- TBD TODO -->
<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 of 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>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 connectivity to the set of
application-level Goals 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 a backbone link to federate a number
of LLN roots, it is possible to run RPL over that backbone 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.</t>
</section>
<section anchor="DAGSelection" title="DODAG Selection">
<t>The objective function of a DAG determines how a node selects
its neighbor set, parent set, and preferred parents. This
selection implicitly also decides 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.</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 would 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 new a 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>
<!-- TBD turn this into an implementation note?
<t>If a node has selected a new set of DAG parents but has not
jumped yet (because it is waiting for DAG Hop timer to
elapse), the node is UNSTABLE and MUST NOT send DIOs for that
DAG.</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 meta-data include a Rank that is not INFINITE_RANK
yet still advertise INFINITE_RANK in its DIOs.</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 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 should 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.</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
lower 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.</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.</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, if it satisfies the predicates of the 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 DAO 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. Nodes
SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and
destinations compatible with their implementation specific objectives.
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 the RPL
Instance's OF or advertised path metric. A leaf node does not extend
DODAG connectivity but still needs to advertise its presence using
DIOs. 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 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>In some cases it is necessary for a leaf node to send a DIO, for
example 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
participate in the repair. It is not expected that such a leaf node
would advertise itself as a router.</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 of P2MP
flows, from the DODAG roots toward the leaves. Downward routes also
support P2P flows: P2P messages can flow to a DODAG Root 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, call "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.</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="symbols">
<t>A node's DAO parent set MUST be a subset of its parent set.</t>
<t>A node MUST NOT unicast DAOs to nodes that are not DAO
parents.</t>
<t>A node MAY link-local multicast DAO messages.</t>
<t>The IPv6 Source Address of a DAO message MUST be the link local
address of the sending node.</t>
<t>If a node sends a DAO to one DAO parent, it MUST send a DAO
with the same DAOSequence to all other DAO parents.</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 operate in either a
storing or non-storing mode, as reported in the MOP in the DIO
message.</t>
<t><list style="numbers">
<t>If the 'A' (Destination Advertisement Supported) flag of DIO
messages for the RPL Version is not set, nodes MUST NOT transmit
DAO messages, MAY ignore DAO messages, and MAY ignore the MOP
field of DIOs.</t>
<t>All nodes who join a DODAG with the 'A' flag set MUST follow
the MOP setting from the root. Nodes that do not have the
capability to fully participate as a router MAY join the DODAG as
a leaf.</t>
<t>In storing mode, all non-root, non-leaf nodes MUST store
routing table entries for all destinations learned from DAOs.</t>
<t>In non-storing mode, the DODAG Root MUST store source routing
table entries for all destinations learned from DAOs.</t>
</list></t>
<t>A DODAG can have one of three settings. Either it does not support
downward routes (the 'A' flag in DIOs is cleared), it supports
downward routes through source routing from DODAG Roots (the 'A' flag
is set and the MOP indicates non-storing), or it supports downward
routes through in-network routing tables (the 'A' flag is set and the
MOP indicates storing). 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>
<section anchor="DAOBaseRules" title="DAO Base Rules">
<t><list style="numbers">
<t>Each time a node generates a new DAO, the DAOSequence field
MUST increment by at least one since the last generated DAO.</t>
<t>Each time a node link-local multicasts a DAO, the DAOSequence
field MUST increment by one since the last link local multicast
DAO.</t>
<t>The RPLInstanceID and DODAGID fields of a DAO 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. 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>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.</t>
</section>
<section anchor="ScheduleDAO" title="DAO Transmission Scheduling">
<t>Because DAOs flow upwards, receiving a unicast DAO can trigger
sending a unicast DAO.</t>
<t><list style="numbers">
<t>On receiving a unicast DAO with a new DAOSequence, a node
SHOULD send a DAO. It SHOULD NOT send this DAO immediately. It
SHOULD delay sending the DAO 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 with a timer (DelayDAO).
Receiving a DAO starts the DelayDAO timer. DAOs 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 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 transmission using rules in <xref
target="DAOBaseRules"></xref> and <xref
target="ScheduleDAO"></xref>.</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>A node may increment DTSN in order to reliably trigger a set of DAO
updates from its immediate children, as part of a routine routing
table update. A node may increment DTSN and set the 'T' bit in order
to trigger a set of DAO updates from its entire sub-DODAG.</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 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. 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 they transmit. One RPL Target Option MUST have a prefix that
includes the node's IPv6 address.</t>
<t>A RPL Target Option in a unicast DAO MUST be followed by a
Transit Information Option.</t>
<t>Multicast DAOs MUST NOT include Transit Information
options.</t>
<t>If a node receives a DAO that does not follow the above three
rules, it MUST discard the DAO without further processing.</t>
</list></t>
</section>
<section anchor="DAONonStoring" title="Non-storing Mode">
<t>In non-storing mode, RPL routes messages downward using 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 forward the DAO
upwards. This forwarding MAY use any parent in the parent set.</t>
<t>When a node removes a node from its DAO parent set, it MAY
generate a new DAO 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
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 a
single DAO, although it might choose to send more than one DAO to each
of multiple DAO parents.</t>
<t>Nodes aggregate DAOs by sending a single DAO with multiple RPL
Target Options. Each RPL Target Option has its own, immediately
following, Transit Information options.<!-- TBD TODO
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.
If so, the node MUST generate a new DAO 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 to nodes that are
not DAO parents.</t>
<t>When a node removes a node from its DAO parent set, it SHOULD
send a No-Path DAO (<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 a network, 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 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 specified in the PCS control field of the DODAG
Configuration Option. Bits greater than or equal to the value
specified in the PCS control field MUST be cleared on transmission
and MUST be ignored on reception. Bits below the value in the PCS
control field are considered "active" bits.</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 to one of its DAO parents, it MUST
select one or more of the set, active bits in the aggregated Path
Control field. The DAO 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 in order of preference,
such that the most significant bits, or groupings of bits, are
allocated to the most preferred DAO parents as determined by the
node.</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 that has no active bits in the
Path Control field set.</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>
</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-nodes multicast address FF02::1.</t>
<t>A multicast DAO message MUST be used only to advertise
information about self, 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>
<t>Information obtained from a multicast DAO 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, 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 RPL routing structure to relay
the packets.</t>
<t>The multicast DAO does not presume any DODAG relationship
between the emitter and the receiver.</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>
<section anchor="SecurityOverview" title="Security Overview">
<t>RPL supports three security modes:</t>
<t><list style="symbols">
<t>Insecure. In this security mode, RPL uses insecure DIS, DIO,
DAO, and DAO-Ack messages.</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 insecure 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>RPL uses CCM* -- Counter with CBC-MAC (Cipher Block Chaining
Message Authentication Code) -- as the cryptographic basis for its
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 a message authentication code (MAC).
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="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.</t>
<t>The exact message exchange to obtain such keys is TBD. It will
involve communication with a key authority, possibly, using the
pre-installed shared key. The key authority can apply a security
policy to decide whether to grant the would-be-router a new key. These
keys may have lifetimes (start and end times) associated with them,
which nodes that support timestamps (described in <xref
target="TimestampCounters"></xref>) can use.</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 NOT set the C bit, MUST
set the KIM field to 0 (00), and MUST set the LVL 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:</t>
<t><list style="numbers">
<t>A node MUST NOT advertise a Rank besides INFINITE_RANK in
secure DIOs secured with Key Index 0x00. If a node receives a
secure DIO that advertises a Rank besides INFINITE_RANK and is
secured with Key Index 0x00, it MUST discard the message without
further processing.</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 using the preinstalled, shared key where
the RPL Target option does not match the IPv6 source address, it
MUST discard the secured DAO 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. Obtaining this
key might require authentication on one or both ends. This message
exchange is TBD.</t>
</section>
<section anchor="SecurityCounter"
title="Counter and Counter Compression">
<t>Every secured RPL packet has a Counter field. Depending on whether
the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL nodes
send CC messages to force uncompressed Counter values, protecting
against replay attacks and synchronizing counters.</t>
<t><list style="numbers">
<t>If a node is sending a secured RPL packet, and the Counter
value of the packet is more than 255 greater than the last secured
packet to the destination address, the node MUST NOT set the 'C'
bit of the security section of the packet.</t>
<t>If a node receives a secure RPL message with the C bit set and
is uncertain of the 32-bit counter value, it MAY send a CC message
with the R bit cleared to obtain an uncompressed counter value.
The Nonce field of the CC message SHOULD be a random or
pseudorandom number.</t>
<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 C bit of the security
section cleared, 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>These rules allow nodes to compress the Counter when destinations
who received the prior packet can determine the full counter value. If
a node cannot determine the full counter value, it can request the
full counter with a CC message.</t>
<section anchor="TimestampCounters" title="Timestamp 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 1kHz (millisecond) granularity.</t>
<t>The timestamp start time MUST be January 1, 2010, 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>
</section>
</section>
<section title="Functional Description of Packet Protection">
<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 describes the order of cryptographic
operations to provide the required protection.</t>
<t>A RPL node MUST set the security section (KIM, LVL, T, and Sec)
in the RPL packet to describe the required protection level.</t>
<t>The Counter field of the security header MUST be an increment of
the last Counter field transmitted.</t>
<t>If the RPL packet is not a response to a Consistency Check
message, the node MAY set the Counter Compression flag of the
security option, following the rules in <xref
target="SecurityCounter"></xref>.</t>
<t>If the Key Identifier Mode (KIM) is 3 (signature key used), and
the Security Level (LVL) calls for encryption, the transmitter MUST
include the Key Source Identifier and Key Index in the security
section and append a signature using its signature key.</t>
<t>A node MUST replaced the original packet payload with that
payload encrypted using the security protection, key, and nonce
specified in the security section.</t>
</section>
<section title="Reception of Incoming Packets">
<t>This section describes the reception of a secured RPL packet.
Given an incoming RPL packet, this section describes now RPL
generates an unencrypted version of the packet and validates its
integrity.</t>
<t>The receiver uses the security control field of the security
section to determine what processing to do. If the described level
of security 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 (the 'T' flag).</t>
<t>Using a nonce derived from the Counter field and other
information (as described in Section <xref
target="CCM*Nonce"></xref>), the receiver checks the integrity of
the packet. If this integrity check does not pass, a node MUST
discard the packet.</t>
<t>RPL uses the key information described in a RPL message to
decrypt its contents as necessary. Once a message has passed its
integrity checks and been successfully decrypted, the node can
update its local security information, such as the source's expected
counter value for counter compression. A node MUST NOT update
security information on receipt of a message that fails security
policy checks, integrity checks, or decryption.</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="TimestampCounters"></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="Cryptographic Mode of Operation">
<t>The cryptographic mode of operation used is based on the CCM mode
of operation 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 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 shall be represented is
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 00 is an
instantiation of the ECPVS signature scheme<xref
target="X9.92"></xref>. It uses as an elliptic curve the named
curve K-283<xref target="X9.92"></xref>. It uses CCM* mode<xref
target="CCMStar"></xref> as the encryption scheme with M=0 (as a
stream-cipher). It uses the Matyas-Meyer-Oseas unkeyed hash
function<xref target="AppliedCryptography"></xref>. It uses the
key derivation function based on this unkeyed hash function
specified in Section 5.6.3 of <xref target="X9.63-2001"></xref>,
and the message encoding rule of Section 7.8 or ANSI X9.92 <xref
target="X9.92"></xref>. PadLen is a non-negative integer set to
M-OctCurve, where OctCurve is the byte-length of the curve in
question (with K-283, one has OctCurve=36).</t>
<t>Let 'a' be a concatenation of a six-byte representation of
Counter and the message header. The packet payload is a
concatenation of packet data 'c' and the signature 's'. This
signature scheme is invoked with visible and recoverable message
parts a and c, whereas the signature verification is invoked with
as received visible and message representative a, c, and with
signature s.</t>
</section>
</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. The message authentication code is calculated over the
entire IPv6 packet. This calculation is done before any compression
that lower layers may apply. The IPv6 and ICMPv6 headers are never
encrypted. The body of the RPL ICMPv6 message MAY be encrypted,
starting from the first byte after the security section and continuing
to the end of the packet.</t>
</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.</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, then use that
route <xref target="I-D.hui-6man-rpl-routing-header"></xref>. 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 DODAG root <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.</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>TTL must be decremented when forwarding.</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 up to an down
flow, such as switching from DIO routes to DAO routes as the
destination is neared.</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 is placed into the packet.
A future version of this specification will detail how this
information is carried with the packet (e.g. a hop-by-hop option
(<xref target="I-D.hui-6man-rpl-option"></xref>) or summarized somehow
into the flow label). For the purpose of RPL operations, the
information carried with a packet is constructed follows:</t>
<t><figure 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' bit:">1-bit flag indicating whether the
packet is expected to progress up or down. A router sets the 'O'
bit when the packet is expect to progress down (using DAO routes),
and resets it when forwarding towards the root of the DODAG
version. A host or RPL leaf node MUST set the bit to 0.</t>
<t hangText="Rank-Error 'R' bit:">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 bit to 0.</t>
<t hangText="Forwarding-Error 'F' bit:">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 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">
<!-- Flow label specific guidance
<t>A packet that is sourced at a node connected to a RPL network or
destined to a node connected to a RPL network MUST be issued with
the flow label zeroed out, but for the RPLInstanceID field.</t>
-->
<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>
<!-- Flow label specific guidance
<t>If a compression mechanism such as 6LoWPAN is applied to the
packet, the flow label MUST NOT be compressed even if it is set to
all zeroes.</t>
-->
</section>
<section title="Router Operation">
<!-- Flow label specific guidance
<section title="Conformance to RFC 3697">
<t><xref target="RFC3697"></xref> mandates that the Flow Label
value set by the source MUST be delivered unchanged to the
destination node(s).</t>
<t>In order to restore the flow label to its original value, an
RPL router that delivers a packet to a destination connected to a
RPL network or that routes a packet outside the RPL network MUST
zero out all the fields but the RPLInstanceID field that must be
delivered without a change.</t>
</section>
-->
<section title="Instance Forwarding">
<t>Instance IDs are used to avoid loops between DODAGs from
different origins. DODAGs that 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. For traffic
originating outside of the RPL domain there may be a mapping
occurring at the gateway into the RPL domain, possibly based on an
encoding within the flow label. This aspect of RPL operation is to
be clarified in a future version of this specification.</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 reset (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 version and
the prior version, in particular if nodes are adjusting their rank
in the next version and deferring their migration into the next
version. A router that is still a member of the prior version may
choose to forward a packet to a (future) parent that is in the
next version. In some cases this could cause the parent to detect
an inconsistency because the rank-ordering in the prior version is
not necessarily the same as in the next 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
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 as 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 is
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 is discarded and the trickle timer is
reset.</t>
</section>
<section title="DAO Inconsistency Loop Detection and Recovery">
<t>A DAO inconsistency happens when router that has an down DAO
route via a child that is a remnant from an obsolete state that is
not matched in the child. 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. 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>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 the RPL protocol; 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 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 root, enabling the root to copy a
multicast packet to all its children routers that had issued a DAO
message including a DAO 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 root of an
DODAG terminates RPL 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 source 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 Internet for all
multicast flows started in the RPL LLN. So regardless of whether the
root is actually attached to the Internet, 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.</t>
</section>
<section anchor="OFGuide" title="Guidelines for Objective Functions">
<t>An Objective Function (OF) 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>
<!-- TBD TODO '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, 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 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">TBD (To be determined)</t>
<t hangText="DEFAULT_DIO_INTERVAL_MIN">TBD (To be determined)</t>
<t hangText="DEFAULT_DIO_INTERVAL_DOUBLINGS">TBD (To be
determined)</t>
<t hangText="DEFAULT_DIO_REDUNDANCY_CONSTANT">TBD (To be
determined)</t>
<t hangText="DEFAULT_MIN_HOP_RANK_INCREASE">TBD a power of two (To
be determined)</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 instance 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 instance per DAO entry per
neighbor (i.e. those neighbors that have given DAO messages to this
node as a DODAG parent) Expiry triggers a change in state for the
DAO entry, setting up to do unreachable (No-Path) advertisements or
immediately deallocating 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 very 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">
<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
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, it may either choose to stay
silent and not send any multicast DIO messages until it has joined
a DODAG, or to immediately root a transient DODAG and start
sending multicast DIO messages. A RPL implementation SHOULD allow
configuring whether the node should stay silent or should start
advertising DIO messages.</t>
<t>Furthermore, the implementation SHOULD allow configuring
whether or not the node should start sending an DIS (optionally
requesting DIO for a specific DODAG) message as an initial probe
for nearby DODAGs, or should simply wait until it receives DIO
messages from other neighboring nodes that are part of existing
DODAGs.</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><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>Objective Code Point (OCP)</t>
<t>DODAGID [DIO, DIO base option] and [DAO message when the D
flag of the DAO message is set).</t>
<t>Route Information (and preference) [DIO message, in Route
Information option]</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>[I-D.ietf-roll-routing-metrics] specifies a number of metrics
and constraints that could be used. 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, as specified in <xref
target="OperationAsALeaf"></xref>, the node would join as a leaf
node.</t>
<t>K flag [DAO message, in DAO base message].</t>
<t>MOP (Mode of Operation) [DIO message, in DIO base
message]</t>
</list></t>
</section>
<section title="Protocol Parameters to be configured on every non-root router in the LLN">
<t><list style="symbols">
<t>Target prefix [DAO, in RPL Target option and DIO
messages]</t>
<t>Transit information [DAO, Transit information option]: A RPL
implementation SHOULD allow configuring whether a non-storing
node provides the transit information in DAO messages.</t>
</list></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, in DODAG configuration option]</t>
<t>DIOIntervalMin [DIO, in DODAG configuration option]</t>
<t>DIORedundancyConstant [DIO, 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, in DODAG configuration option]</t>
<t>MinHopRankIncrease [DIO, in DODAG configuration option]</t>
<t>The following flags: A, MOP (Mode of Operation),
DODAGPreference field [DIO message, DIO Base object]</t>
<t>Route information (list of prefixes with preference) [DIO
message, in Route Information option]</t>
<t>The T flag allows for triggering a refresh of the downward
routes. A RPL implementation SHOULD support manual setting of
the T flag or upon the occurrence of a set of event such as the
expiration of a configurable periodic timer.</t>
<t>List of metrics and constraints used for the DODAG.</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>
</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>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>While the entry is in the UNREACHABLE state 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>
<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>When scheduling to send a DAO, an implementation should
equivalently start a timer (DelayDAO) to delay sending the DAO, thus
helping to potentially aggregate DAOs. The DelayDAO timer 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"></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 A flag [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, in DODAG configuration
option]</t>
<t>DIOIntervalMin [DIO, in DODAG configuration option]</t>
<t>DIORedundancyConstant [DIO, in DODAG configuration
option]</t>
</list></t>
<t>Path Control Size [DIO, in DODAG configuration option]</t>
<t>MinHopRankIncrease [DIO, 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 reset (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>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 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>
</list></t>
</section>
<section 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 consists of specifying the following
conditions that a RPL node must satisfy to join a DODAG:</t>
<t><list style="symbols">
<t>RPLInstanceID</t>
<t>DODAGID</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.</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.</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">
<figure title="">
<artwork><![CDATA[
+----------------------------------------------------------------+
| |
| TBD |
| Under Construction |
| Deference given to Security Design Team |
| |
+----------------------------------------------------------------+
]]></artwork>
</figure>
<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>Two values are currently defined:</t>
<texttable title="DIO Base Flags">
<ttcol align="center">MOP</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>00</c>
<c>Non-Storing mode of operation</c>
<c>This document</c>
<c>01</c>
<c>Storing mode of operation</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>DAG Timer 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>
</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="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>
<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, Phoebus Chen, Mathilde Durvy, Manhar Goindi, Mukul Goyal,
Anders Jagd, JeongGil (John) Ko, Quentin Lampin, Jerry Martocci, Matteo
Paris, Alexandru Petrescu, Joseph Reddy, and Don Sturek.</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, and
Arsalan Tavakoli, which have provided useful design considerations to
RPL.</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:</t>
<figure>
<artwork><![CDATA[
JP Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782
France
Email: jpv@cisco.com
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Philip Levis
Stanford University
358 Gates Hall, Stanford University
Stanford, CA 94305-9030
USA
Email: pal@cs.stanford.edu
Richard Kelsey
Ember Corporation
Boston, MA
USA
Phone: +1 617 951 1225
Email: kelsey@ember.com
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, CA 94107
USA
Email: jhui@archrock.com
Kris Pister
Dust Networks
30695 Huntwood Ave.
Hayward, 94544
USA
Email: kpister@dustnetworks.com
Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen, DK-2100
Denmark
Email: abr@sdesigns.dk
Stephen Dawson-Haggerty
UC Berkeley
Soda Hall, UC Berkeley
Berkeley, CA 94720
USA
Email: stevedh@cs.berkeley.edu
]]></artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-roll-building-routing-reqs.xml'?>
<?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-routing-metrics.xml'?>
<?rfc include='reference.I-D.ietf-roll-of0.xml'?>
<?rfc include="reference.RFC.3819"?>
<?rfc include="reference.RFC.4101"?>
<?rfc include="reference.RFC.4191"?>
<?rfc include="reference.RFC.4862"?>
<?rfc include="reference.RFC.4443"?>
<?rfc include="reference.RFC.4861"?>
<?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.I-D.ietf-manet-nhdp.xml"?>
<?rfc include="reference.I-D.ietf-roll-trickle.xml"?>
<?rfc include="reference.I-D.hui-6man-rpl-option.xml"?>
<?rfc include="reference.I-D.hui-6man-rpl-routing-header.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="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>
<section anchor="TODO" title="Outstanding Issues">
<t>This section enumerates some outstanding issues that are to be
addressed in future revisions of the RPL specification.</t>
<section title="Additional Support for P2P Routing">
<t>In some situations the baseline mechanism to support arbitrary P2P
traffic, by flowing upwards along the DODAG until a common ancestor is
reached and then flowing down, may not be suitable for all application
scenarios. A related scenario may occur when the down paths setup
along the DODAG by the destination advertisement mechanism are not the
most desirable downward paths for the specific application scenario
(in part because the DODAG links may not be symmetric). It may be
desired to support within RPL the discovery and installation of more
direct routes 'across' the DAG. Such mechanisms need to be
investigated.</t>
</section>
<!-- DONE (pending Extension Header vs. Flow Label)
<section title="Loop Detection">
<t>It is under investigation to complement the loop avoidance
strategies provided by RPL with a loop detection mechanism that may be
employed when traffic is forwarded.</t>
</section>
-->
<!--
<section title="Destination Advertisement / DAO Fan-out">
<t>When DAO messages are relayed to more than one DODAG parent, in
some cases a situation may be created where a large number of DAO
messages conveying information about the same destination flow upwards
along the DAG. It is desirable to bound/limit the
multiplication/fan-out of DAO messages in this manner. Some aspects of
the Destination Advertisement mechanism remain under investigation,
such as behavior in the face of links that may not be symmetric.</t>
<t>In general, the utility of providing redundancy along downwards
routes by sending DAO messages to more than one parent is under
investigation.</t>
-->
<!-- This has now been addressed with DTSN, 'S', and 'T' flag:
<t>The use of suitable triggers, such as the 'T' flag, to trigger DA
operation within an affected sub-DODAG, is under investigation.
Further, the ability to limit scope of the affected depth within the
sub-DODAG is under investigation (e.g. if a stateful node can proxy
for all nodes 'behind' it, then there may be no need to propagate the
triggered 'T' flag further).</t>
-->
<!--
</section>
-->
<!-- This is addressed with proposed RPL Routing Header
<section title="Source Routing">
<t>In support of nodes that maintain minimal routing state, and to
make use of the collection of piecewise source routes from the
destination advertisement mechanism, there needs to be some
investigation of a mechanism to specify, attach, and follow source
routes for packets traversing the LLN.</t>
</section>
-->
<section title="Address / Header Compression">
<t>In order to minimize overhead within the LLN it is desirable to
perform some sort of address and/or header compression, perhaps via
labels, addresses aggregation, or some other means. This is still
under investigation.</t>
</section>
<section title="Managing Multiple Instances">
<t>A network may run multiple instances of RPL concurrently. Such a
network will require methods for assigning and otherwise managing
RPLInstanceIDs. This will likely be addressed in a separate
document.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:05:34 |