RPL: IPv6 Routing Protocol for Low
power and Lossy Networkswintert@acm.orgCisco Systems, IncVillage d'Entreprises Green Side400, Avenue de RoumanilleBatiment T3Biot - Sophia Antipolis06410France+33 497 23 26 34pthubert@cisco.comSigma DesignsEmdrupvej 26A, 1.CopenhagenDK-2100Denmarkabr@sdesigns.dkLIX, Ecole
Polytechnique, France+33 6 6058 9349T.Clausen@computer.orghttp://www.ThomasClausen.org/Arch Rock
Corporation501 2nd St. Ste. 410San FranciscoCA94107USAjhui@archrock.comEmber
CorporationBostonMAUSA+1 617 951 1225kelsey@ember.comStanford
University358 Gates Hall, Stanford UniversityStanfordCA94305-9030USApal@cs.stanford.eduDust Networks30695 Huntwood Ave.HaywardCA94544USAkpister@dustnetworks.comrstruik.ext@gmail.comCisco Systems, Inc11, Rue Camille DesmoulinsIssy Les Moulineaux92782Francejpv@cisco.com
Routing Area
ROLLDraftLow 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 processing power, memory, and
energy (battery power). Their interconnects are characterized by high
loss rates, low data rates, and instability. LLNs are comprised of
anything from a few dozen and up to thousands of routers. Supported
traffic flows include point-to-point (between devices inside the LLN),
point-to-multipoint (from a central control point to a subset of devices
inside the LLN), and multipoint-to-point (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.Low power and Lossy Networks (LLNs) consist of largely of constrained
nodes (with limited processing power, memory, and sometimes energy when
they are battery operated or energy scavenging). These routers are
interconnected by lossy links, typically supporting only low data rates,
that are usually unstable with relatively low packet delivery rates.
Another characteristic of such networks is that the traffic patterns are
not simply point-to-point, but in many cases point-to-multipoint or
multipoint-to-point. Furthermore such networks may potentially comprise
up to thousands of nodes. These characteristics offer unique challenges
to a routing solution: the IETF ROLL Working Group has defined
application-specific routing requirements for a Low power and Lossy
Network (LLN) routing protocol, specified in , , , and .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.RPL was designed with the objective to meet the requirements
spelled out in , , , and .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.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.RPL operations require bidirectional links. It is required that the
reachability of a router is verified before the router can be used as
a parent. RPL expects an external mechanism to be triggered during the
parent selection phase in order to verify link properties and neighbor
reachability. Neighbor Unreachability Detection (NUD) is such a
mechanism, but alternates are possible, including Bidirectional
Forwarding Detection and hints from
lower layers via L2 triggers like . In a
general fashion, a detection mechanism that is reactive to traffic is
favored in order to minimize the cost of monitoring links that are not
being used.RPL also expects an external mechanism to access and transport some
control information, referred to as the "RPL Packet Information", in
data packets. The RPL Packet Information is defined in and enables the association of a data
packet with a RPL instance and the validation of RPL routing states.
The IPv6 Hop-by-Hop RPL Option is an example of such
mechanism. The mechanism is required for all packets except when
strict source routing is used (that is for packets going downward in
non-storing mode as detailed further in ), which by nature prevents endless
loops and alleviates the need for the RPL Packet Information. Future
companion specifications may propose alternate ways to carry the RPL
Packet Information in the IPv6 packets and may extend the RPL Packet
Information to support additional features.RPL provides a mechanism to disseminate information over the
dynamically-formed network topology. The dissemination enables minimal
configuration in the nodes, allowing nodes to operate mostly
autonomously. This mechanism uses trickle to optimize the
dissemination as described in .In some applications, RPL assembles topologies of routers that own
independent prefixes. Those prefixes may or may not be aggregatable
depending on the origin of the routers. A prefix that is owned by a
router is advertised as on-link.RPL also introduces the capability to bind a subnet together with a
common prefix and to route within that subnet. A source can inject
information about the subnet to be disseminated by RPL, and that
source is authoritative for that subnet. Because many LLN links have
non-transitive properties, a common prefix that RPL disseminates over
the subnet must not be advertised as on-link.RPL may in particular disseminate IPv6 Neighbor Discovery (ND)
information such as the Prefix
Information Option (PIO) and the Route
Information Option (RIO). ND information that is disseminated by RPL
conserves all its original semantics for router to host, with limited
extensions for router to router, though it is not to be confused with
routing advertisements and it is never to be directly redistributed in
another routing protocol. A RPL node often combines host and router
behaviors. As a host, it will process the options as specified in
, , and . As a
router, the RPL node may advertise the information from the options as
required for the specific link, for instance in a ND RA message,
though the exact operation is out of scope.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.In compliance with the layered architecture of IP, RPL does not
rely on any particular features of a specific link layer technology.
RPL is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low power wireless or PLC
(Power Line Communication) technologies.Implementers may find a useful
reference when designing a link layer interface between RPL and a
particular link layer technology.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 RFC 2119.Additionally, this document uses terminology from , and introduces the following
terminology: 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.A DAG root is a node within the DAG that has
no outgoing edge. Because the graph is acyclic, by definition all
DAGs must have at least one DAG root and all paths terminate at a
DAG root.A DAG rooted at a
single destination, i.e. at a single DAG root (the DODAG root) with
no outgoing edges.A DODAG root is the DAG root of a DODAG.
The DODAG root may act as a border router for the DODAG, and in
particular it may aggregate routes in the DODAG, and may
redistribute DODAG routes into other routing protocols.A Virtual DODAG root is the result
of two or more RPL routers, for instance 6LoWPAN Border Routers
(6LBRs), coordinating to synchronize DODAG state and act in concert
as if they are a single DODAG root (with multiple interfaces), with
respect to the LLN. The coordination most likely occurs between
powered devices over a reliable transit link, and the details of
that scheme are out of scope for this specification (to be defined
in future companion specifications).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".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".A node's Rank defines the node's individual
position relative to other nodes with respect to a DODAG root. Rank
strictly increases in the Down direction and strictly decreases in
the Up direction. The exact way Rank is computed depends on the
DAG's Objective Function (OF). The Rank may analogously track a
simple topological distance, may be calculated as a function of link
metrics, and may consider other properties such as constraints.Defines how routing metrics,
optimization objectives, and related functions are used to compute
Rank. Furthermore, the OF dictates how parents in the DODAG are
selected and thus the DODAG formation.An identifier that
indicates which Objective Function the DODAG uses.A unique identifier within a network.
DODAGs with the same RPLInstanceID share the same Objective
Function.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.The identifier of a DODAG root. The DODAGID
is unique within the scope of a RPL Instance in the LLN. The tuple
(RPLInstanceID, DODAGID) uniquely identifies a DODAG.A specific iteration ("Version") of a
DODAG with a given DODAGID.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.The Goal is an application specific goal that is
defined outside the scope of RPL. Any node that roots a DODAG will
need to know about this Goal to decide if the Goal can be satisfied
or not. A typical Goal is to construct the DODAG according to a
specific objective function and to keep connectivity to a set of
hosts (e.g. to use an objective function that minimizes a metric and
to be connected to a specific database host to store the collected
data).A DODAG is grounded when the DODAG root can
satisfy the Goal.A DODAG is floating if it is not Grounded. A
floating DODAG is not expected to have the properties required to
satisfy the goal. It may, however, provide connectivity to other
nodes within the DODAG.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 ).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. (See
).Local DODAGs contain one and only one
root node, and allows that single root node to allocate and manage a
RPL Instance, identified by a local RPLInstanceID, without
coordination with other nodes. This is typically done in order to
optimize routes to a destination within the LLN. (See ).A Global DODAG uses a global
RPLInstanceID that may be coordinated among several other nodes.
(See ).DODAG Information Object (See )Destination Advertisement Object (See )DODAG Information Solicitation (See )Consistency Check (See )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.The aim of this section is to describe RPL in the spirit of . Protocol details can be found in further
sections.This section describes the basic RPL topologies that may be formed,
and the rules by which these are constructed, i.e. the rules governing
DODAG formation.LLNs, such as Radio Networks, do not typically have a predefined
topologies, for example those imposed by point to point wires, so
RPL has to discover links and then select peers sparingly.Because in many cases layer 2 ranges overlap only partially, RPL
forms non-transitive/NBMA network topologies upon which it computes
routes.RPL routes are optimized for traffic to or from one or more roots
that act as sinks for the topology. As a result, RPL organizes a
topology as a Directed Acyclic Graph (DAG) that is partitioned into
one or more Destination Oriented DAGS (DODAGs), one DODAG per sink.
If the DAG has multiple roots, then it is expected that the roots
are federated by a common backbone such as a transit link.RPL uses four values to identify and maintain a topology: The first is a RPLInstanceID. A RPLInstanceID identifies a
set of one or more Destination Oriented DAGs (DODAGs). A network
may have multiple RPLInstanceIDs, each of which defines an
independent set of DODAGs, which may be optimized for different
Objective Functions (OFs) and/or applications. The set of DODAGs
identified by a RPLInstanceID is called a RPL Instance. All
DODAGs in the same RPL Instance use the same OF.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.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.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.A RPL Instance contains one or more DODAG roots. A RPL Instance
may provide routes to certain destination prefixes, reachable via
the DODAG roots or alternate paths within the DODAG. These roots may
operate independently, or may coordinate over a network that is not
necessarily as constrained as a LLN.A RPL Instance may comprise:a single DODAG with a single root For example, a DODAG optimized to minimize latency rooted
at a single centralized lighting controller in a home
automation application.multiple uncoordinated DODAGs with independent roots
(differing DODAGIDs) For example, multiple data collection points in an urban
data collection application that do not have suitable
connectivity to coordinate with each other, or that use the
formation of multiple DODAGs as a means to dynamically and
autonomously partition the network.a single DODAG with a virtual root that coordinates LLN sinks
(with the same DODAGID) over a backbone network.For example, multiple border routers operating with a
reliable transit link, e.g. in support of a 6LowPAN
application, that are capable to act as logically equivalent
interfaces to the sink of the same DODAG.a combination of the above as suited to some application
scenario.Each RPL packet is associated with a particular RPLInstanceID
(see ) and therefore RPL Instance
(). The provisioning or automated
discovery of a mapping between a RPLInstanceID and a type or service
of application traffic is out of scope for this specification (to be
defined in future companion specifications). depicts an example of a RPL
Instance comprising three DODAGs with DODAG Roots R1, R2, and R3.
Each of these DODAG Roots advertises the same RPLInstanceID. The
lines depict connectivity between parents and children. depicts how a DODAG
Version number increment leads to a new DODAG Version. This
depiction illustrates a DODAG Version number increment that results
in a different DODAG topology. Note that a new DODAG Version does
not always imply a different DODAG topology. To accommodate certain
topology changes requires a new DODAG Version, as described later in
this specification.Please note that in the following examples tree-like structures
are depicted for simplicity, although the DODAG structure allows for
each node to have multiple parents when the connectivity supports
it.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.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 , 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 , , , and related companion
specifications.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.RPL also supports mechanisms which may be used for local repair
within the DODAG Version. The DIO message specifies the necessary
parameters as configured from and controlled by policy at the DODAG
root.RPL supports message confidentiality and integrity. It is
designed such that link-layer mechanisms can be used when available
and appropriate, yet in their absence RPL can use its own
mechanisms. RPL has three basic security modes.In the first, called "unsecured," RPL control messages are sent
without any additional security mechanisms. Unsecured mode does not
imply that the RPL network is unsecure: it could be using other
present security primitives (e.g. link-layer security) to meet
application security requirements.In the second, called "pre-installed," nodes joining a RPL
Instance have pre-installed keys that enable them to process and
generate secured RPL messages.The third mode is called "authenticated." In authenticated mode,
nodes have pre-installed keys as in pre-installed mode, but the
pre-installed key may only be used to join a RPL Instance as a leaf.
Joining an authenticated RPL Instance as a router requires obtaining
a key from an authentication authority. The process by which this
key is obtained is out of scope for this specification. Note that
this specification alone does not provide sufficient detail for a
RPL implementation to securely operate in authenticated mode. For a
RPL implementation to operate securely in authenticated mode it is
necessary for a future companion specification to detail the
mechanisms by which a node obtains/requests the authentication
material (e.g. key, certificate), and to determine from where that
material should be obtained. See also .DODAGs can be grounded or floating: the DODAG root advertises
which is the case. A grounded DODAG offers connectivity to hosts
that are required for satisfying the application-defined goal. A
floating DODAG is not expected to satisfy the goal and in most cases
only provides routes to nodes within the DODAG. Floating DODAGs may
be used, for example, to preserve inner connectivity during
repair.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.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.The low-power and lossy nature of LLNs motivates RPL's use of
on-demand loop detection using data packets. Because data traffic
can be infrequent, maintaining a routing topology that is constantly
up to date with the physical topology can waste energy. Typical LLNs
exhibit variations in physical connectivity that are transient and
innocuous to traffic, but that would be costly to track closely from
the control plane. Transient and infrequent changes in connectivity
need not be addressed by RPL until there is data to send. This
aspect of RPL's design draws from existing, highly used LLN
protocols as well as extensive experimental and deployment evidence
on its efficacy.The RPL Packet Information that is transported with data packets
includes the Rank of the transmitter. An inconsistency between the
routing decision for a packet (upward or downward) and the Rank
relationship between the two nodes indicates a possible loop. On
receiving such a packet, a node institutes a local repair
operation.For example, if a node receives a packet flagged as moving in the
upward direction, and if that packet records that the transmitter is
of a lower (lesser) Rank than the receiving node, then the receiving
node is able to conclude that the packet has not progressed in the
upward direction and that the DODAG is inconsistent.A high level overview of the distributed algorithm, which
constructs the DODAG, is as follows:Some nodes are configured to be DODAG roots, with associated
DODAG configurations.Nodes advertise their presence, affiliation with a DODAG,
routing cost, and related metrics by sending link-local
multicast DIO messages to all-RPL-nodes.Nodes listen for DIOs and use their information to join a new
DODAG (thus selecting DODAG parents), or to maintain an existing
DODAG, according to the specified Objective Function and Rank of
their neighbors.Nodes provision routing table entries, for the destinations
specified by the DIO message, via their DODAG parents in the
DODAG Version. Nodes that decide to join a DODAG can provision
one or more DODAG parents as the next-hop for the default route
and a number of other external routes for the associated
instance.RPL uses Destination Advertisement Object (DAO) messages to
establish downward routes. DAO messages are an optional feature for
applications that require P2MP or P2P traffic. RPL supports two modes
of downward traffic: storing (fully stateful) or non-storing (fully
source routed). Any given RPL Instance is either storing or
non-storing. In both cases, P2P packets travel Up toward a DODAG Root
then Down to the final destination (unless the destination is on the
upward route). In the non-storing case the packet will travel all the
way to a DODAG root before traveling Down. In the storing case the
packet may be directed Down towards the destination by a common
ancestor of the source and the destination prior to reaching a DODAG
Root.This specification describes a basic mode of operation in support
of P2P traffic. Note that more optimized P2P solutions may be
described in companion specifications.A RPL network can optionally support on-demand discovery of DODAGs
to specific destinations within an LLN. Such local DODAGs behave
slightly differently than global DODAGs: they are uniquely defined by
the combination of DODAGID and RPLInstanceID. The RPLInstanceID
denotes whether a DODAG is a local DODAG.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. Even though
the specific computation of the rank is left to the Objective
Function, the rank must implement generic properties regardless of the
Objective Function.In particular, the rank of the nodes must monotonically decrease as
the DODAG version is followed towards the DODAG destination. In that
regard, the rank can be regarded as a scalar representation of the
location or radius of a node within a DODAG Version.The details of how the Objective Function computes rank are out of
scope for this specification, although that computation may depend,
for example, on parents, link metrics, node metrics, and the node
configuration and policies. See for
more information.The rank is not a path cost, although its value can be derived from
and influenced by path metrics. The rank has properties of its own
that are not necessarily those of all metrics: The rank is an abstract numeric value.The rank is the expression of a relative
position within a DODAG Version with regard to neighbors and is
not necessarily a good indication or a proper expression of a
distance or a path cost to the root.The stability of the rank determines the
stability of the routing topology. Some dampening or filtering is
RECOMMENDED to keep the topology stable, and thus the rank does
not necessarily change as fast as some link or node metrics would.
A new DODAG Version would be a good opportunity to reconcile the
discrepancies that might form over time between metrics and ranks
within a DODAG Version.The rank is incremented in a strictly
monotonic fashion, and can be used to validate a progression from
or towards the root. A metric, like bandwidth or jitter, does not
necessarily exhibit this property.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.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 node's
further options with regard to DODAG parent selection and movement
within the DODAG are restricted in favor of loop avoidance.Rank may be thought of as a fixed point number, where the
position of the radix point between the integer part and the
fractional part is determined by MinHopRankIncrease.
MinHopRankIncrease is the minimum increase in rank between a node
and any of its DODAG parents. A DODAG Root provisions
MinHopRankIncrease. MinHopRankIncrease creates a tradeoff between
hop cost precision and the maximum number of hops a network can
support. A very large MinHopRankIncrease, for example, allows
precise characterization of a given hop's affect on Rank but cannot
support many hops.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:For example, if a 16-bit rank quantity is decimal 27, and the
MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) =
1. The integer part of the rank is 1 and the fractional part is
11/16.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.A node A has a rank less than the rank of a node B if DAGRank(A)
is less than DAGRank(B).A node A has a rank equal to the rank of a node B if DAGRank(A)
is equal to DAGRank(B).A node A has a rank greater than the rank of a node B if
DAGRank(A) is greater than DAGRank(B).Rank computations maintain the following properties for any nodes
M and N that are neighbors in the LLN: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.In this case the
positions of M and N within the DODAG and with respect to the
DODAG root are similar (identical). Routing through a node with
equal Rank may cause a routing loop (i.e., if that node chooses
to route through a node with equal Rank as well).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.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 ) when the metric that
an objective function minimizes is ETX, or latency, or in a more
complicated way as appropriate to the objective function being used
within the DODAG.Routing metrics are used by routing protocols to compute shortest
paths. Interior Gateway Protocols (IGPs) such as IS-IS () and OSPF ()
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.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.In addition, RPL supports constrained-based routing where
constraints may be applied to both link and nodes. If a link or a node
does not satisfy a required constraint, it is 'pruned' from the
candidate neighbor set, thus leading to a constrained shortest
path.An Objective Function specifies the objectives used to compute the
(constrained) path. Furthermore, nodes are configured to support a set
of metrics and constraints, and select their parents in the DODAG
according to the metrics and constraints advertised in the DIO
messages. Upstream and Downstream metrics may be merged or advertised
separately depending on the OF and the metrics. When they are
advertised separately, it may happen that the set of DIO parents is
different from the set of DAO parents (a DAO parent is a node to which
unicast DAO messages are sent). Yet, all are DODAG parents with
regards to the rules for Rank computation.The Objective Function is decoupled from the routing metrics and
constraints used by RPL. Indeed, whereas the OF dictates rules such as
DODAG parents selection, load balancing and so on, the set of metrics
and/or constraints used, and thus determine the preferred path, are
based on the information carried within the DAG container option in
DIO messages.The set of supported link/node constraints and metrics is specified
in .Shortest path: path offering the shortest
end-to-end delay.Shortest Constrained path: the path that
does not traverse any battery-operated node and that optimizes the
path reliability.RPL tries to avoid creating loops when undergoing topology changes
and includes rank-based datapath validation mechanisms for detecting
loops when they do occur (see for
more details). In practice, this means that RPL guarantees neither
loop free path selection nor tight delay convergence times, but can
detect and repair a loop as soon as it is used. RPL uses this loop
detection to ensure that packets make forward progress within the
DODAG Version and trigger repairs when necessary.A node is greedy if it attempts to move deeper (increase Rank) in
the DODAG Version in order to increase the size of the parent set or
improve some other metric. Once a node has joined a DODAG Version,
RPL disallows certain behaviors, including greediness, in order to
prevent resulting instabilities in the DODAG Version.Suppose a node is willing to receive and process a DIO message
from a node in its own sub-DODAG, and in general a node deeper than
itself. In this case, a possibility exists that a feedback loop is
created, wherein two or more nodes continue to try and move in the
DODAG Version while attempting to optimize against each other. In
some cases, this will result in instability. It is for this reason
that RPL limits the cases where a node may process DIO messages from
deeper nodes to some forms of local repair. This approach creates an
'event horizon', whereby a node cannot be influenced beyond some
limit into an instability by the action of nodes that may be in its
own sub-DODAG. depicts a DODAG in 3 different
configurations. A usable link between (B) and (C) exists in all 3
configurations. In -1, Node (A) is a
DODAG parent for Nodes (B) and (C). In -2, Node (A) is a DODAG parent for Nodes
(B) and (C), and Node (B) is also a DODAG parent for Node (C). In
-3, Node (A) is a DODAG parent for
Nodes (B) and (C), and Node (C) is also a DODAG parent for Node
(B).If a RPL node is too greedy, in that it attempts to optimize
for an additional number of parents beyond its most preferred
parents, then an instability can result. Consider the DODAG
illustrated in -1. In this example,
Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but
we will consider the case when they are operating under the greedy
condition that will try to optimize for 2 parents.Let -1 be the initial
condition.Suppose Node (C) first is able to leave the DODAG and
rejoin at a lower rank, taking both Nodes (A) and (B) as DODAG
parents as depicted in -2. Now
Node (C) is deeper than both Nodes (A) and (B), and Node (C)
is satisfied to have 2 DODAG parents.Suppose Node (B), in its greediness, is willing to receive
and process a DIO message from Node (C) (against the rules of
RPL), and then Node (B) leaves the DODAG and rejoins at a
lower rank, taking both Nodes (A) and (C) as DODAG parents.
Now Node (B) is deeper than both Nodes (A) and (C) and is
satisfied with 2 DAG parents.Then Node (C), because it is also greedy, will leave and
rejoin deeper, to again get 2 parents and have a lower rank
then both of them.Next Node (B) will again leave and rejoin deeper, to again
get 2 parentsAnd again Node (C) leaves and rejoins deeper...The process will repeat, and the DODAG will oscillate
between -2 and -3 until the nodes count to infinity
and restart the cycle again.This cycle can be averted through mechanisms in RPL: Nodes (B) and (C) stay at a rank sufficient to attach
to their most preferred parent (A) and don't go for any
deeper (worse) alternate parents (Nodes are not
greedy)Nodes (B) and (C) do not process DIO messages from
nodes deeper than themselves (because such nodes are
possibly in their own sub-DODAGs)These mechanisms are further described in 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.For example, consider the local repair mechanism that allows a
node to detach from the DODAG, advertise a rank of INFINITE_RANK (in
order to poison its routes / inform its sub-DODAG), and then to
re-attach to the DODAG. In that case the node may in some cases
re-attach to its own prior-sub-DODAG, causing a DODAG loop, because
the poisoning may fail if the INFINITE_RANK advertisements are lost
in the LLN environment. (In this case the rank-based datapath
validation mechanisms would eventually detect and trigger correction
of the loop).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 mitigate
the impact of DAO loops and trigger their repair. (See ).RPL supports three basic traffic flows: Multipoint-to-Point (MP2P),
Point-to-Multipoint (P2MP), and Point-to-Point (P2P).Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN
applications (, , , ). 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.Point-to-multipoint (P2MP) is a traffic pattern required by several
LLN applications (, , , ). RPL supports P2MP traffic by using a
destination advertisement mechanism that provisions Down routes toward
destinations (prefixes, addresses, or multicast groups), and away from
roots. Destination advertisements can update routing tables as the
underlying DODAG topology changes.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.RPL also supports the case where a P2P destination is a 'one-hop'
neighbor.RPL neither specifies nor precludes additional mechanisms for
computing and installing potentially more optimal routes to support
arbitrary P2P traffic.Within a given LLN, there may be multiple, logically independent RPL
instances. A RPL node may belong to multiple RPL instances, and may act
as a router in some and as a leaf in others. This document describes how
a single instance behaves.There are two types of RPL Instances: local and global. RPL divides
the RPLInstanceID space between Global and Local instances to allow for
both coordinated and unilateral allocation of RPLInstanceIDs. Global RPL
Instances are coordinated, have one or more DODAGs, and are typically
long-lived. Local RPL Instances are always a single DODAG whose singular
root owns the corresponding DODAGID and allocates the Local
RPLInstanceID in a unilateral manner. Local RPL Instances can be used,
for example, for constructing DODAGs in support of a future on-demand
routing solution. The mode of operation of Local RPL Instances is out of
scope for this specification and may be described in other companion
specifications.The definition and provisioning of RPL instances are out of scope for
this specification. Guidelines may be application and implementation
specific, and are expected to be elaborated in future companion
specifications. Those operations are expected to be such that data
packets coming from the outside of the RPL network can unambiguously be
associated to at least one RPL instance, and be safely routed over any
instance that would match the packet.Control and data packets within RPL network are tagged to
unambiguously identify what RPL Instance they are part of.Every RPL control message has a RPLInstanceID field. Some RPL control
messages, when referring to a local RPLInstanceID as defined below, may
also include a DODAGID.Data packets that flow within the RPL network expose the
RPLInstanceID as part of the RPL Packet Information that RPL requires,
as further described in . For data
packets coming from outside the RPL network, the ingress router
determines the RPLInstanceID and places it into the resulting packet
that it injects into the RPL network.A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms
for allocating and provisioning global RPLInstanceID are out of scope
for this specification. There can be up to 128 global instance in the
whole network. Local instances are always used in conjunction with a
DODAGID (which is either given explicitly or implicitly in some
cases), and up 64 local instances per DODAGID can be supported. Local
instances are allocated and managed by the node that owns the DODAGID,
without any explicit coordination with other nodes, as further
detailed below.A global RPLinstanceID is encoded in a RPLinstanceID field as
follows: A local RPLInstanceID is autoconfigured by the node that owns the
DODAGID and it MUST be unique for that DODAGID. The DODAGID used to
configure the local RPLInstanceID MUST be a reachable IPv6 address of
the node, and MUST be used as an endpoint of all communications within
that local instance.A local RPLinstanceID is encoded in a RPLinstanceID field as
follows: The D flag in a Local RPLInstanceID is always set to 0 in RPL
control messages. It is used in data packets to indicate whether the
DODAGID is the source or the destination of the packet. If the D flag
is set to 1 then the destination address of the IPv6 packet MUST be
the DODAGID. If the D flag is cleared then the source address of the
IPv6 packet MUST be the DODAGID.For example, consider a node A that is the DODAG Root of a local
RPL Instance, and has allocated a local RPLInstanceID. By definition,
all traffic traversing that local RPL Instance will either originate
or terminate at node A. The DODAGID in this case will be the reachable
IPv6 address of node A, and all traffic will contain the address of
node A, thus the DODAGID, in either the source or destination address.
Thus the Local RPLInstanceID may indicate that the DODAGID is
equivalent to either the source address or the destination address by
setting the D flag appropriately.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.Most RPL Control Message have the scope of a link. The only exception
is for the DAO / DAO-ACK messages in non-storing mode, which are
exchanged using a unicast address over multiple hops and thus uses
global or unique-local addresses for both the source and destination
addresses. For all other RPL Control messages, the source address is a
link-local address, and the destination address is either the
all-RPL-nodes multicast address or a link-local unicast address of the
destination. The all-RPL-nodes multicast address is a new address with a
requested value of FF02::1A (to be confirmed by IANA).In accordance with , 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 .The RPL Control message is an ICMPv6 information message with a
requested Type of 155 (to be confirmed by IANA).The Code field identifies the type of RPL Control Message. This
document defines codes for the following RPL Control Message types (all
codes are to be confirmed by IANA ):0x00: DODAG Information Solicitation ()0x01: DODAG Information Object ()0x02: Destination Advertisement Object ()0x03: Destination Advertisement Object Acknowledgment ()0x80: Secure DODAG Information Solicitation ()0x81: Secure DODAG Information Object ()0x82: Secure Destination Advertisement Object ()0x83: Secure Destination Advertisement Object Acknowledgment
()0x8A: Consistency Check ()If a node receives a RPL control message with an unknown Code field,
the node MUST discard the message without any further processing, MAY
raise a management alert, and MUST NOT send any messages in
response.The checksum is computed as specified in . It is set to zero for the RPL security
operations specified below, and computed once the rest of the content of
the RPL message including the security fields is all set.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 .The remainder of this section describes the currently defined RPL
Control Message Base formats followed by the currently defined RPL
Control Message Options.Each RPL message has a secure variant. The secure variants provide
integrity and replay protection as well as optional confidentiality
and delay protection. Because security covers the base message as well
as options, in secured messages the security information lies between
the checksum and base, as shown in .The level of security and the algorithms in use are indicated in
the protocol messages as described below:Message authentication codes (MACs) and signatures provide
authentication over the entire unsecured ICMPv6 RPL control message,
including the Security section with all fields defined, but with the
ICMPv6 checksum temporarily set to zero. Encryption provides
confidentiality of the secured RPL ICMPv6 message starting at the
first byte after the Security section and continuing to the last byte
of the packet. The security transformation yields a secured ICMPv6 RPL
message with the inclusion of the cryptographic fields (MAC,
signature, etc.). In other words, the security transformation itself
(e.g. the Signature and/or Algorithm in use) will detail how to
incorporate the cryptographic fields into the secured packet. The
Security section itself does not explicitly carry those cryptographic
fields. Use of the Security section is further detailed in and .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. describes the details of the 'T'
flag and Counter field.7-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.The Security
Algorithm field specifies the encryption, MAC, and signature
scheme the network uses. Supported values of this field are as
follows: describes the
algorithms in greater detail.The Key Identifier Mode
is a 2-bit field that 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 values from the table below:
In Mode 3 (KIM=11), the presence or absence of the Key
Source and Key Identifier depends on the Security Level (LVL)
described below. If the Security Level indicates there is
encryption, then the fields are present; if it indicates there is
no encryption, then the fields are not present.3-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.The Security Level is a 3-bit
field that indicates the provided packet protection. This value
can be adapted on a per-packet basis and allows for varying levels
of data authenticity and, optionally, for data confidentiality.
The KIM field indicates whether signatures are used and the
meaning of the Level field. Note that the assigned values of
Security Level are not necessarily ordered-- a higher value of LVL
does not necessarily equate to increased security. The Security
Level is set to one of the values in the tables below: The MAC attribute indicates that the message has a
Message Authentication Code of the specified length. The ENC
attribute indicates that the message is encrypted. The Sign
attribute indicates that the message has a signature of the
specified length.8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.The Counter field indicates the
non-repeating 4-octet value (nonce) used with the cryptographic
mechanism that implements packet protection and allows for the
provision of semantic security.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: 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.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.Unassigned bits of the Security section are reserved. They MUST be
set to zero on transmission and MUST be ignored on reception.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. describes how
nodes respond to a DIS.8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.8-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.Unassigned bits of the DIS Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.A Secure DIS message follows the format in , where the base format is
the DIS message shown in .The DIS message MAY carry valid options.This specification allows for the DIS message to carry the
following options: 0x00 Pad10x01 PadN0x07 Solicited InformationThe DODAG Information Object carries information that allows a node
to discover a RPL Instance, learn its configuration parameters, select
a DODAG parent set, and maintain the DODAG.The Grounded (G) flag indicates
whether the DODAG advertised can satisfy the application-defined
goal. If the flag is set, the DODAG is grounded. If the flag is
cleared, the DODAG is floating.The Mode of Operation
(MOP) field identifies the mode of operation of the RPL Instance
as administratively provisioned at and distributed by the DODAG
Root. All nodes who join the DODAG must be able to honor the MOP
in order to fully participate as a router, or else they must
only join as a leaf. MOP is encoded as in the figure
below:A value of 0 indicates that destination
advertisement messages are disabled and the DODAG maintains
only upward routesA 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). describes how DAGPreference
affects DIO processing.8-bit unsigned integer set by the
DODAG root to the DODAGVersionNumber. describes the rules for DODAG
Version numbers and how they affect DIO processing.16-bit unsigned integer indicating the DODAG
rank of the node sending the DIO message. describes how Rank is set and how
it affects DIO processing.8-bit field set by the DODAG root
that indicates which RPL Instance the DODAG is part of.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 .8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.8-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.128-bit IPv6 address set by a DODAG root
which uniquely identifies a DODAG. The DODAGID MUST be a
routable IPv6 address belonging to the DODAG root.Unassigned bits of the DIO Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.A Secure DIO message follows the format in , where the base format is
the DIO message shown in .The DIO message MAY carry valid options.This specification allows for the DIO message to carry the
following options: 0x00 Pad10x01 PadN0x02 Metric Container0x03 Routing Information0x04 DODAG Configuration0x08 Prefix InformationThe Destination Advertisement Object (DAO) is used to propagate
destination information upwards along the DODAG. In storing mode the
DAO message is unicast by the child to the selected parent(s). In
non-storing mode the DAO message is unicast to the DODAG root. The DAO
message may optionally, upon explicit request or error, be
acknowledged by its destination with a Destination Advertisement
Acknowledgement (DAO-ACK) message back to the sender of the DAO.The '*' denotes that the DODAGID is not always
present, as described below.8-bit field indicating the topology
instance associated with the DODAG, as learned from the DIO.The 'K' flag indicates that the recipient is
expected to send a DAO-ACK back. (See The 'D' flag indicates that the DODAGID field
is present. This flag MUST be set when a local RPLInstanceID is
used.6-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.8-bit unused field. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.Incremented at each unique DAO
message from a node and echoed in the DAO-ACK message.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.Unassigned bits of the DAO Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.A Secure DAO message follows the format in , where the base format is
the DAO message shown in .The DAO message MAY carry valid options.This specification allows for the DAO message to carry the
following options: 0x00 Pad10x01 PadN0x05 RPL Target0x06 Transit Information0x09 RPL Target DescriptorA special case of the DAO message, termed a No-Path, is used in
storing mode to clear downward routing state that has been
provisioned through DAO operation. The No-Path carries a Target
option and an associated Transit Information option with a lifetime
of 0x00000000 to indicate a loss of reachability to that Target.The DAO-ACK message is sent as a unicast packet by a DAO recipient
(a DAO parent or DODAG root) in response to a unicast DAO message.The '*' denotes that the DODAGID is not always
present, as described below.8-bit field indicating the topology
instance associated with the DODAG, as learned from the DIO.The 'D' flag indicates that the DODAGID field
is present. This would typically only be set when a local
RPLInstanceID is used.7-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.Incremented at each DAO message from
a node, and echoed in the DAO-ACK by the recipient. The
DAOSequence is used to correlate a DAO message and a DAO ACK
message and is not to be confused with the Transit Information
option Path Sequence that is associated to a given target Down
the DODAG.Indicates the completion. Status 0 is
unqualified acceptance, 1 to 127 are unassigned and
undetermined, and 128 and greater are rejection codes used to
indicate that the node should select an alternate parent. This
specification does not define any rejection codes.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.Unassigned bits of the DAO-ACK Base are reserved. They MUST be
set to zero on transmission and MUST be ignored on reception.A Secure DAO-ACK message follows the format in , where the base format is
the DAO-ACK message shown in .This specification does not define any options to be carried by
the DAO-ACK message.The CC message is used to check secure message counters and issue
challenge/responses. A CC message MUST be sent as a secured RPL
message.8-bit field indicating the topology
instance associated with the DODAG, as learned from the DIO.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.7-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.16-bit unsigned integer set by a CC
request. The corresponding CC response includes the same nonce
value as the request.32-bit unsigned integer value
indicating the sender's estimate of the destination's current
security Counter value. If the sender does not have an estimate,
it SHOULD set the Destination Counter field to zero.Unassigned bits of the CC Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.The Destination Counter value allows new or recovered nodes to
resynchronize through CC message exchanges. This is important to
ensure that a Counter value is not repeated for a given security key
even in the event of devices recovering from a failure that created
a loss of Counter state. For example, where a CC request or other
RPL message is received with an initialized Counter within the
message security section, the provision of the Incoming Counter
within the CC response message allows the requesting node to reset
its Outgoing Counter to a value greater than the last value received
by the responding node; the Incoming Counter will also be updated
from the received CC response.This specification allows for the CC message to carry the
following options: 0x00 Pad10x01 PadNRPL Control Message Options all follow this format: 8-bit identifier of the type of
option. The Option Type values are to be confirmed by IANA .8-bit unsigned integer,
representing the length in octets of the option, not including
the Option Type and Length fields.A variable length field that contains
data specific to the option.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.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).The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
messages, and its format is as follows:The Pad1 option is used to insert a single octet 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.NOTE! the format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields.The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
messages, and its format is as follows: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.0x01 (to be confirmed by IANA)For N octets of padding, where 2
<= N <= 7, the Option Length field contains the value N-2.
An Option Length of 0 indicates a total padding of 2 octets. An
Option Length of 5 indicates a total padding of 7 octets, which
is the maximum padding size allowed with the PadN option.For N (N > 1) octets of padding,
the Option Data consists of N-2 zero-valued octets.The Metric Container option MAY be present in DIO or DAO
messages, and its format is as follows: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 as chosen by the
implementer.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 .The processing and propagation of the Metric Container is
governed by implementation specific policy functions.0x02 (to be confirmed by IANA)The Option Length field contains
the length in octets of the Metric Data.The order, content, and coding of the
Metric Container data is as specified in .The Route Information option MAY be present in DIO messages, and
carries the same information as the IPv6 Neighbor Discovery (ND)
Route Information option as defined in . The root of a DODAG is authoritative for
setting that information and the information is unchanged as
propagated down the DODAG. A RPL router may trivially transform it
back into a ND option to advertise in its own RAs so a node attached
to the RPL router will end up using the DODAG for which the root has
the best preference for the destination of a packet. In addition to
the existing ND semantics, it is possible for an Objective function
to use this information to favor a DODAG which root is most
preferred for a specific destination. The format of the option is
modified slightly (Type, Length, Prefix) in order to be carried as a
RPL option as follows:The Route Information option is used to indicate that
connectivity to the specified destination prefix is available from
the DODAG root.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. should be consulted as the
authoritative reference with respect to the Route Information
option. The field descriptions are transcribed here for
convenience:0x03 (to be confirmed by IANA)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.8-bit unsigned integer. The number
of leading bits in the Prefix that are valid. The value ranges
from 0 to 128. The Prefix field has the number of bytes inferred
from the Option Length field, that must be at least the Prefix
Length. Note that in RPL this means that the Prefix field may
have lengths other than 0, 8, or 16.2-bit signed integer. The Route Preference
indicates whether to prefer the router associated with this
prefix over others, when multiple identical prefixes (for
different routers) have been received. If the Reserved (10)
value is received, the Route Information Option MUST be ignored.
As per , the Reserved (10) value
MUST NOT be sent. ( restricts the
Preference to just three values to reinforce that it is not a
metric).Two 3-bit unused fields. They MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.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.Variable-length field containing an IP
address or a prefix of an IPv6 address. The Prefix Length field
contains the number of valid leading bits in the prefix. The
bits in the prefix after the prefix length (if any) are reserved
and MUST be initialized to zero by the sender and ignored by the
receiver. Note that in RPL this field may have lengths other
than 0, 8, or 16.Unassigned bits of the Route Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.The DODAG Configuration option MAY be present in DIO messages,
and its format is as follows:The DODAG Configuration option is used to distribute
configuration information for DODAG Operation through the DODAG.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.0x04 (to be confirmed by IANA)144-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.One bit flag
describing the security mode of the network. The bit describe
whether a node must authenticate with a key authority before
joining the network as a router. If the DIO is not a secure DIO,
the 'A' bit MUST be zero.3-bit unsigned integer
used to configure the number of bits that may be allocated to
the Path Control field (see ).
Note that when PCS is consulted to determine the width of the
Path Control field a value of 1 is added, i.e. a PCS value of 0
results in 1 active bit in the Path Control field. The default
value of PCS is DEFAULT_PATH_CONTROL_SIZE.8-bit unsigned integer used
to configure Imax of the DIO trickle timer (see ). The default value of
DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.8-bit unsigned integer used to
configure Imin of the DIO trickle timer (see ). The default value of
DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.8-bit unsigned integer used
to configure k of the DIO trickle timer (see ). The default value of
DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT.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.16-bit unsigned integer used to
configure MinHopRankIncrease as described in . The default value of
MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE.8-bit unsigned integer. This is
the lifetime that is used as default for all RPL routes. It is
expressed in units of Lifetime Units, e.g. the default lifetime
in seconds is (Default Lifetime) * (Lifetime Unit).16-bit unsigned integer. Provides
the unit in seconds that is used to express route lifetimes in
RPL. For very stable networks, it can be hours to days.16-bit unsigned
integer. The OCP field identifies the OF and is managed by the
IANA.The RPL Target option MAY be present in DAO messages, and its
format is as follows:The RPL Target Option is used to indicate a target IPv6 address,
prefix, or multicast group that is reachable or queried along the
DODAG. In a DAO, the RPL Target option indicates reachability.A RPL Target Option May optionally be paired with a RPL Target
Descriptor Option () that
qualifies the target.A set of one or more Transit Information options () MAY directly follow a set of
one or more Target option in a DAO message (where each Target Option
MAY be paired with a RPL Target Descriptor Option as above). The
structure of the DAO message, detailing how Target options are used
in conjunction with Transit Information options, is further
described in .The RPL Target option may be repeated as necessary to indicate
multiple targets.0x05 (to be confirmed by IANA)Variable, length of the option in
octets excluding the Type and Length fields.8-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.8-bit unsigned integer. Number of
valid leading bits in the IPv6 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.The Transit Information option MAY be present in DAO messages,
and its format is as follows:The '*' denotes that the Parent Address is not always
present, as described below.The Transit Information option is used for a node to indicate
attributes for a path to one or more destinations. The destinations
are indicated by one or more Target options that immediately precede
the Transit Information option(s).The Transit Information option can be used for a node to indicate
its DODAG parents to an ancestor that is collecting DODAG routing
information, typically for the purpose of constructing source
routes. In the non-storing mode of operation this ancestor will be
the DODAG Root, and this option is carried by the DAO message. In
the storing mode of operation the Parent Address is not needed,
since the DAO message is sent directly to the parent. The option
length is used to determine whether the Parent Address is present or
not.A non-storing node that has more than one DAO parent MAY include
a Transit Information option for each DAO parent as part of the
non-storing destination advertisement operation. The node may
distribute the bits in the Path Control field among different groups
of DAO parents in order to signal a preference among parents. That
preference may influence the decision of the DODAG root when
selecting among the alternate parents/paths for constructing
downward routes.One or more Transit Information options MUST be preceded by one
or more RPL Target options. In this manner the RPL Target option
indicates the child node, and the Transit Information option(s)
enumerate the DODAG parents. The structure of the DAO message,
further detailing how Target options are used in conjunction with
Transit Information options, is further described in .A typical non-storing node will use multiple Transit Information
options, and it will send the DAO message thus formed directly to
the root. A typical storing node will use one Transit Information
option with no parent field, and will send the DAO message thus
formed, with additional adjustments to Path Control as detailed
later, to one or multiple parents.For example, in a non-storing mode of operation let Tgt(T) denote
a Target option for a target T. Let Trnst(P) denote a Transit
Information option that contains a parent address P. Consider the
case of a non-storing node N that advertises the self-owned targets
N1 and N2 and has parents P1, P2, and P3. In that case the DAO
message would be expected to contain the sequence ( (Tgt(N1),
Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3)) ), such that the group
of Target options {N1, N2} are described by the Transit Information
options as having the parents {P1, P2, P3}. The non-storing node
would then address that DAO message directly to the DODAG root, and
forward that DAO message through one of the DODAG parents P1, P2, or
P3.0x06 (to be confirmed by IANA)Variable, depending on whether or
not Parent Address is present.1-bit flag. The 'E' flag is set to
indicate that the parent router redistributes external targets
into the RPL network. An external target is a target that has
been learned through an alternate protocol. The external targets
are listed in the target options that immediately precede the
Transit Information option. An external target is not expected
to support RPL messages and options.7-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.8-bit bitfield. The Path Control
field limits the number of DAO-Parents to which a DAO message
advertising connectivity to a specific destination may be sent,
as well as providing some indication of relative preference. The
limit provides some bound on overall DAO message fan-out in the
LLN. The assignment and ordering of the bits in the path control
also serves to communicate preference. Not all of these bits may
be enabled as according to the PCS in the DODAG Configuration.
The Path Control field is divided into four subfields which
contain two bits each: PC1, PC2, PC3, and PC4, as illustrated in
. The subfields are
ordered by preference, with PC1 being the most preferred and PC4
being the least preferred. Within a subfield there is no order
of preference. By grouping the parents (as in ECMP) and ordering
them, the parents may be associated with specific bits in the
Path Control field in a way that communicates preference.
8-bit unsigned integer. When a RPL
Target option is issued by the node that owns the Target Prefix
(i.e. in a DAO message), that node sets the Path Sequence and
increments the Path Sequence each time it issues a RPL Target
option with updated information.8-bit unsigned integer. The length
of time in Lifetime Units (obtained from the Configuration
option) that the prefix is valid for route determination. The
period starts when a new Path Sequence is seen. A value of all
one bits (0xFF) represents infinity. A value of all zero bits
(0x00) indicates a loss of reachability. A DAO message that
contains a Transit Information option with a Path Lifetime of
0x00 for a Target is referred as a No-Path (for that Target) in
this document.IPv6 Address of the
DODAG Parent of the node originally issuing the Transit
Information Option. This field may not be present, as according
to the DODAG Mode of Operation (storing or non-storing) and
indicated by the Transit Information option length.Unassigned bits of the Transit Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.The Solicited Information option MAY be present in DIS messages,
and its format is as follows:The Solicited Information option is used for a node to request
DIO messages from a subset of neighboring nodes. The Solicited
Information option may specify a number of predicate criteria to be
matched by a receiving node. This is used by the requester to limit
the number of replies from "non-interesting" nodes. These predicates
affect whether a node resets its DIO trickle timer, as described in
.The Solicited Information option contains flags that indicate
which predicates a node should check when deciding whether to reset
its Trickle timer. A node resets its Trickle timer when all
predicates are true. If a flag is set, then the RPL node MUST check
the associated predicate. If a flag is cleared, then the RPL node
MUST NOT check the associated predicate. (If a flag is cleared, the
RPL node assumes that the associated predicate is true).0x07 (to be confirmed by IANA)19The V flag is the Version predicate. The
Version predicate is true if the receiver's DODAGVersionNumber
matches the requested Version Number. If the V flag is cleared
then the Version field is not valid and the Version field MUST
be set to zero on transmission and ignored upon receipt.The I flag is the InstanceID predicate. The
InstanceID predicate is true when the RPL node's current
RPLInstanceID matches the requested RPLInstanceID. If the I flag
is cleared then the RPLInstanceID field is not valid and the
RPLInstanceID field MUST be set to zero on transmission and
ignored upon receipt.The D flag is the DODAGID predicate. The
DODAGID predicate is true if the RPL node's parent set has the
same DODAGID as the DODAGID field. If the D flag is cleared then
the DODAGID field is not valid and the DODAGID field MUST be set
to zero on transmission and ignored upon receipt.5-bit unused field reserved for flags. The
field MUST be initialized to zero by the sender and MUST be
ignored by the receiver.8-bit unsigned integer containing
the value of DODAGVersionNumber that is being solicited when
valid.8-bit unsigned integer containing
the RPLInstanceID that is being solicited when valid.128-bit unsigned integer containing the
DODAGID that is being solicited when valid.Unassigned bits of the Solicited Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.The Prefix Information option MAY be present in DIO messages, and
carries the information that is specified for the IPv6 ND Prefix
Information Option in , and for use
by RPL nodes and IPv6 hosts. In particular, a RPL node may use this
option for the purpose of State-Less Address Auto-Configuration
(SLAAC) from a prefix advertised by a parent as specified in , and advertise its own address as specified
in . The root of a DODAG is
authoritative for setting that information. The information is
propagated down the DODAG unchanged, with the exception that a RPL
router may update (extend) the prefix by appending it's own suffix.
The format of the option is modified (Type, Length, Prefix) in order
to be carried as a RPL option as follows:The Prefix Information option may be used to distribute the
prefix in use inside the DODAG, e.g. for address
autoconfiguration. and
should be consulted as the authoritative reference with respect to
the Prefix Information option. The field descriptions are
transcribed here for convenience:0x08 (to be confirmed by IANA)30. Note that this length is
expressed in units of single-octets, unlike in IPv6 ND.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 , for which there may be more
restrictions on the prefix length.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 RPL node 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. A RPL node acting as a
router MUST NOT propagate a PIO with the L flag set. A RPL node
acting as a router MAY propagate a PIO with the L flag not
set.1-bit autonomous address-configuration flag.
When set indicates that this prefix can be used for stateless
address configuration as specified in . When both protocols (ND RAs and RPL
DIOs) are used to carry PIOs on the same link, it is possible to
use either one for SLAAC by a RPL node. It is also possible to
make either protocol ineligible for SLAAC operation by forcing
the A flag to 0 for PIOs carried in that protocol.1-bit Router address flag. When set, indicates
that the Prefix field contains a complete IPv6 address assigned
to the sending router that can be used as parent in a target
option. The indicated prefix is the first Prefix Length bits of
the Prefix field. The router IPv6 address has the same scope and
conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits.5-bit unused field. It MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.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 .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 . A value of all one bits (0xffffffff)
represents infinity. See . Note
that the value of this field MUST NOT exceed the Valid Lifetime
field to avoid preferring addresses that are no longer
valid.This field is unused. It MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.An IPv6 address or a prefix of an IPv6
address. The Prefix Length field contains the number of valid
leading bits in the prefix. The bits in the prefix after the
prefix length are reserved and MUST be initialized to zero by
the sender and ignored by the receiver. A router SHOULD NOT send
a prefix option for the link-local prefix and a host SHOULD
ignore such a prefix option. A non-storing node SHOULD refrain
from advertising a prefix till it owns an address of that
prefix, and then it SHOULD advertise its full address in this
field, with the 'R' flag set. The children of a node that so
advertises a full address with the 'R' flag set may then use
that address to determine the content of the Parent Address
field of the Transit Information Option.Unassigned bits of the Prefix Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.The RPL Target option MAY be immediately followed by one opaque
descriptor that qualifies that specific target.The RPL Target Descriptor Option is used to qualify a target,
something that is sometimes called tagging.There can be at most one descriptor per target. The descriptor is
set by the node that injects the target in the RPL network. It MUST
be copied but not modified by routers that propagate the target Up
the DODAG in DAO messages.0x09 (to be confirmed by IANA)432-bit unsigned integer. Opaque.This section describes the general scheme for bootstrap and operation
of sequence counters in RPL, such as the DODAGVersionNumber in the DIO
message, the DAOSequence in the DAO message, and the Path Sequence in
the Transit Information option.This specification utilizes three different sequence numbers to
validate the freshness and the synchronization of protocol
information:This sequence counter is
present in the DIO base to indicate the Version of the DODAG being
formed. The DODAGVersionNumber is monotonically incremented by the
root each time the root decides to form a new Version of the DODAG
in order to revalidate the integrity and allow a global repairs to
occur. The DODAGVersionNumber is propagated unchanged Down the
DODAG as routers join the new DODAG Version. The
DODAGVersionNumber is globally significant in a DODAG and
indicates the Version of the DODAG that a router is operating in.
An older (lesser) value indicates that the originating router has
not migrated to the new DODAG Version and can not be used as a
parent once the receiving node has migrated to the newer DODAG
Version.This sequence counter is present in
the DAO base to correlate a DAO message and a DAO ACK message. The
DAOSequence number is locally significant to the node that issues
a DAO message for its own consumption to detect the loss of a DAO
message and enable retries.This sequence counter is present in
the Transit Information option in a DAO message. The purpose of
this counter is to differentiate a movement where a newer route
supersedes a stale one from a route redundancy scenario where
multiple routes exist in parallel for a same target. The Path
Sequence is globally significant in a DODAG and indicates the
freshness of the route to the associated target. An older (lesser)
value received from an originating router indicates that the
originating router holds stale routing states and the originating
router should not be considered anymore as a potential next-hop
for the target. The Path Sequence is computed by the node that
advertises the target, that is the target itself or a router that
advertises a target on behalf of a host, and is unchanged as the
DAO content is propagated towards the root by parent routers. If a
host does not pass a counter to its router, then the router is in
charge of computing the Path Sequence on behalf of the host and
the host can only register to one router for that purpose. If a
DAO message containing a same target is issued to multiple parents
at a given point of time for the purpose of route redundancy, then
the Path Sequence is the same in all the DAO messages for that
same target.RPL sequence counters are subdivided in a 'lollipop' fashion (), where the values from 128 and greater are
used as a linear sequence to indicate a restart and bootstrap the
counter, and the values less than or equal to 127 used as a circular
sequence number space of size 128 as in . Consideration is given to the mode of
operation when transitioning from the linear region to the circular
region. Finally, when operating in the circular region, if sequence
numbers are detected to be too far apart then they are not comparable,
as detailed below.A window of comparison, SEQUENCE_WINDOW = 16, is configured based
on a value of 2^N, where N is defined to be 4 in this
specification.For a given sequence counter, The sequence counter SHOULD be initialized to an implementation
defined value which is 128 or greater prior to use. A recommended
value is 240 (256 - SEQUENCE_WINDOW).When a sequence counter increment would cause the sequence
counter to increment beyond its maximum value, the sequence
counter MUST wrap back to zero. When incrementing a sequence
counter greater than or equal to 128, the maximum value is 255.
When incrementing a sequence counter less than 128, the maximum
value is 127.When comparing two sequence counters, the following rules MUST
be applied: When a first sequence counter A is in the interval
[128..255] and a second sequence counter B is in [0..127]:
If (256 + B - A) is less than or equal to
SEQUENCE_WINDOW, then B is greater than A, A is less than
B, and the two are not equal.If (256 + B - A) is greater than SEQUENCE_WINDOW, then
A is greater than B, B is less than A, and the two are not
equal. For example, if A is 240, and B is 5, then (256 + 5
- 240) is 21. 21 is greater than SEQUENCE_WINDOW (16), thus
240 is greater than 5. As another example, if A is 250 and B
is 5, then (256 + 5 - 250) is 11. 11 is less than
SEQUENCE_WINDOW (16), thus 250 is less than 5.In the case where both sequence counters to be compared are
less than or equal to 127, and in the case where both sequence
counters to be compared are greater than or equal to 128:If the absolute magnitude of difference between the two
sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in is used to determine the
relationships greater than, less than, and equal.If the absolute magnitude of difference of the two
sequence counters is greater than SEQUENCE_WINDOW, then a
desynchronization has occurred and the two sequence
numbers are not comparable.If two sequence numbers are determined to be not comparable,
i.e. the results of the comparison are not defined, then a node
should consider the comparison as if it has evaluated in such a
way so as to give precedence to the sequence number that has most
recently been observed to increment. Failing this, the node should
consider the comparison as if it has evaluated in such a way so as
to minimize the resulting changes to its own state.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.As mentioned in , nodes that decide to
join a DODAG MUST provision at least one DODAG parent as a default route
for the associated instance. This default route enables a packet to be
forwarded upwards until it eventually hits a common ancestor from which
it will be routed downwards to the destination. If the destination is
not in the DODAG, then the DODAG root may be able to forward the packet
using connectivity to the outside of the DODAG; if it can not forward
the packet outside then the DODAG root has to drop it.A DIO message can also transport explicit routing information: The DODAGID is a Global or Unique Local IPv6
Address of the root. A node that joins a DODAG SHOULD provision a
host route via a DODAG parent to the address used by the root as
DODAGID.The root MAY place one or more Route
Information options in a DIO message. The RIO is used to advertise
an external route that is reachable via the root, associated with a
preference, as presented in , which
incorporates the RIO from . It is
interpreted as a capability of the root as opposed to a routing
advertisement and it MUST NOT be redistributed in another routing
protocol though it SHOULD be used by an ingress RPL router to select
a DODAG when a packet is injected in a RPL domain from a node
attached to that RPL router. An Objective Function MAY use the
routes advertised in RIO or the preference for those routes in order
to favor a DODAG versus another one for a same instance.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 ). In this way these
values will propagate Down the DODAG unchanged and advertised by
every node that has a route to that DODAG root. These fields are:
Grounded (G)Mode of Operation (MOP)DAGPreference (Prf)VersionRPLInstanceIDDODAGIDA node MAY update the following fields at each hop: RankDTSNThe DODAGID field each root sets MUST be unique within the RPL
Instance and MUST be a routable IPv6 address belonging to the
root.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.RPL's upward route discovery algorithms and processing are in
terms of three logical sets of link-local nodes. First, the
candidate neighbor set is a subset of the nodes that can be reached
via link-local multicast. The selection of this set is
implementation-dependent and OF-dependent. Second, the parent set is
a restricted subset of the candidate neighbor set. Finally, the
preferred parent is a member of the parent set that is the preferred
next hop in upward routes. The preferred parent is conceptually a
single parent although it may be a set of multiple parents if those
parents are equally preferred and have identical rank.More precisely: The DODAG parent set MUST be a subset of the candidate
neighbor set.A DODAG root MUST have a DODAG parent set of size zero.A node that is not a DODAG root MAY maintain a DODAG parent
set of size greater than or equal to one.A node's preferred DODAG parent MUST be a member of its DODAG
parent set.A node's rank MUST be greater than all elements of its DODAG
parent set.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.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.The OF can guide candidate neighbor set and parent set selection,
as discussed in .The above rules govern a single DODAG Version. The rules in this
section define how RPL operates when there are multiple DODAG
Versions: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.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.A node MUST NOT send DIOs for DODAG Versions of which it is
not a member.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 . Events triggering the
increment of the DODAGVersionNumber are described later in
this section and in .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 .Once a node has advertised a DODAG Version by sending a
DIO, it MUST NOT be a member of a previous DODAG Version of
the same DODAG (i.e. with the same RPLInstanceID, the same
DODAGID, and a lower DODAGVersionNumber). Lower is defined as
the less-than operator in .When the DODAG parent set becomes empty on a node that is not a
root, (i.e. the last parent has been removed, causing the node to
no longer be associated with that DODAG), then the DODAG
information should not be suppressed until after the expiration of
an implementation-specific local timer in order to observe if the
DODAGVersionNumber has been incremented, should any new parents
appear for the DODAG. This will help protect against the
possibility of loops that may occur if that node were to
inadvertently rejoin the old DODAG Version in its own prior
sub-DODAG.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.For example, suppose that a node has left a DODAG with
DODAGVersionNumber N. Suppose that node had a sub-DODAG, and did
attempt to poison that sub-DODAG by advertising a rank of
INFINITE_RANK, but those advertisements may have become lost in
the LLN. Then, if the node did observe a candidate neighbor
advertising a position in that original DODAG at
DODAGVersionNumber N, that candidate neighbor could possibly have
been in the node's former sub-DODAG and there is a possible case
where to add that candidate neighbor as a parent could cause a
loop. If that candidate neighbor in this case is observed to
advertise a DODAGVersionNumber N+1, then that candidate neighbor
is certain to be safe, since it is certain not to be in that
original node's sub-DODAG as it has been able to increment the
DODAGVersionNumber by hearing from the DODAG root while that
original node was detached. It is for this reason that it is
useful for the detached node to remember the original DODAG
information, including the DODAGVersionNumber N.Exactly when a DODAG Root increments the DODAGVersionNumber is
implementation dependent and out of scope for this specification.
Examples include incrementing the DODAGVersionNumber periodically,
upon administrative intervention, or on application-level
detection of lost connectivity or DODAG inefficiency.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.A DODAG root without possibility to satisfy the
application-defined goal MUST NOT set the Grounded bit.A DODAG root MUST advertise a rank of ROOT_RANK.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.In a deployment that uses non-RPL links to federate a number of
LLN roots, it is possible to run RPL over those non-RPL links and
use one router as a "backbone root". The backbone root is the
virtual root of the DODAG, and exposes a rank of BASE_RANK over
the backbone. All the LLN roots that are parented to that backbone
root, including the backbone root if it also serves as LLN root
itself, expose a rank of ROOT_RANK to the LLN. These virtual roots
are part of the same DODAG and advertise the same DODAGID. They
coordinate DODAGVersionNumbers and other DODAG parameters with the
virtual root over the backbone. The method of coordination is out
of scope for this specification (to be defined in future companion
specifications).The objective function and the set of advertised routing
metrics and constraints of a DAG determines how a node selects its
neighbor set, parent set, and preferred parents. This selection
implicitly also determines the DODAG within a DAG. Such selection
can include administrative preference (Prf) as well as metrics or
other considerations.If a node has the option to join a more preferred DODAG while
still meeting other optimization objectives, then the node will
generally seek to join the more preferred DODAG as determined by
the OF. All else being equal, it is left to the implementation to
determine which DODAG is most preferred (since, as a reminder, a
node must only join one DODAG per RPL Instance).A node MUST NOT advertise a Rank less than or equal to any
member of its parent set within the DODAG Version.A node MAY advertise a Rank lower than its prior
advertisement within the DODAG Version.Let L be the lowest rank within a DODAG Version that a
given node has advertised. Within the same DODAG Version, that
node MUST NOT advertise an effective rank higher than L +
DAGMaxRankIncrease. INFINITE_RANK is an exception to this
rule: a node MAY advertise an INFINITE_RANK within a DODAG
version without restriction. If a node's Rank were to be
higher than allowed by L + DAGMaxRankIncrease, when it
advertises Rank it MUST advertise its Rank as
INFINITE_RANK.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.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.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.When a node migrates to the next DODAG Version, the DODAG
parent set needs to be rebuilt for the new Version. An
implementation could defer to migrate for some reasonable amount
of time, to see if some other neighbors with potentially better
metrics but higher rank announce themselves. Similarly, when a
node jumps into a new DODAG it needs to construct a new DODAG
parent set for this new DODAG.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 .A node is allowed to join any DODAG Version that it has never
been a prior member of without any restrictions, but if the node
has been a prior member of the DODAG Version then it must continue
to observe the rule that it may not advertise a rank higher than
L+DAGMaxRankIncrease at any point in the life of the DODAG
Version. This rule must be observed so as not to create a loophole
that would allow the node to effectively increment its rank all
the way to INFINITE_RANK, which may have impact on other nodes and
create a resource-wasting count-to-infinity scenario.A node poisons routes by advertising a Rank of
INFINITE_RANK.A node MUST NOT have any nodes with a Rank of INFINITE_RANK
in its parent set.Although an implementation may advertise INFINITE_RANK for the
purposes of poisoning, doing so is not the same as setting Rank to
INFINITE_RANK. For example, a node may continue to send data
packets whose RPL Packet Information includes a Rank that is not
INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs.When a (former) parent is observed to advertise a Rank of
INFINITE_RANK, that (former) parent has detached from the DODAG
and is no longer able to act as a parent, nor is there any why
that another node may be considered to have a Rank greater-than
INFINITE_RANK. Therefore that (former) parent cannot act as a
parent any longer and is removed from the parent set.A node unable to stay connected to a DODAG within a given
DODAG Version, i.e. that cannot retain non-empty parent set
without violating the rules of this specification, MAY detach
from this DODAG Version. A node that detaches becomes root of
its own floating DODAG and SHOULD immediately advertise this
new situation in a DIO as an alternate to poisoning.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.A DODAG parent may have moved, migrated to the next DODAG
Version, or jumped to a different DODAG. A node ought to give some
preference to remaining in the current DODAG, if possible via an
alternate parent, but ought to follow the parent if there are no
other options.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.If the DIO message is malformed, then the DIO message is not
eligible for further processing and a node MUST silently discard
it. (See for error
logging).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.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 . When a node places a neighbor into
the DODAG parent set, the node becomes attached to the DODAG
through the new DODAG parent node.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).RPL nodes transmit DIOs using a Trickle timer (). A DIO from a sender with a
lesser DAGRank that causes no changes to the recipient's parent set,
preferred parent, or Rank SHOULD be considered consistent with respect
to the Trickle timer.The following packets and events MUST be considered inconsistencies
with respect to the Trickle timer, and cause the Trickle timer to
reset:When a node detects an inconsistency when forwarding a packet,
as detailed in .When a node receives a multicast DIS message without a
Solicited Information option, unless a DIS flag restricts this
behavior.When a node receives a multicast DIS with a Solicited
Information option and the node matches all of the predicates in
the Solicited Information option, unless a DIS flag restricts this
behavior.When a node joins a new DODAG Version (e.g. by updating its
DODAGVersionNumber, joining a new RPL Instance, etc.).Note that this list is not exhaustive, and an implementation MAY
consider other messages or events to be inconsistencies.A node SHOULD NOT reset its DIO trickle timer in response to
unicast DIS messages. When a node receives a unicast DIS without a
Solicited Information option, it MUST unicast a DIO to the sender in
response. This DIO MUST include a DODAG Configuration option. When a
node receives a unicast DIS message with a Solicited Information
option and matches the predicates of that Solicited Information
option, it MUST unicast a DIO to the sender in response. This unicast
DIO MUST include a DODAG Configuration Option. Thus a node MAY
transmit a unicast DIS message to a potential DODAG parent in order to
probe for DODAG Configuration and other parameters.The configuration parameters of the trickle timer are specified
as follows:learned from the DIO message as
(2^DIOIntervalMin)ms. The default value of DIOIntervalMin is
DEFAULT_DIO_INTERVAL_MIN.learned from the DIO message as
DIOIntervalDoublings. The default value of DIOIntervalDoublings
is DEFAULT_DIO_INTERVAL_DOUBLINGS.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.The DODAG selection is implementation and OF dependent. In order to
limit erratic movements, and all metrics being equal, nodes SHOULD
keep their previous selection. Also, nodes SHOULD provide a means to
filter out a parent whose availability is detected as fluctuating, at
least when more stable choices are available.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.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.In some cases a RPL node may attach to a DODAG as a leaf node only.
One example of such a case is when a node does not understand or does
not support (policy) the RPL Instance's OF or advertised
metric/constraint. As specified in
related to policy function, the node may either join the DODAG as a
leaf node or may not join the DODAG. As mentioned in , it is then recommended to log a fault.A leaf node does not extend DODAG connectivity but in some cases
the leaf node may still need to transmit DIOs on occasion, in
particular when the leaf node may not have always been acting as a
leaf node and an inconsistency is detected.A node operating as a leaf node must obey the following rules:It MUST NOT transmit DIOs containing the DAG Metric
Container.Its DIOs MUST advertise a DAGRank of INFINITE_RANK.It MAY suppress DIO transmission, unless the DIO transmission
has been triggered due to detection of inconsistency when a packet
is being forwarded or in response to a unicast DIS message, in
which case the DIO transmission MUST NOT be suppressed.It MAY transmit unicast DAOs as described in .It MAY transmit multicast DAOs to the '1 hop' neighborhood as
described in .A particular case that requires a leaf node to send a DIO is if
that leaf node was a prior member of another DODAG and another node
forwards a message assuming the old topology, triggering an
inconsistency. The leaf node needs to transmit a DIO in order to
repair the inconsistency. Note that due to the lossy nature of LLNs,
even though the leaf node may have optimistically poisoned its routes
by advertising a rank of INFINITE_RANK in the old DODAG prior to
becoming a leaf node, that advertisement may have become lost and a
leaf node must be capable to send a DIO later in order to repair the
inconsistency.In the general case, the leaf node MUST NOT advertise itself as a
router (i.e. send DIOs).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.This section describes how RPL discovers and maintains downward
routes. RPL constructs and maintains downward routes with Destination
Advertisement Object (DAO) messages. Downward routes support P2MP flows,
from the DODAG roots toward the leaves. Downward routes also support P2P
flows: P2P messages can flow toward a DODAG Root (or a common ancestor)
through an upward route, then away from the DODAG Root to a destination
through a downward route.This specification describes the two modes a RPL Instance may choose
from for maintaining downward routes. In the first mode, called
"storing", nodes store downward routing tables for their sub-DODAG. Each
hop on a downward route in a storing network examines its routing table
to decide on the next hop. In the second mode, called "non-storing",
nodes do not store downward routing tables. Downward packets are routed
with source routes populated by a DODAG Root .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.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.A node MAY send DAO messages using the all-RPL-nodes multicast
address, which is an optimization to provision one-hop routing.
The 'K' bit MUST be cleared on transmission of the multicast
DAO.A node's DAO parent set MUST be a subset of its DODAG parent
set.In storing mode operation, a node MUST NOT address unicast DAO
messages to nodes that are not DAO parents.In storing mode operation, the IPv6 source and destination
addresses of a DAO message MUST be link-local addresses.In non-storing mode operation, a node MUST NOT address unicast
DAO messages to nodes that are not DODAG roots.In non-storing mode operation, the IPv6 source and destination
addresses of a DAO message MUST be a unique-local or a global
addresses.The selection of DAO parents is implementation and objective
function specific.Destination Advertisement may be configured to be entirely
disabled, or operate in either a storing or non-storing mode, as
reported in the MOP in the DIO message.All nodes who join a DODAG MUST abide by the MOP setting from
the root. Nodes that do not have the capability to fully
participate as a router, e.g. that does not match the advertised
MOP, MAY join the DODAG as a leaf.If the MOP is 0, indicating no downward routing, nodes MUST NOT
transmit DAO messages, and MAY ignore DAO messages.In non-storing mode, the DODAG Root SHOULD store source routing
table entries for destinations learned from DAOs. If the Root
fails to store some information, then some destination may be
unreachable.In storing mode, all non-root, non-leaf nodes MUST store
routing table entries for destinations learned from DAOs.A DODAG can have one of several possible modes of operation, as
defined by the MOP field. Either it does not support downward routes,
it supports downward routes through source routing from DODAG Roots,
or it supports downward routes through in-network routing tables.When downward routes are supported through in-network routing
tables, the multicast operation defined in this specification may or
may not be supported, also as indicated by the MOP field.When downward routes are supported through in-network routing
tables as described in this specification, it is expected that nodes
acting as routers have been provisioned sufficiently to hold the
required routing table state. If a node acting as a router is unable
to hold the full routing table state then the routing state is not
complete, messages may be dropped as a consequence, and a fault may be
logged (). Future extensions to RPL
may elaborate on refined actions/behaviors to manage this case.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.For each Target that is associated with (owned by) a node, that
node is responsible to emit DAO messages in order to provision the
downward routes. The Target+Transit information contained in those
DAO messages subsequently propagates Up the DODAG. The Path Sequence
counter in the Transit information option is used to indicate
freshness and update stale downward routing information as described
in .For a Target that is associated with (owned by) a node, that node
MUST increment the Path Sequence counter, and generate a new DAO
message, when:The Path Lifetime is to be updated (e.g. a refresh or a
no-Path)The Parent Address list is to be changedFor a Target that is associated with (owned by) a node, that node
MAY increment the Path Sequence counter, and generate a new DAO
message, on occasion in order to refresh the downward routing
information. In storing mode, the node generates such DAO to each of
its DAO parents in order to enable multipath. All DAOs generated at
the same time for a same target MUST be sent with the same path
sequence in the transit information.A node might send DAO messages when it receives DAO messages, as
a result of changes in its DAO parent set, or in response to another
event such as the expiry of a related prefix lifetime. In the case
of receiving DAOs, it matters whether the DAO message is "new," or
contains new information. In non-storing mode, every DAO message a
node receives is "new." In storing mode, a DAO message is "new" if
it satisfies any of these criteria for a contained Target: it has a newer Path Sequence number,it has additional Path Control bits, oris a No-Path DAO message that removes the last downward route
to a prefix.A node that receives a DAO message from its sub-DODAG MAY
suppress scheduling a DAO message transmission if that DAO message
is not new.If a node sends a DAO message with newer or different
information than the prior DAO message transmission, it MUST
increment the DAOSequence field by at least one. A DAO message
transmission that is identical to the prior DAO message
transmission MAY increment the DAOSequence field.The RPLInstanceID and DODAGID fields of a DAO message MUST be
the same value as the members of the node's parent set and the
DIOs it transmits.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.A node that sets the 'K' flag in a unicast DAO message but does
not receive a DAO-ACK in response MAY reschedule the DAO message
transmission for another attempt, up until an
implementation-specific number of retries.Nodes SHOULD ignore DAOs without newer sequence numbers and
MUST NOT process them further.Unlike the Version field of a DIO, which is incremented only by a
DODAG Root and repeated unchanged by other nodes, DAOSequence values
are unique to each node. The sequence number space for unicast and
multicast DAO messages can be either the same or distinct. It is
RECOMMENDED to use the same sequence number space.DAOs follow a common structure in both storing and non-storing
networks. In the most general form, a DAO message may include several
groups of options, where each group consists of one or more Target
options followed by one or more Transit Information options. The
entire group of Transit Information options applies to the entire
group of Target options. Later sections describe further details for
each mode of operation.RPL nodes MUST include one or more RPL Target Options in each
DAO message they transmit. One RPL Target Option MUST have a
prefix that includes the node's IPv6 address if that node needs
the DODAG to provision downward routes to that node. The RPL
Target Option MAY be immediately followed by an opaque RPL Target
Descriptor Option that qualifies it.When a node updates the information in a Transit Information
option for a Target option that covers one of its addresses, it
MUST increment the Path Sequence number in that Transit
Information option. The Path Sequence number MAY be incremented
occasionally to cause a refresh to the downward routes.One or more RPL Target Option in a unicast DAO message MUST be
followed by one or more Transit Information Option. All the
transit options apply to all the target options that immediately
precede them.Multicast DAOs MUST NOT include the Parent Address in Transit
Information options.A node that receives and processes a DAO message containing
information for a specific Target, and that has prior information
for that Target, MUST use the Path Sequence number in the Transit
Information option associated with that Target in order to
determine whether or not the DAO message contains updated
information as per .If a node receives a DAO message that does not follow the above
rules, it MUST discard the DAO message without further
processing.In non-storing mode, the root builds a strict source routing
header, hop-by-hop, by recursively looking up one-hop information that
ties a target (address or prefix) and a transit address together. In
some cases, when a child address is derived from a prefix that is
owned and advertised by a parent, that parent-child relationship may
be inferred by the root for the purpose of constructing the source
routing header. In all other cases it is necessary to inform the root
of the transit-target relationship from a reachable target, so as to
later enable the recursive construction of the routing header. An
address that is advertised as target in a DAO message MUST be
collocated in the same router, or reachable onlink by the router that
owns the address that is indicated in the associated transit
information. The following additional rules apply to ensure the
continuity of the end-to-end source route path:The address of a parent used in the transit option MUST be
taken from a PIO from that parent with the 'R' flag set. The 'R'
flag in a PIO indicates that the prefix field actually contains
the full parent address but the child SHOULD NOT assume that the
parent address is onlink.A PIO with a 'A' flag set indicates that the RPL child node may
use the prefix to autoconfigure an address. A parent that
advertises a prefix in a PIO with the 'A' flag set MUST ensure
that the address or the whole prefix in the PIO is reachable from
the root by advertising it as a DAO target. If the parent sets
also the 'L' flag indicating that the prefix is onlink, then it
MUST advertise the whole prefix as target in a DAO message.An address that is advertised as target in a DAO message MUST
be collocated in the same router or reachable onlink by the router
that owns the address that is indicated in the associated transit
information.In order to enable an optimum compression of the routing
header, the parent SHOULD set the 'R' flag in all PIOs with the
'A' flag set and the 'L' flag cleared, and the child SHOULD prefer
to use as transit the address of the parent that is found in the
PIO that is used to autoconfigure the address that is advertised
as target in the DAO message.A router might have targets that are not known to be on-link
for a parent, either because they are addresses located on an
alternate interface or because they belong to nodes that are
external to RPL, for instance connected hosts. In order to inject
such a target in the RPL network, the router MUST advertise itself
as the Parent Address in the Transit Information option for that
target, using an address that is on-link for that nodes DAO
parent. If the target belongs to an external node then the router
MUST set the External 'E' flag in the transit information.A child node that has autoconfigured an address from a parent PIO
with the 'L' flag set does not need to advertise that address as a DAO
target since the parent insures that the whole prefix is already
reachable from the root. But if the 'L' flag is not set then it is
necessary in non-storing mode for the child node to inform the root of the parent-child
relationship, using a reachable address of the parent, so as to enable
the recursive construction of the routing header. This is done by
associating an address of the parent as transit with the address of
the child as target in a DAO message.Because DAOs flow upwards, receiving a unicast DAO can trigger
sending a unicast DAO to a DAO parent.On receiving a unicast DAO message with updated information,
such as containing a Transit Information option with a new Path
Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO
message immediately. It SHOULD delay sending the DAO message in
order to aggregate DAO information from other nodes for which it
is a DAO parent.A node SHOULD delay sending a DAO message with a timer
(DelayDAO). Receiving a DAO message starts the DelayDAO timer. DAO
messages received while the DelayDAO timer is active do not reset
the timer. When the DelayDAO timer expires, the node sends a
DAO.When a node adds a node to its DAO parent set, it SHOULD
schedule a DAO message transmission.DelayDAO's value and calculation is implementation-dependent. A
default value of DEFAULT_DAO_DELAY is defined in this
specification.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.If a node hears one of its DAO parents increment its DTSN, the
node MUST schedule a DAO message transmission using rules in and .In non-storing mode, if a node hears one of its DAO parents
increment its DTSN, the node MUST increment its own DTSN.In a storing mode of operation, as part of routine routing table
updates and maintenance, a storing node MAY increment DTSN in order to
reliably trigger a set of DAO updates from its immediate children. In
a storing mode of operation it is not necessary to trigger DAO updates
from the entire sub-DODAG, since that state information will propagate
hop-by-hop Up the DODAG.In a non-storing mode of operation, a DTSN increment will also
cause the immediate children of a node to increment their DTSN in
turn, triggering a set of DAO updates from the entire sub-DODAG. In a
non-storing mode of operation typically only the root would
independently increment the DTSN when a DAO refresh is needed but a
global repair (such as by incrementing DODAGVersionNumber) is not
desired. In a non-storing mode of operation typically all non-root
nodes would increment their DTSN only when their parent(s) are
observed to do so.In the general, a node may trigger DAO updates according to
implementation specific logic, such as based on the detection of a
downward route inconsistency or occasionally based upon an internal
timer.In the case of triggered DAOs, selecting a proper DAODelay can
greatly reduce the number of DAOs transmitted. The trigger flows Down
the DODAG; in the best case the DAOs flow Up the DODAG such that
leaves send DAOs first, with each node sending a DAO message only
once. Such a scheduling could be approximated by setting DAODelay
inversely proportional to Rank. Note that this suggestion is intended
as an optimization to allow efficient aggregation (it is not required
for correct operation in the general case).In non-storing mode, RPL routes messages downward using IP source
routing. The following rule applies to nodes that are in non-storing
mode. Storing mode has a separate set of rules, described in .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.DAOs are sent directly to the root along a default route
installed as part of the parent selection.When a node removes a node from its DAO parent set, it MAY
generate a new DAO message with an updated Transit Information
option.In non-storing mode, a node uses DAOs to report its DAO parents to
the DODAG Root. The DODAG Root can piece together a downward route to
a node by using DAO parent sets from each node in the route. The Path
Sequence information may be used to detect stale DAO information. The
purpose of this per-hop route calculation is to minimize traffic when
DAO parents change. If nodes reported complete source routes, then on
a DAO parent change the entire sub-DODAG would have to send new DAOs
to the DODAG Root. Therefore, in non-storing mode, a node can send a
single DAO, although it might choose to send more than one DAO message
to each of multiple DAO parents.Nodes pack DAOs by sending a single DAO message with multiple RPL
Target Options. Each RPL Target Option has its own, immediately
following, Transit Information options.In storing mode, RPL routes messages downward by the IPv6
destination address. The following rule apply to nodes that are in
storing mode:The Parent Address field of a Transmit Information option MUST
be empty.On receiving a unicast DAO, a node MUST compute if the DAO
would change the set of prefixes that the node itself advertises.
This computation SHOULD include consultation of the Path Sequence
information in the Transit Information options associated with the
DAO, to determine if the DAO message contains newer information
that supersedes the information already stored at the node. If so,
the node MUST generate a new DAO message and transmit it,
following the rules in . Such a
change includes receiving a No-Path DAO.When a node generates a new DAO, it SHOULD unicast it to each
of its DAO parents. It MUST NOT unicast the DAO message to nodes
that are not DAO parents.When a node removes a node from its DAO parent set, it SHOULD
send a No-Path DAO message () to
that removed DAO parent to invalidate the existing route.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.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.Because this information is stored within each node's routing
tables, in storing mode DAOs are communicated directly to DAO parents,
who store this information.A DAO message from a node contains one or more Target Options. Each
Target Option specifies either a prefix advertised by the node, a
prefix of addresses reachable outside the LLN, the address of
destination in the node's sub-DODAG, or a multicast group that a node
in the sub-DODAG is listening to. The Path Control field of the
Transit Information option allows nodes to request or allow for
multiple downward routes. A node constructs the Path Control field of
a Transit Information option as follows:The bit width of the path control field MUST be equal to the
value (PCS + 1), where PCS is specified in the control field of
the DODAG Configuration Option. Bits greater than or equal to the
value (PCS + 1) MUST be cleared on transmission and MUST be
ignored on reception. Bits below that value are considered
"active" bits.The node MUST logically construct groupings of its DAO parents
while populating the Path Control field, where each group consists
of DAO parents of equal preference. Those groups MUST then be
ordered according to preference, which allows for a logical
mapping of DAO parents onto Path Control subfields (See ). Groups MAY be repeated in
order to extend over the entire bit width of the patch control
field, but the order, including repeated groups, MUST be retained
so that preference is properly communicated.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.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.When a node sends a DAO message to one of its DAO parents, it
MUST select one or more of the bits that are set active in the
subfield that is mapped to the group containing that DAO parent
from the aggregated Path Control field. A given bit can only be
presented as active to one parent. The DAO message it transmits to
its parent MUST have these active bits set and all other active
bits cleared.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.Path control bits SHOULD be allocated according to the
preference mapping of DAO parents onto Path Control subfields,
such that the active Path Control bits, or groupings of bits, that
belong to a particular Path Control subfield are allocated to DAO
parents within the group that was mapped to that subfield.In a non-storing mode of operation, a node MAY pass DAOs
through without performing any further processing on the Path
Control field.A node MUST NOT unicast a DAO message that has no active bits
in the Path Control field set. It is possible that, for a given
Target option, that a node does not have enough aggregate Path
Control bits to send a DAO message containing that Target to each
of its DAO Parents, in which case those least preferred DAO
Parents may not get a DAO message for that Target.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.A node that provisions a DAO route for a Target that has an
associated Path Control field SHOULD use the content of that Path
Control field in order to determine an order of preference among
multiple alternative DAO routes for that Target. The Path Control
field assignment is derived from preference (of the DAO parents), as
determined on the basis of this node's best knowledge of the
"end-to-end" aggregated metrics in the "downward" direction as per the
objective function. In non storing mode the root can determine the
downward route by aggregating the information from each received DAO,
which includes the Path Control indications of preferred DAO
parents.Suppose that there is an LLN operating in storing mode that
contains a Node N with four parents, P1, P2, P3, and P4. Let N have
three children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such
that there will be 8 active bits in the Path Control field:
11111111b. Consider the following example:The Path Control field is split into 4 subfields, PC1
(11000000b), PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b),
such that those 4 subfields represent 4 different levels of
preference as per . The
implementation at Node N, in this example, groups {P1, P2} to be of
equal preference to each other, and the most preferred group
overall. {P3} is less preferred to {P1, P2}, and more preferred to
{P4}. Let Node N then perform its path control mapping such that:
PC1 (11000000b) in the Path Control field
{P3} -> PC2 (00110000b) in the Path Control field
{P4} -> PC3 (00001100b) in the Path Control field
{P4} -> PC4 (00000011b) in the Path Control field
]]>Note that the implementation repeated {P4} in order to
get complete coverage of the Path Control field.Let C1 send a DAO containing a Target T with a Path Control
10000000b. Node N stores an entry associating 10000000b with the
Path Control field for C1 and Target T.Let C2 send a DAO containing a Target T with a Path Control
00010000b. Node N stores an entry associating 00010000b with the
Path Control field for C1 and Target T.Let C3 send a DAO containing a Target T with a Path Control
00001100b. Node N stores an entry associating 00001100b with the
Path Control field for C1 and Target T.At some later time, Node N generates a DAO for Target T. Node
N will construct an aggregate Path Control field by ORing
together the contribution from each of its children that have
given a DAO for Target T. The aggregate Path Control field thus
has the active bits set as: 10011100b.Node N then distributes the aggregate Path Control bits among
its parents P1, P2, P3, and P4 in order to prepare the DAO
messages.P1 and P2 are eligible to receive active bits from the most
preferred subfield (11000000b). Those bits are 10000000b in the
aggregate Path Control field. Node N must the bit to one of the
two parents only. In this case, Node P1 is allocated the bit,
and gets the Path Control field 10000000b for its DAO. There are
no bits left to allocate to Node P2, thus Node P2 would have a
Path Control field of 00000000b and a DAO cannot be generated to
Node P2 since there are no active bits.The second-most preferred subfield (00110000b) has the active
bits 00010000b. Node N has mapped P3 to this subfield. Node N
may allocates the active bit to P3, constructing a DAO for P3
containing Target T with a Path Control of 00010000b.The third-most preferred subfield (00001100b) has the active
bits 00001100b. Node N has mapped P4 to this subfield. Node N
may allocate both bits to P4, constructing a DAO for P4
containing Target T with a Path Control of 00001100b.The least preferred subfield (00000011b) has no active bits.
Had there been active bits, those bits would have been added to
the Path Control field of the DAO constructed for P4.The process of populating the DAO messages destined for P1,
P2, P3, P4 with other targets (other than T) proceeds as
according the aggregate path control fields collected for those
targets.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.A node MAY multicast a DAO message to the link-local scope
all-RPL-nodes multicast address.A multicast DAO message MUST be used only to advertise
information about the node itself, i.e. prefixes directly
connected to or owned by the node, such as a multicast group that
the node is subscribed to or a global address owned by the
node.A multicast DAO message MUST NOT be used to relay connectivity
information learned (e.g. through unicast DAO) from another
node.A node MUST NOT perform any other DAO related processing on a
received multicast DAO message, in particular a node MUST NOT
perform the actions of a DAO parent upon receipt of a multicast
DAO.The multicast DAO may be used to enable direct P2P
communication, without needing the DODAG to relay the packets.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.Implementation complexity and size is a core concern for LLNs such
that it may be economically or physically impossible to include
sophisticated security provisions in a RPL implementation. Furthermore,
many deployments can utilize link-layer or other security mechanisms to
meet their security requirements without requiring the use of security
in RPL.Therefore, the security features described in this document are
OPTIONAL to implement. A given implementation MAY support a subset
(including the empty set) of the described security features, for
example it could support integrity and confidentiality, but not
signatures. An implementation SHOULD clearly specify which security
mechanisms are supported, and it is RECOMMENDED that implementers
carefully consider security requirements and the availability of
security mechanisms in their network.RPL supports three security modes:Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO,
and DAO-ACK messages, which do not have security sections. As a
network could be using other security mechanisms, such as
link-layer security, unsecured mode does not imply all messages
are sent without any protection.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.Authenticated. In this security mode, RPL uses secure messages.
To join a RPL Instance, a node must have a pre-installed key.
Nodes 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. Authenticated mode cannot
be supported by symmetric algorithms. As of this specification,
RPL supports only symmetric algorithms: authenticated mode is
included for the benefit of potential future cryptographic
primitives. See .Whether or not the RPL Instance uses unsecured mode is signaled by
whether it uses secure RPL messages. Whether a secured network uses
the pre-installed or authenticated mode is signaled by the 'A' bit of
the DAG Configuration option.This specification specifies CCM -- Counter with CBC-MAC (Cipher
Block Chaining Message Authentication Code) -- as the cryptographic
basis for RPL security. 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.All secured RPL messages have either a message authentication code
(MAC) or a signature. Secured RPL messages optionally also have
encryption protection for confidentiality. Secured RPL message formats
support both integrated encryption/authentication schemes (e.g., CCM)
as well as schemes that separately encrypt and authenticate
packets.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 , secure DIO and DIS messages have these
rules:If sent, this initial secure DIS MUST set the Key Identifier
Mode field to 0 (00) and MUST set the Security Level field to 1
(001). The key used MUST be the preconfigured group key (Key Index
0x00).When a node resets its Trickle timer in response to a secure
DIS (), 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.When a node sends a DIO in response to a unicast secure DIS
(), the DIO MUST be a secure
DIO.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.If the 'A' bit of the Configuration option is set and the RPL
Instance is operating in authenticated mode:A node MUST NOT advertise a Rank besides INFINITE_RANK in
secure DIOs secured with Key Index 0x00. When processing DIO
messages secured with Key Index 0x00, a processing node MUST
consider the advertised Rank to be INFINITE_RANK. Any other value
results in the message being discarded.Secure DAOs using Key Index 0x00 MUST NOT have a RPL Target
option with a prefix besides the node's address. If a node
receives a secured DAO message using the preinstalled, shared key
where the RPL Target option does not match the IPv6 source
address, it MUST discard the secured DAO message without further
processing.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.Authenticated mode requires a would-be router to dynamically
install new keys once they have joined a network as a host. Having
joined as a host, the node uses standard IP messaging to communicate
with an authorization server, which can provide new keys.The protocol to obtain such keys is out of scope for this
specification and to be elaborated in future specifications. That
elaboration is required for RPL to securely operate in authenticated
mode.RPL nodes send Consistency Check (CC) messages to protect against
replay attacks and synchronize counters.If a node receives a unicast CC message with the R bit cleared,
and it is a member of or is in the process of joining the
associated DODAG, it SHOULD respond with a unicast CC message to
the sender. This response MUST have the R bit set, and MUST have
the same Nonce, RPLInstanceID and DODAGID fields as the message it
received.If a node receives a multicast CC message, it MUST discard the
message with no further processing.Consistency Check messages allow nodes to issue a
challenge-response to validate a node's current Counter value. Because
the CC Nonce is generated by the challenger, an adversary replaying
messages is unlikely to be able to generate a correct response. The
Counter in the Consistency Check response allows the challenger to
validate the Counter values it hears.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:The timestamp MUST be at least six octets long.The timestamp MUST be in 1024Hz (binary millisecond)
granularity.The timestamp start time MUST be January 1, 1970, 12:00:00AM
UTC.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.If the Counter represents such a timestamp, a node MAY set the
'T' flag of the security section of secured RPL packets.If the Counter field does not present such a timestamp, then a
node MUST NOT set the 'T' flag.If a node does not have a local timestamp that satisfies the
above requirements, it MUST ignore the 'T' flag.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 . 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.The 'T' flag is present because many LLNs today already maintain
global time synchronization at sub-millisecond granularity for
security, application, and other reasons. Allowing RPL to leverage
this existing functionality when present greatly simplifies solutions
to some security problems, such as delay protection.Given an outgoing RPL control packet and required security
protection, this section describes how RPL generates the secured
packet to transmit. It also describes the order of cryptographic
operations to provide the required protection.The requirement for security protection and the level of security
to be applied to an outgoing RPL packet shall be determined by the
node's security policy database. The configuration of this security
policy database for outgoing packet processing is implementation
specific.Where secured RPL messages are to be transmitted, a RPL node MUST
set the security section (T, Sec, KIM, and LVL) in the outgoing RPL
packet to describe the protection level and security settings that are
applied (see ). The Security
subfield bit of the RPL message Code field MUST be set to indicate the
secure RPL message.The Counter value used in constructing the AES-128 CCM Nonce () to secure the outgoing packet MUST be an
increment of the last Counter transmitted to the particular
destination address.Where security policy specifies the application of delay
protection, the Timestamp Counter used in constructing the Nonce to
secure the outgoing packet MUST be incremented according to the rules
in . Where a Timestamp Counter
is applied (indicated with the 'T' flag set) the locally maintained
Time Counter MUST be included as part of the transmitted secured RPL
message.The cryptographic algorithm used in securing the outgoing packet
shall be specified by the node's security policy database and MUST be
indicated in the value of the Sec field set within the outgoing
message.The security policy for the outgoing packet shall determine the
applicable Key Identifier Mode (KIM) and Key Identifier specifying the
security key to be used for the cryptographic packet processing,
including the optional use of signature keys (see ). The security policy will also
specify the algorithm (Algorithm) and level of protection (Level) in
the form of authentication or authentication and encryption, and
potential use of signatures that shall apply to the outgoing
packet.Where encryption is applied, a node MUST replace the original
packet payload with that payload encrypted using the security
protection, key, and nonce specified in the security section of the
packet.All secured RPL messages include integrity protection. In
conjunction with the security algorithm processing, a node derives
either a Message Authentication Code (MAC) or signature that MUST be
included as part of the outgoing secured RPL packet.This section describes the reception and processing of a secured
RPL packet. Given an incoming secured RPL packet, where the Security
subfield bit of the RPL message Code field is set, this section
describes how RPL generates an unencrypted variant of the packet and
validates its integrity.The receiver uses the RPL security control fields to determine the
necessary packet security processing. If the described level of
security for the message type and originator is unknown or does not
meet locally maintained security policies, a node MUST discard the
packet without further processing, MAY raise a management alert, and
MUST NOT send any messages in response. These policies can include
security levels, keys used, source identifiers, or the lack of
timestamp-based counters (as indicated by the 'T' flag). The
configuration of the security policy database for incoming packet
processing is out of scope for this specification (it may, for
example, be defined through DIO Configuration or through out-of-band
administrative router configuration).Where the message security level (LVL) indicates an encrypted RPL
message, the node uses the key information identified through the KIM
field as well as the Nonce as input to the message payload decryption
processing. The Nonce shall be derived from the message Counter field
and other received and locally maintained information (see ). The plaintext message contents shall
be obtained by invoking the inverse cryptographic mode of operation
specified by the Sec field of the received packet.The receiver shall use the Nonce and identified key information to
check the integrity of the incoming packet. If the integrity check
fails against the received message authentication code (MAC), a node
MUST discard the packet.If the received message has an initialized (zero value) Counter
value and the receiver has an incoming Counter currently maintained
for the originator of the message, the receiver MUST initiate a
Counter resynchronization by sending a Consistency Check response
message (see ) to the message
source. The Consistency Check response message shall be protected with
the current full outgoing Counter maintained for the particular node
address. That outgoing Counter will be included within the security
section of the message while the incoming Counter will be included
within the Consistency Check message payload.Based on the specified security policy a node MAY apply replay
protection for a received RPL message. The replay check SHOULD be
performed before the authentication of the received packet. The
Counter as obtained from the incoming packet shall be compared against
the watermark of the incoming Counter maintained for the given
origination node address. If the received message Counter value is
non-zero and less than the maintained incoming Counter watermark a
potential packet replay is indicated and the node MUST discard the
incoming packet.If delay protection is specified as part of the incoming packet
security policy checks, the Timestamp Counter is used to validate the
timeliness of the received RPL message. If the incoming message
Timestamp Counter value indicates a message transmission time prior to
the locally maintained transmission time Counter for the originator
address, a replay violation is indicated and the node MUST discard the
incoming packet. If the received Timestamp Counter value indicates a
message transmission time that is earlier than the Current time less
the acceptable packet delay, a delay violation is indicated and the
node MUST discard the incoming packet.Once a message has been decrypted, where applicable, and has
successfully passed its integrity check, replay, and optionally delay
protection checks, the node can update its local security information,
such as the source's expected Counter value for replay comparison.A node MUST NOT update its security information on receipt of a
message that fails security policy checks or other applied integrity,
replay, or delay checks.If the 'T' flag of a message is set and a node has a local
timestamp that follows the requirements in , 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.For a RPL ICMPv6 message, the entire packet is within the scope of
RPL security.Message authentication codes (MAC) and signatures are calculated
over the entire unsecured IPv6 packet. When computing MACs and
signatures, mutable IPv6 fields are considered to be filled with
zeroes, following the rules in Section 3.3.3.1 of (IPSec Authenticated Header). MAC and
signature calculations are performed before any compression that lower
layers may apply.When a RPL ICMPv6 message is encrypted, encryption starts at the
first byte after the security section and continues to the last byte
of the packet. The IPv6 header, ICMPv6 header, and RPL message up to
the end of the security section are not encrypted, as they are needed
to correctly decrypt the packet.For example, a node sending a message with LVL=5, KIM=0, and
Algorithm=0 uses the CCM algorithm to
create a packet with attributes ENC-MAC-32: it encrypts the packet and
appends a 32-bit MAC. The block cipher key is determined by the Key
Index; the Nonce is computed as described in ; the message to authenticate and
encrypt is the RPL message starting at the first byte after the
security section and ends with the last byte of the packet; the
additional authentication data starts with the beginning of the IPv6
header and ends with the last byte of the RPL security section.The cryptographic mode of operation described in this specification
(Algorithm = 0) is based on CCM and the block-cipher AES-128. This mode of operation is widely supported
by existing implementations. CCM mode requires a nonce.A RPL node constructs a CCM nonce as follows:8 bytes. Source Identifier is
set to the logical identifier of the originator of the protected
packet.4 bytes. Counter is set to the
(uncompressed) value of the corresponding field in the Security
option of the RPL control message.3 bits. Security Level is
set to the value of the corresponding field in the Security
option of the RPL control message.Unassigned bits of the nonce are reserved. They MUST be set to
zero when constructing the nonce.All fields of the nonce are represented in most-significant-octet
and most-significant-bit first order.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.The signature scheme in RPL for Security Mode 3 is an
instantiation of the RSA algorithm (RSASSA-PSS) as defined in
Section 8.1 of . It uses as public key
the pair (n,e), where n is a 2048-bit or 3072-bit RSA modulus and
where e=2^{16}+1. It uses CCM mode as
the encryption scheme with M=0 (as a stream-cipher). Note that
although disallows CCM mode with M=0,
this specification explicitly allows CCM mode with M=0 when used in
conjunction with a signature as in this case, because the signature
provides sufficient protection. It uses the SHA-256 hash function
specified in Section 6.2 of . It uses
the message encoding rules of Section 8.1 of .Let 'a' be a concatenation of a six-byte representation of
Counter and the message header. The packet payload is the
right-concatenation of packet data 'm' and the signature 's'. This
signature scheme is invoked with the right-concatenation of the
message parts a and m, whereas the signature verification is invoked
with the right-concatenation of the message parts a and m, and with
signature s.RSA signatures of this form provide sufficient protection for RPL
networks. If needed, alternative signature schemes which produce
more concise signatures is out of scope for this specification and
may be the subject of a future specification.An implementation that supports RSA signing with either 2048-bit
or 3072-bit signatures SHOULD support verification of both 2048-bit
and 3072-bit RSA signatures. This is in consideration of providing
an upgrade path for a RPL deployment.This document specifies a routing protocol. These non-normative
suggestions are provided to aid in the design of a forwarding
implementation by illustrating how such an implementation could work
with RPLWhen forwarding a packet to a destination, precedence is given to
selection of a next-hop successor as follows:This specification only covers how a successor is selected from
the DODAG Version that matches the RPLInstanceID marked in the
IPv6 header of the packet being forwarded. Routing outside the
instance can be done as long as additional rules are put in place
such as strict ordering of instances and routing protocols to
protect against loops. Such rules may be defined in a separate
document.If a local administrative preference favors a route that has
been learned from a different routing protocol than RPL, then use
that successor.If the packet header specifies a source route by including a
RH4 header as specified in , then use that
route. If the node fails to forward the packet with that specified
source route, then that packet should be dropped. The node MAY log
an error. The node may send an ICMPv6 Error in Source Routing
Header message to the source of the packet (See ).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.If there is an entry in the routing table matching the
destination that has been learned from a unicast destination
advertisement (e.g. the destination is located Down the
sub-DODAG), then use that successor. If there are DAO Path Control
bits associated with multiple successors, then consult the Path
Control bits to order the successors by preference when choosing.
If, for a given DAO Path Control bit, multiple successors are
recorded as having asserted that bit, precedence should be given
to the successor who most recently asserted that bit.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.Any other as-yet-unattempted DODAG parent may be chosen for the
next attempt to forward a unicast packet when no better match
exists.Finally the packet is dropped. ICMP Destination Unreachable MAY
be invoked (an inconsistency is detected).Hop Limit MUST be decremented when forwarding as per .Note that the chosen successor MUST NOT be the neighbor that was
the predecessor of the packet (split horizon), except in the case
where it is intended for the packet to change from an upward to a
downward direction, as determined by the routing table of the node
making the change, such as switching from DIO routes to DAO routes as
the destination is neared in order to continue traveling toward the
destination.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.RPL loop detection uses RPL Packet Information that is transported
within the data packets, relying on an external mechanism such as
that places in the RPL
Packet Information in an IPv6 Hop-by-Hop Option header.The content of RPL Packet Information is defined as follows:1-bit flag indicating whether the packet
is expected to progress Up or Down. A router sets the 'O' flag
when the packet is expected to progress Down (using DAO routes),
and clears it when forwarding toward the DODAG root (to a node
with a lower rank). A host or RPL leaf node MUST set the 'O' flag
to 0.1-bit flag indicating whether a rank
error was detected. A rank error is detected when there is a
mismatch in the relative ranks and the direction as indicated in
the 'O' bit. A host or RPL leaf node MUST set the 'R' bit to
0.1-bit flag indicating that
this node can not forward the packet further towards the
destination. The 'F' bit might be set by a child node that does
not have a route to destination for a packet with the Down 'O' bit
set. A host or RPL leaf node MUST set the 'F' bit to 0.8-bit field indicating the DODAG
instance along which the packet is sent.16-bit field set to zero by the source
and to DAGRank(rank) by a router that forwards inside the RPL
network.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.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. The
RPLInstanceID is part of the RPL Packet Information.A RPL router that forwards a packet in the RPL network MUST
check if the packet includes the RPL Packet Information. If not,
then the RPL router MUST insert a RPL Packet Information. If the
router is an ingress router that injects the packet into the RPL
network, the router MUST set the RPLInstanceID field in the RPL
Packet Information. The details of how that router determines the
mapping to a RPLInstanceID are out of scope for this specification
and left to future specification.A router that forwards a packet to outside the RPL network MUST
remove the RPL Packet Information.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.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.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: the 'O' bit set (to Down) from a node of a higher rank.the 'O' bit cleared (for Up) from a node of a lesser
rank.When the DODAG root increments the DODAGVersionNumber, a
temporary rank discontinuity may form between the next DODAG
Version and the prior DODAG Version, in particular if nodes are
adjusting their rank in the next DODAG Version and deferring their
migration into the next DODAG Version. A router that is still a
member of the prior DODAG Version may choose to forward a packet
to a (future) parent that is in the next DODAG Version. In some
cases this could cause the parent to detect an inconsistency
because the rank-ordering in the prior DODAG Version is not
necessarily the same as in the next DODAG Version and the packet
may be judged to not be making forward progress. If the sending
router is aware that the chosen successor has already joined the
next DODAG Version, then the sending router MUST update the
SenderRank to INFINITE_RANK as it forwards the packets across the
discontinuity into the next DODAG Version in order to avoid a
false detection of rank inconsistency.One inconsistency along the path is not considered a critical
error and the packet may continue. But a second detection along
the path of a same packet should not occur and the packet MUST be
dropped.This process is controlled by the Rank-Error bit associated
with the packet. When an inconsistency is detected on a packet, if
the Rank-Error bit was not set then the Rank-Error bit is set. If
it was set the packet MUST be discarded and the trickle timer MUST
be reset.DAO inconsistency loop recovery is a mechanism that applies to
storing mode of operation only.In non-storing mode, the packets are source routed to the
destination and DAO inconsistencies are not corrected locally.
Instead, an ICMP error with a new code "Error in Source Routing
Header" is sent back to the root. The "Error in Source Routing
Header" message has the same format as the "Destination
Unreachable Message" as specified in . The portion of the invoking packet that
is sent back in the ICMP message should record at least up to the
routing header, and the routing header should be consumed by this
node so that the destination in the IPv6 header is the next hop
that this node could not reach.A DAO inconsistency happens when a router has a downward route
that was previously learned from a DAO message via a child, but
that downward route is not longer valid in the child, e.g. because
that related state in the child has been cleaned up. With DAO
inconsistency loop recovery, a packet can be used to recursively
explore and cleanup the obsolete DAO states along a sub-DODAG.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.Upon receiving a packet with a Forwarding-Error bit set, the
node MUST remove the routing states that caused forwarding to that
neighbor, clear the Forwarding-Error bit and attempt to send the
packet again. The packet may be sent to an alternate neighbor,
after the expiration of a user-configurable implementation
specific timer. If that alternate neighbor still has an
inconsistent DAO state via this node, the process will recurse,
this node will set the Forwarding-Error 'F' bit and the routing
state in the alternate neighbor will be cleaned up as well.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 () or MLDv2 ().RPL provides a trivial mapping between MLD queries and RPL DAOs by
transporting a multicast group in a DAO target option. The mapping
excludes the support of source specific filters that are not defined in
DAO options. The mapping enables to proxy a multicast registration from
a non-RPL node attached to a RPL router up to the root of the DODAG,
which can act as a multicast router as if the listeners were directly
attached to it.Nodes that support the RPL storing mode of operation SHOULD also
support multicast DAO operations as described below. Nodes that only
support the non-storing mode of operation are not expected to support
this section.The multicast operation is controlled by the MOP field in the DIO.
If the MOP field requires multicast support, then a node that
joins the RPL network as a router must operate as described in this
section for multicast signaling and forwarding within the RPL
network. A node that does not support the multicast operation
required by the MOP field can only join as a leaf.If the MOP field does not require multicast support, then
multicast is handled by some other way that is out of scope for this
specification. (Examples may include a series of unicast copies or
limited-scope flooding).As is traditional, a listener that is not a RPL node uses a protocol
such as MLD with a router to register to a multicast group. If the
listener is attached to a RPL router and multicast support is enabled,
then the RPL router maps the MLD query into a RPL DAO message. A
listener that is a RPL node uses a listener registration DAO message
right away.Along the path between the router and the DODAG root, MLD requests
are transported as DAO messages within RPL; each hop coalesces the
multiple requests for a same group as a single DAO message to the
parent(s), in a fashion similar to proxy IGMP, but recursively between
child router and parent Up to the DODAG root.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.As a result, multicast routing states are installed in each router on
the way from the listeners to the DODAG root, enabling the root to copy
a multicast packet to all its children routers that had issued a DAO
message including a Target option for that multicast group, as well as
all the attached nodes that registered over MLD.For unicast traffic, it is expected that the grounded DODAG root acts
as a Low power and lossy network Border Router (LBR) and MAY
redistribute the RPL routes over the external infrastructure using
whatever routing protocol is used in the other routing domain. For
multicast traffic, the root MAY proxy MLD for all the nodes attached to
the RPL domain (this would be needed if the multicast source is located
in the external infrastructure). For such a source, the packet will be
replicated as it flows Down the DODAG based on the multicast routing
table entries installed from the DAO message.For a multicast packet sourced from inside the DODAG, the packet is
passed to the preferred parents, and if that fails then to the
alternates in the DODAG. The packet is also copied to all the registered
children, except for the one that passed the packet. Finally, if there
is a listener in the external infrastructure then the DODAG root has to
further propagate the packet into the external infrastructure.As a result, the DODAG Root acts as an automatic proxy Rendezvous
Point for the RPL network, and as source towards the non-RPL domain for
all multicast flows started in the RPL domain. So regardless of whether
the root is actually attached to a non-RPL domain, and regardless of
whether the DODAG is grounded or floating, the root can serve inner
multicast streams at all times.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.In IGPs such as OSPF or IS-IS , the maintenance of a routing adjacency
involves the use of Keepalive mechanisms (Hellos) or other protocols
such as the Bidirectional Forwarding Detection
(BFD) and the MANET
Neighborhood Discovery Protocol(NHDP) . Unfortunately, such a
proactive approach is often not desirable in constrained environments
where it would lead to excessive control traffic in light of the data
traffic with a negative impact on both link loads and nodes
resources.By contrast with those routing protocols, RPL does not define any
'keep-alive' mechanisms to detect routing adjacency failures: this is
because in many cases such a mechanism would 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 an
external mechanisms to detect that a neighbor is no longer reachable.
Such a mechanism should preferably be reactive to traffic in order to
minimize the overhead to maintain the routing adjacency and focus on
links that are actually being used.Example reactive mechanisms that can be used include: The Neighbor Unreachability Detection
mechanism.Layer 2 triggers derived from
events such as association states and L2 acknowledgements.An Objective Function (OF), in conjunction with routing metrics and
constraints, allows for the selection of a DODAG to join, and a number
of peers in that DODAG as parents. The OF is used to compute an ordered
list of parents. The OF is also responsible to compute the rank of the
device within the DODAG Version.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 , and related companion
specifications.Most Objective Functions are expected to follow the same abstract
behavior at a node: 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.An OF scans all the interfaces on the node. 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 for this specification. Finally an
interface might or not match a required criterion for an Objective
Function, for instance a degree of security. As a result, some
interfaces might be completely excluded from the computation, for
example if those interfaces cannot satisfy some advertised
constraints, while others might be more or less preferred.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.An OF computes rank of a node for comparison by adding to the
rank of the candidate a value representing the relative locations
of the node and the candidate in the DODAG Version.The increase in rank must be at least
MinHopRankIncrease.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.Candidate neighbors that would cause the rank of the node
to increase are not considered for parent selection.Candidate neighbors that advertise an OF incompatible with the
set of OF specified by the policy functions are ignored.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. If the routers are equal for that relation then the next
test is attempted between the routers,Else the best of the two routers becomes the current best
parent and the scan continues with the next candidate
neighbor.Some OFs may include a test to compare the ranks that would
result if the node joined either router.When the scan is complete, the preferred parent is elected and
the node's rank is computed as the preferred parent rank plus the
step in rank with that parent.Other rounds of scans might be necessary to elect alternate
parents. In the next rounds: Candidate neighbors that are not in the same DODAG are
ignored.Candidate neighbors that are of greater rank than the node
are ignored.Candidate neighbors of an equal rank to the node are
ignored for parent selection.Candidate neighbors of a lesser rank than the node are
preferred.This specification directly borrows the Prefix Information Option
(PIO) and the Routing Information Option (RIO) from IPv6 ND. It is
envisioned that, as future specifications build on this base, there may
be additional cause to leverage parts of IPv6 ND. This section provides
some suggestions for future specifications.First and foremost RPL is a routing protocol. One should take great
care to preserve architecture when mapping functionalities between RPL
and ND. RPL is for routing only. That said, there may be persuading
technical reasons to allow for sharing options between RPL and IPv6 ND
in a particular implementation/deployment.In general the following guidelines apply: RPL Type codes must be allocated from the RPL Control Message
Options registry.RPL Length fields must be expressed in units of single octets, as
opposed to ND Length fields which are expressed in units of 8
octets.RPL Options are generally not required to be aligned to 8 octet
boundaries.When mapping/transposing an IPv6 ND option for redistribution as
a RPL option, any padding octets should be removed when possible.
For example, the Prefix Length field in the PIO is sufficient to
describe the length of the Prefix field. When mapping/transposing a
RPL option for redistribution as an IPv6 ND option, any such padding
octets should be restored. This procedure must be unambiguous.Following is a summary of RPL constants and variables:This is the rank for a virtual root that
might be used to coordinate multiple roots. BASE_RANK has a value of
0.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.This is the constant maximum for the
rank. INFINITE_RANK has a value of 0xFFFF.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.This is the default value
used to configure PCS in the DODAG Configuration Option, which
dictates the number of significant bits in the Path Control field of
the Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a
value of 0. This configures the simplest case limiting the fan-out
to 1 and limiting a node to send a DAO message to only one
parent.This is the default value
used to configure Imin for the DIO trickle timer.
DEFAULT_DIO_INTERVAL_MIN has a value of 3. This configuration
results in Imin of 8ms.This is the default
value used to configure Imax for the DIO trickle timer.
DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This configuration
results in a maximum interval of 2.3 hours.This is the default
value used to configure k for the DIO trickle timer.
DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This
configuration is a conservative value for trickle suppression
mechanism.This is the default
value of MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a
value of 256. This configuration results in an 8-bit wide integer
part of Rank.This is the default value for the
DelayDAO Timer. DEFAULT_DAO_DELAY has value of 1 second. See .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 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).Up to one timer per DAO parent (the
subset of DODAG parents chosen to receive destination
advertisements) per DODAG. Expiry triggers sending of DAO message to
the DAO parent. See Up to one timer per DAO entry per neighbor
(i.e. those neighbors that have given DAO messages to this node as a
DODAG parent) Expiry may trigger No-Path advertisements or
immediately deallocate the DAO entry if there are no DAO
parents.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 .Most of the existing IETF management standards are Structure of
Management Information (SMI) based data models (MIB modules) to
monitor and manage networking devices.For a number of protocols, the IETF community has used the IETF
Standard Management Framework, including the Simple Network Management
Protocol , the Structure of Management
Information , and MIB data models for
managing new protocols.As pointed out in , 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.In 2003, the Internet Architecture Board (IAB) held a workshop on
Network Management that discussed the
strengths and weaknesses of some IETF network management protocols and
compared them to operational needs, especially configuration.One issue discussed was the user-unfriendliness of the binary
format of SNMP . 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.As stated in , "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.RPL will be used on a variety of devices that may have resources
such as memory varying from a few Kbytes to several hundreds of Kbytes
and even Mbytes. When memory is highly constrained, it may not be
possible to satisfy all the requirements listed in this section. Still
it is worth listing all of these in an exhaustive fashion, and
implementers will then determine which of these requirements could be
satisfied according to the available resources on the device.This section discusses the configuration management, listing the
protocol parameters for which configuration management is
relevant.Some of the RPL parameters are optional. The requirements for
configuration are only applicable for the options that are used."Architectural Principles of the Internet" , Section 3.8, states: "Avoid options and
parameters whenever possible. Any options and parameters should be
configured or negotiated dynamically rather than manually." This is
especially true in LLNs where the number of devices may be large and
manual configuration is infeasible. This has been taken into account
in the design of RPL whereby the DODAG root provides a number of
parameters to the devices joining the DODAG, thus avoiding
cumbersome configuration on the routers and potential sources of
misconfiguration (e.g. values of trickle timers, ...). Still there
are additional RPL parameters that a RPL implementation should allow
to be configured, which are discussed in this section.When a node is first powered up:The node may decide to stay silent, waiting to receive DIO
messages from DODAG of interest (advertising a supported OF
and metrics/constraints) and not send any multicast DIO
messages until it has joined a DODAG.The node may decide to send one or more DIS messages
(optionally requesting DIO for a specific DODAG) as an initial
probe for nearby DODAGs, and in the absence of DIO messages in
reply after some configurable period of time, the node may
decide to root a floating DODAG and start sending multicast
DIO messages.A RPL implementation SHOULD allow configuring the preferred
mode of operation listed above along with the required parameters
(in the second mode: the number of DIS messages and related
timer).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.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.A RPL implementation MUST allow configuring the following RPL
parameters: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.List of supported Objective Code Points (OCPs)List of supported metrics: specifies a
number of metrics and constraints used for the DODAG formation.
Thus a RPL implementation should allow configuring the list of
metrics that a node can accept and understand. If a DIO is
received with a metric and/or constraint that is not understood
or supported, as specified in , the node would join as a leaf
node.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.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.'K' flag: when a node should set the 'K' flag in a DAO
message [DAO message, in DAO base message].MOP (Mode of Operation) [DIO message, in DIO base
message].Route Information (and preference) [DIO message, in Route
Information option]A RPL implementation MUST allow configuring the Target prefix
[DAO message, in RPL Target option].Furthermore, there are circumstances where a node may want to
designate a Target to allow for specific processing of the Target
(prioritization, ...). Such processing rules are out of scope for
this specification. When used, a RPL implementation SHOULD allow
configuring the Target Descriptor on a per-Target basis (for example
using access lists).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:Start its own (floating) DODAG: the new DODAGID must be
configured in addition to its DAGPreference.Poison the broken path (see procedure in ).Trigger a local repair.In addition, several other parameters are configured only on the
DODAG root and advertised in options carried in DIO messages.As specified in , 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.DIOIntervalDoublings [DIO message, in DODAG configuration
option]DIOIntervalMin [DIO message, in DODAG configuration
option]DIORedundancyConstant [DIO message, in DODAG configuration
option]In addition, a RPL implementation SHOULD allow for configuring
the following set of RPL parameters:Path Control Size [DIO message, in DODAG configuration
option]MinHopRankIncrease [DIO message, in DODAG configuration
option]The DODAGPreference field [DIO message, DIO Base object]DODAGID [DIO message, in DIO base option] and [DAO message,
when the 'D' flag of the DAO message is set]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.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 .DAO messages are optional and used in DODAGs that require
downward routing operation. This section deals with the set of
parameters related to DAO messages and provides recommendations on
their configuration.As stated in , it is
recommended to delay the sending of DAO message to DAO parents in
order to maximize the chances to perform route aggregation. Upon
receiving a DAO message, the node should thus start a DelayDAO
timer. The default value is DEFAULT_DAO_DELAY. A RPL implementation
MAY allow for configuring the DelayDAO timer.In a storing mode of operation, a storing node may increment DTSN
in order to reliably trigger a set of DAO updates from its immediate
children, as part of routine routing table updates and maintenance.
A RPL implementation MAY allow for configuring a set of rules
specifying the triggers for DTSN increment (manual or
event-based).When a DAO entry times out or is invalidated, a node SHOULD make
a reasonable attempt to report a No-Path to each of the DAO parents.
That number of attempts MAY be configurable.An implementation should support rate-limiting the sending of DAO
messages. The related parameters MAY be configurable.As described in , the
security features described in this document are optional to
implement and a given implementation may support a subset (including
the empty set) of the described security features.To this end an implementation supporting described security
features may conceptually implement a security policy database. In
support of the security mechanisms, a RPL implementation SHOULD
allow for configuring a subset of the following parameters:Security Modes accepted [Unsecured mode, Pre-Installed mode,
Authenticated mode]KIM values accepted [Secure RPL Control messages, in Security
Section]Level values accepted [Secure RPL Control messages, in
Security section]Algorithm values accepted [Secure RPL Control messages, in
Security section]Key material in support of Authenticated or Pre-Installed key
modes.In addition, a RPL implementation SHOULD allow for configuring a
DODAG root with a subset of the following parameters:Level values advertised [Secure DIO message, in Security
Section]KIM value advertised [Secure DIO message, in Security
Section]Algorithm value advertised [Secure DIO message, in Security
Section]This document specifies default values for the following set of
RPL variables: DEFAULT_PATH_CONTROL_SIZEDEFAULT_DIO_INTERVAL_MINDEFAULT_DIO_INTERVAL_DOUBLINGSDEFAULT_DIO_REDUNDANCY_CONSTANTDEFAULT_MIN_HOP_RANK_INCREASEDEFAULT_DAO_DELAYIt is recommended to specify default values in protocols; that
being said, as discussed in , default
values may make less and less sense. RPL is a routing protocol that
is expected to be used in a number of contexts where network
characteristics such as the number of nodes, link and nodes types
are expected to vary significantly. Thus, these default values are
likely to change with the context and as the technology will evolve.
Indeed, LLNs' related technology (e.g. hardware, link layers) have
been evolving dramatically over the past few years and such
technologies are expected to change and evolve considerably in the
coming years.The proposed values are not based on extensive best current
practices and are considered to be conservative.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.A RPL implementation SHOULD provide information about the
following parameters:DODAG Version number [DIO message, in DIO base message]Status of the G flag [DIO message, in DIO base message]Status of the MOP field [DIO message, in DIO base
message]Value of the DTSN [DIO message, in DIO base message]Value of the rank [DIO message, in DIO base message]DAOSequence: Incremented at each unique DAO message, echoed
in the DAO-ACK message [DAO and DAO-ACK messages]Route Information [DIO message, Route Information option]
(list of IPv6 prefixes per parent along with lifetime and
preference]Trickle parameters: DIOIntervalDoublings [DIO message, in DODAG configuration
option]DIOIntervalMin [DIO message, in DODAG configuration
option]DIORedundancyConstant [DIO message, in DODAG
configuration option]Path Control Size [DIO message, in DODAG configuration
option]MinHopRankIncrease [DIO message, in DODAG configuration
option]Values that may be monitored only on the DODAG rootTransit 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.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.When possible more granular information about inconsistency
detection should be provided. A RPL implementation MAY provide
counters reporting the number of following inconsistencies:Packets received with 'O' bit set (to Down) from a node with
a higher rankPackets received with 'O' bit cleared (to Up) from a node
with a lower rankNumber of packets with the 'F' bit setNumber of packets with the 'R' bit setA 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 allow for the candidate neighbor list to be monitored with some
metric reflecting local confidence (the degree of stability of the
neighbors) as measured by some metrics.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.For each DODAG, a RPL implementation is expected to keep track of
the following DODAG table values:RPLInstanceIDDODAGIDDODAGVersionNumberRankObjective Code PointA set of DODAG ParentsA set of prefixes offered upwards along the DODAGTrickle timers used to govern the sending of DIO messages for
the DODAGList of DAO parentsDTSNNode status (router versus leaf)A RPL implementation SHOULD allow for monitoring the set of
parameters listed above.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.A RPL implementation SHOULD allow for the following parameters to
be monitored:Next Hop (DODAG parent)Next Hop InterfacePath metrics value for each DODAG parentA DAO Routing Table Entry conceptually contains the following
elements (for storing nodes only):Advertising Neighbor InformationIPv6 AddressInterface ID to which DAO Parents has this entry been
reportedRetry CounterLogical equivalent of DAO Content: DAO-SequencePath SequenceDAO LifetimeDAO Path ControlDestination Prefix (or Address or Mcast Group)A RPL implementation SHOULD provide information about the state
of each DAO Routing Table entry states.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:Memory overflow along with the cause (e.g. routing tables
overflow, ...)Number of times a packet could not be sent to a DODAG parent
flagged as validNumber of times a packet has been received for which the router
did not have a corresponding RPLInstanceIDNumber of times a local repair procedure was triggeredNumber of times a global repair was triggered by the DODAG
rootNumber of received malformed messagesNumber of seconds with packets to forward and no next hop
(DODAG parent)Number of seconds without next hop (DODAG parent)Number of times a node has joined a DODAG as a leaf because it
received a DIO with metric/constraint not understood and it was
configured to join as a leaf node in this case (see ).It is RECOMMENDED to report faults via at least error log messages.
Other protocols may be used to report such faults.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.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).The first policy rules consist of specifying the following
conditions that a RPL node must satisfy to join a DODAG:RPLInstanceIDList of supported routing metrics and constraintsObjective Function (OCP values)A RPL implementation MUST allow configuring these parameters and
SHOULD specify whether the node must simply ignore the DIO if the
advertised DODAG is not compliant with the local policy or whether the
node should join as the leaf node if only the list of supported
routing metrics and constraints, and the OF is not supported.
Additionally a RPL implementation SHOULD allow for the addition of the
DODAGID as part of the policy.A RPL implementation SHOULD allow configuring the set of acceptable
or preferred Objective Functions (OF) referenced by their Objective
Codepoints (OCPs) for a node to join a DODAG, and what action should
be taken if none of a node's candidate neighbors advertise one of the
configured allowable Objective Functions, or if the advertised
metrics/constraint is not understood/supported. Two actions can be
taken in this case:The node joins the DODAG as a leaf node as specified in The node does not join the DODAGA 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.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.A RPL implementation MAY provide an indicator on the size of the
candidate neighbor list.It is RECOMMENDED to quarantine neighbors that start emitting
malformed messages at unacceptable rates.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.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 (). Thus
the impact of RPL on other protocols should be extremely limited.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:Number of repairs and time to repair in seconds (average,
variance)Number of times and duration during which a devices could not
forward a packet because of a lack of reachable neighbor in its
routing tableMonitoring of resources consumption by RPL in terms of
bandwidth and required memoryNumber of RPL control messages sent and receivedThere may be situations where a node should be placed in "verbose"
mode to improve diagnostics. Thus a RPL implementation SHOULD provide
the ability to place a node in and out of verbose mode in order to get
additional diagnostic information.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 a trusted computing
base or 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 out of scope for this specification. Special care, however, needs
to be exercised with respect to interfaces to these higher layers.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 out of scope for this specification. The mechanisms assume a
secure implementation of cryptographic operations and secure and
authentic storage of keying material.The security mechanisms specified provide particular combinations
of the following security services:Assurance that transmitted
information is only disclosed to parties for which it is
intended.Assurance of the source of
transmitted information (and, hereby, that information was not
modified in transit).Assurance that a duplicate of
transmitted information is detected.Assurance that
transmitted information was received in a timely manner.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.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).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.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.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.IANA has defined an ICMPv6 Type Number Registry. The suggested type
value for the RPL Control Message is 155, to be confirmed by IANA.IANA is requested to create a registry, RPL Control Codes, for the
Code field of the ICMPv6 RPL Control Message.New codes may be allocated only by an IETF Review. Each code should
be tracked with the following qualities:CodeDescriptionDefining RFCThe following codes are currently defined:CodeDescriptionReference0x00DODAG Information SolicitationThis document0x01DODAG Information ObjectThis document0x02Destination Advertisement ObjectThis document0x03Destination Advertisement Object AcknowledgmentThis document0x80Secure DODAG Information SolicitationThis document0x81Secure DODAG Information ObjectThis document0x82Secure Destination Advertisement ObjectThis document0x83Secure Destination Advertisement Object AcknowledgmentThis document0x8AConsistency CheckThis documentIANA is requested to create a registry for the 3-bit Mode of
Operation (MOP), which is contained in the DIO Base.New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities:Mode of Operation ValueCapability descriptionDefining RFCFour values are currently defined:MOP valueDescriptionReference0No downward routes maintained by RPLThis document1Non-Storing mode of operationThis document2Storing mode of operation with no multicast supportThis document3Storing mode of operation with multicast supportThis documentThe rest of the range, decimal 4 to 7, is currently unassigned.IANA is requested to create a registry for the RPL Control Message
OptionsNew values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities:ValueMeaningDefining RFCValueMeaningReference0Pad1This document1PadNThis document2DAG Metric ContainerThis Document3Routing InformationThis Document4DODAG ConfigurationThis Document5RPL TargetThis Document6Transit InformationThis Document7Solicited InformationThis Document8Prefix InformationThis Document9Target DescriptorThis DocumentIANA is requested to create a registry to manage the codespace of
the Objective Code Point (OCP) field.No OCP codepoints are defined in this specification.New codes may be allocated only by an IETF Review. Each code should
be tracked with the following qualities:OCP codeDescriptionDefining RFCIANA is requested to create a registry for the values of 8-bit
Algorithm field in the Security Section.New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities:ValueEncryption/MACSignatureDefining RFCThe following value is currently defined:ValueEncryption/MACSignatureReference0CCM with AES-128RSA with SHA-256This documentIANA is requested to create a registry for the 8-bit Security
Section Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCNo bit is currently defined for the Security Section Flags.IANA is requested to create one registry for the 3-bit Security
Level (LVL) Field per allocated KIM value.For a given KIM value, new levels may be allocated only by an IETF
Review. Each level should be tracked with the following qualities:LevelKIM valueDescriptionDefining RFCThe following levels pre KIM value are currently defined:LevelKIM valueDescriptionReference00See This document10See This document20See This document30See This document01See This document11See This document21See This document31See This document02See This document12See This document22See This document32See This document03See This document13See This document23See This document33See This documentIANA is requested to create a registry for the DIS (DODAG
Informational Solicitation) Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCNo bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags.IANA is requested to create a registry for the 8-bit DODAG
Information Object (DIO) Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCNo bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags.IANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following bits are currently defined:Bit numberDescriptionReference0DAO-ACK requestThis document1DODAGID field is presentThis documentIANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Acknowledgement Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following bit is currently defined:Bit numberDescriptionReference0DODAGID field is presentThis documentIANA is requested to create a registry for the 8-bit Consistency
Check (CC) Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following bit is currently defined:Bit numberDescriptionReference0CC ResponseThis documentIANA is requested to create a registry for the 8-bit DODAG
Configuration Option Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following bits are currently defined:Bit numberDescriptionReference4Authentication EnabledThis document5-7Path Control SizeThis documentIANA is requested to create a registry for the 8-bit RPL Target
Option Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCNo bit is currently defined for the RPL Target Option Flags.IANA is requested to create a registry for the 8-bit Transit
Information Option (RIO) Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following bits are currently defined:Bit numberDescriptionReference0ExternalThis documentIANA is requested to create a registry for the 8-bit Solicited
Information Option (RIO) Flag Field.New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following bits are currently defined:Bit numberDescriptionReference0Version Predicate matchThis document1InstanceID Predicate matchThis document2DODAGID Predicate matchThis documentIn 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".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.The rules for assigning new IPv6 multicast addresses are defined in
. This specification requires the
allocation of a new permanent multicast address with a link local
scope for RPL nodes called all-RPL-nodes, with a suggested value of
FF02::1A, to be confirmed by IANA.The authors would like to acknowledge the review, feedback, and
comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel,
Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa
Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar
Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko,
Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru
Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep
Tripathi, and Nicolas Tsiftes.The authors would like to acknowledge the guidance and input provided
by the ROLL Chairs, David Culler and JP Vasseur, and the Area Director
Adrian Farrel.The authors would like to acknowledge prior contributions of Robert
Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Jim
Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom have
provided useful design considerations to RPL.RPL Security Design, found in , ,
and elsewhere throughout the document, is primarily the contribution of
the Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
Levis, Kris Pister, Rene Struik, and Adrian Farrel.Fault-Tolerant Broadcast of Routing
InformationDigital Equipment Corp.FIPS Pub 180-3, Secure Hash Standard
(SHS)This appendix provides some examples to illustrate the dissemination
of addressing information and prefixes with RPL. The examples depict
information being distributed with PIO and RIO options, and the use of
DIO and DAO messages. Note that this appendix is not normative, and that
the specific details of a RPL addressing plan and autoconfiguration may
vary according to specific implementations. RPL merely provides a
vehicle for disseminating information that may be built upon and used by
other mechanisms.Note that these examples illustrate use of address autoconfiguration
schemes supported by information distributed within RPL. However, if an
implementation includes another address autoconfiguration scheme, RPL
nodes might be configured not to set the 'A' flag in PIO options, though
the PIO can still be used to distribute prefix and addressing
information.Consider the simple network illustrated in . In this example there are a group of
routers participating in a RPL network: a DODAG Root, nodes A, Y, and
Z. The DODAG Root and node Z also have connectivity to different
external network domains (i.e. external to the RPL network). Note that
those external networks could be RPL networks or another type of
network altogether.In this example the DODAG Root makes a prefix available to the RPL
subnet for address autoconfiguration. Here the entire RPL subnet uses
that same prefix, RPL::/64, for address autoconfiguration, though in
other implementations more complex/hybrid schemes could be
employed.The DODAG Root has connectivity to an external (with respect to
that RPL network) prefix EXT_1::/64. The DODAG Root may have learned
of connectivity to this prefix, for example, via explicit
configuration or IPv6 ND on a non-RPL interface. The DODAG Root is
configured to announce information on the connectivity to this
prefix.Similarly, Node Z has connectivity to an external prefix
EXT_2::/64. Node Z also has direct connectivity to the node Host1.The DODAG Root adds a RIO to its DIO messages. The RIO contains
the external prefix 2001:DB8:1:1::/64. This information may be
repeated in the DIO messages emitted by the other nodes within the
DODAG. Thus the reachability to the prefix 2001:DB8:1:1::/64 is
disseminated down the DODAG.Node Z may announce the prefix information to a non-RPL aware
host, Host1. Host1 may then participate in address
autoconfiguration and obtain the address, for example,
RPL::Host1.Node Z may interact with another neighboring non-RPL router in
EXT_2::/64. Node Z may repackage the information learned from the
RPL network in order to announce that information into the other
neighboring network. For example, Node Z may repackage a RIO to
indicate reachability to EXT_1::/64.Node Z, on behalf of the non-RPL aware host Host1, will send
DAOs containing Host1 as a Target and itself (Node Z) as a parent
in the Transit Information option. (In storing mode that Transit
Information option does not need to contain the address of Node
Z). A non-storing root then becomes aware of the 1-hop link Node Z
-- Host1 for use in constructing source routes.Node Z may advertise reachability to the target network
EXT_2::/64 by sending DAO messages using EXT_2::/64 as a target in
the Target option and itself (Node Z) as a parent in the Transit
Information option. (In storing mode that Transit Information
option does not need to contain the address of Node Z). A
non-storing root then becomes aware of the 1-hop link (Node Z --
EXT_2::/64) for use in constructing source routes. Node Z may
additionally advertise its reachability to EXT_2::/64 to nodes in
its sub-DODAG by sending DIO messages with a PIO, with the 'A'
flag cleared. illustrates the logical
addressing architecture of a simple RPL network operating in storing
mode. In this example each node, A, B, C, and D, owns its own prefix,
and makes that prefix available for address autoconfiguration by
on-link devices. (This is conveyed by setting the 'A' flag and the 'L'
flag in the PIO of the DIO messages). Node A owns the prefix A::/64,
node B owns B::/64, and so on. Node B autoconfigures an on-link
address with respect to node A, A::B. Nodes C and D similarly
autoconfigure on-link addresses from Node B's prefix, B::C and B::D
respectively. Nodes have the option of setting the 'R' flag and
publishing their address within the Prefix field of the PIO.Node A, for example, will send DIO messages with a PIO as
follows: SetSetClear64A::Node B, for example, will send DIO messages with a PIO as
follows: SetSetSet64B::BNode C, for example, will send DIO messages with a PIO as
follows: SetSetClear64C::Node D, for example, will send DIO messages with a PIO as
follows: SetSetSet64D::DNode B will send DAO messages to node A with the following
information: Target B::/64Target C::/64Target D::/64Node C will send DAO messages to node B with the following
information: Target C::/64Node D will send DAO messages to node B with the following
information: Target D::/64Node A will conceptually collect the following information into
its RIB: A::/64 connectedB::/64 via B's link localC::/64 via B's link localD::/64 via B's link localNode B will conceptually collect the following information into
its RIB: ::/0 via A's link localB::/64 connectedC::/64 via C's link localD::/64 via D's link localNode C will conceptually collect the following information into
its RIB: ::/0 via B's link localC::/64 connectedNode D will conceptually collect the following information into
its RIB: ::/0 via B's link localD::/64 connected illustrates the logical
addressing architecture of a simple RPL network operating in storing
mode. In this example the root node A sources a prefix which is used
for address autoconfiguration over the entire RPL subnet. (This is
conveyed by setting the 'A' flag and clearing the 'L' flag in the PIO
of the DIO messages). Nodes A, B, C, and D all autoconfigure to the
prefix A::/64. Nodes have the option of setting the 'R' flag and
publishing their address within the Prefix field of the PIO.Node A, for example, will send DIO messages with a PIO as
follows: SetClearClear64A::Node B, for example, will send DIO messages with a PIO as
follows: SetClearSet64A::BNode C, for example, will send DIO messages with a PIO as
follows: SetClearClear64A::Node D, for example, will send DIO messages with a PIO as
follows: SetClearSet64A::DNode B will send DAO messages to node A with the following
information: Target A::B/128Target A::C/128Target A::D/128Node C will send DAO messages to node B with the following
information: Target A::C/128Node D will send DAO messages to node B with the following
information: Target A::D/128Node A will conceptually collect the following information into
its RIB: A::/128 connectedB::/128 via B's link localC::/128 via B's link localD::/128 via B's link localNode B will conceptually collect the following information into
its RIB: ::/0 via A's link localB::/128 connectedC::/128 via C's link localD::/128 via D's link localNode C will conceptually collect the following information into
its RIB: ::/0 via B's link localC::/128 connectedNode D will conceptually collect the following information into
its RIB: ::/0 via B's link localD::/128 connected illustrates the logical
addressing architecture of a simple RPL network operating in
non-storing mode. In this example each node, A, B, C, and D, owns its
own prefix, and makes that prefix available for address
autoconfiguration by on-link devices. (This is conveyed by setting the
'A' flag and the 'L' flag in the PIO of the DIO messages). Node A owns
the prefix A::/64, node B owns B::/64, and so on. Node B
autoconfigures an on-link address with respect to node A, A::B. Nodes
C and D similarly autoconfigure on-link addresses from Node B's
prefix, B::C and B::D respectively. Nodes have the option of setting
the 'R' flag and publishing their address within the Prefix field of
the PIO.The PIO contained in the DIO messages in the non-storing mode
with node-owned prefixes can be considered to be identical to those
in the storing mode with node-owned prefixes case ().Node B will send DAO messages to node A with the following
information: Target B::/64, Transit A::BNode C will send DAO messages to node A with the following
information: Target C::/64, Transit B::CNode D will send DAO messages to node A with the following
information: Target D::/64, Transit B::DNode A will conceptually collect the following information into
its RIB. Note that Node A has enough information to construct source
routes by doing recursive lookups into the RIB: A::/64 connectedB::/64 via A::BC::/64 via B::CD::/64 via B::DNode B will conceptually collect the following information into
its RIB: ::/0 via A's link localB::/64 connectedNode C will conceptually collect the following information into
its RIB: ::/0 via B's link localC::/64 connectedNode D will conceptually collect the following information into
its RIB: ::/0 via B's link localD::/64 connected illustrates the logical
addressing architecture of a simple RPL network operating in
non-storing mode. In this example the root node A sources a prefix
which is used for address autoconfiguration over the entire RPL
subnet. (This is conveyed by setting the 'A' flag and clearing the 'L'
flag in the PIO of the DIO messages). Nodes A, B, C, and D all
autoconfigure to the prefix A::/64. Nodes must set the 'R' flag and
publishing their address within the Prefix field of the PIO, in order
to inform their children which address to use in the transit
option.Node A, for example, will send DIO messages with a PIO as
follows: SetClearSet64A::ANode B, for example, will send DIO messages with a PIO as
follows: SetClearSet64A::BNode C, for example, will send DIO messages with a PIO as
follows: SetClearSet64A::CNode D, for example, will send DIO messages with a PIO as
follows: SetClearSet64A::DNode B will send DAO messages to node A with the following
information: Target A::B/128, Transit A::ANode C will send DAO messages to node A with the following
information: Target A::C/128, Transit A::BNode D will send DAO messages to node A with the following
information: Target A::D/128, Transit A::BNode A will conceptually collect the following information into
its RIB. Note that Node A has enough information to construct source
routes by doing recursive lookups into the RIB: A::A/128 connectedB::B/128 via A::AC::C/128 via A::BD::D/128 via A::BNode B will conceptually collect the following information into
its RIB: ::/0 via A's link localA::B/128 connectedNode C will conceptually collect the following information into
its RIB: ::/0 via B's link localA::C/128 connectedNode D will conceptually collect the following information into
its RIB: ::/0 via B's link localA::D/128 connected