rfc6550.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc rfcedstyle="yes" ?>
<rfc submissionType="IETF" consensus="yes" category="std" number="6550" ipr="trust200902">
  <front>
    <title abbrev="RPL">RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>

    <author fullname="Tim Winter" initials="T" role="editor" surname="Winter">
      <organization></organization>

      <address>
        <email>wintert@acm.org</email>
      </address>
    </author>

    <author fullname="Pascal Thubert" initials="P" role="editor"
            surname="Thubert">
      <organization abbrev="Cisco Systems">Cisco Systems</organization>

      <address>
        <postal>
          <street>Village d'Entreprises Green Side</street>

          <street>400, Avenue de Roumanille</street>

          <street>Batiment T3</street>

          <city>Biot - Sophia Antipolis</city>

          <code>06410</code>

          <country>France</country>
        </postal>

        <phone>+33 497 23 26 34</phone>

        <email>pthubert@cisco.com</email>
      </address>
    </author>

    <author fullname="Anders Brandt" initials="A" surname="Brandt">
      <organization abbrev="Sigma Designs">Sigma Designs</organization>

      <address>
        <postal>
          <street>Emdrupvej 26A, 1.</street>

          <city>Copenhagen</city>

          <code>DK-2100</code>

          <country>Denmark</country>
        </postal>

        <email>abr@sdesigns.dk</email>
      </address>
    </author>

    <author fullname="Jonathan W. Hui" initials="J" surname="Hui">
      <organization abbrev="Arch Rock Corporation">Arch Rock
      Corporation</organization>

      <address>
        <postal>
          <street>501 2nd St., Suite 410</street>

          <city>San Francisco</city>

          <region>CA</region>

          <code>94107</code>

          <country>USA</country>
        </postal>

        <email>jhui@archrock.com</email>
      </address>
    </author>

    <author fullname="Richard Kelsey" initials="R" surname="Kelsey">
      <organization abbrev="Ember Corporation">Ember
      Corporation</organization>

      <address>
        <postal>
          <city>Boston</city>

          <region>MA</region>

          <country>USA</country>
        </postal>

        <phone>+1 617 951 1225</phone>

        <email>kelsey@ember.com</email>
      </address>
    </author>

    <author fullname="Philip Levis" initials="P" surname="Levis">
      <organization abbrev="Stanford University">Stanford
      University</organization>

      <address>
        <postal>
          <street>358 Gates Hall, Stanford University</street>

          <city>Stanford</city>

          <region>CA</region>

          <code>94305-9030</code>

          <country>USA</country>
        </postal>

        <email>pal@cs.stanford.edu</email>
      </address>
    </author>

    <author fullname="Kris Pister" initials="K" surname="Pister">
      <organization abbrev="Dust Networks">Dust Networks</organization>

      <address>
        <postal>
          <street>30695 Huntwood Ave.</street>

          <city>Hayward</city>

          <region>CA</region>

          <code>94544</code>

          <country>USA</country>
        </postal>

        <email>kpister@dustnetworks.com</email>
      </address>
    </author>

    <author fullname="Rene Struik" initials="R" surname="Struik">
      <organization abbrev="Struik Security Consultancy">Struik Security Consultancy</organization>
      <address>
        <email>rstruik.ext@gmail.com</email>
      </address>
    </author>

    <author fullname="JP. Vasseur" initials="JP" surname="Vasseur">
      <organization abbrev="Cisco Systems">Cisco Systems</organization>

      <address>
        <postal>
          <street>11, Rue Camille Desmoulins</street>

          <city>Issy Les Moulineaux</city>

          <code>92782</code>

          <country>France</country>
        </postal>

        <email>jpv@cisco.com</email>
      </address>
    </author>

   <author fullname="Roger K. Alexander" initials="R" surname="Alexander">
     <organization abbrev="Cooper Power Systems"> Cooper Power
Systems</organization>
     <address>
       <postal>
         <street>20201 Century Blvd., Suite 250</street>
         <city>Germantown</city><region>MD</region>
         <code>20874</code>
         <country>USA</country>
       </postal>
       <phone>+1 240 454 9817</phone>
       <email>roger.alexander@cooperindustries.com</email>
     </address>
   </author> 

    <date  month="March" year="2012" />

    <area>Routing Area</area>

    <workgroup>ROLL</workgroup>


    <abstract>
      <t>Low-Power and Lossy Networks (LLNs) are a class of network in which
      both the routers and their interconnect are constrained. LLN routers
      typically operate with constraints on 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 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 Low-Power and Lossy Networks (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 are supported.
      Support for point-to-point traffic is also available.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Low-power and Lossy Networks (LLNs) consist largely of constrained
      nodes (with limited processing power, memory, and sometimes energy when
      they are battery operated or energy scavenging). These routers are
      interconnected by lossy links, typically supporting only low data rates,
      that are usually unstable with relatively low packet delivery rates.
      Another characteristic of such networks is that the traffic patterns are
      not simply point-to-point, but in many cases point-to-multipoint or
      multipoint-to-point. Furthermore, such networks may potentially comprise
      up to thousands of nodes. These characteristics offer unique challenges
      to a routing solution: the IETF ROLL working group has defined
      application-specific routing requirements for a Low-power and Lossy
      Network (LLN) routing protocol, specified in <xref
      target="RFC5867"></xref>, <xref target="RFC5826"></xref>, <xref
      target="RFC5673"></xref>, and <xref target="RFC5548"></xref>.</t>

      <t>This document specifies the IPv6 Routing Protocol for LLNs (RPL). Note that although RPL was specified according to
      the requirements set forth in the aforementioned requirement documents,
      its use is in no way limited to these applications.</t>

      <section title="Design Principles">
        <t>RPL was designed with the objective to meet the requirements
        spelled out in <xref target="RFC5867"></xref>, <xref
        target="RFC5826"></xref>, <xref target="RFC5673"></xref>, and <xref
        target="RFC5548"></xref>.</t>

        <t>A network may run multiple instances of RPL concurrently. Each such
        instance may serve different and potentially antagonistic constraints
        or performance criteria. This document defines how a single instance
        operates.</t>

        <t>In order to be useful in a wide range of LLN application domains,
        RPL separates packet processing and forwarding from the routing
        optimization objective. Examples of such objectives include minimizing
        energy, minimizing latency, or satisfying constraints. This document
        describes the mode of operation of RPL. Other companion documents
        specify routing Objective Functions. A RPL implementation, in support
        of a particular LLN application, will include the necessary Objective
        Function(s) as required by the application.</t>

        <t>RPL operations require bidirectional links. In some LLN scenarios,
        those links may exhibit asymmetric properties. It is required that the
        reachability of a router be 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 (BFD) <xref target="RFC5881"></xref> and hints from
        lower layers via Layer 2 (L2) triggers like <xref target="RFC5184"></xref>. 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.</t>

        <t>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 <xref
        target="loopdetect"></xref> and enables the association of a data
        packet with a RPL Instance and the validation of RPL routing states.
        The RPL option <xref
        target="RFC6553"></xref> 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 <xref
        target="DownwardRoutes"></xref>), 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.</t>

        <t>RPL provides a mechanism to disseminate information over the
        dynamically formed network topology. This dissemination enables minimal
        configuration in the nodes, allowing nodes to operate mostly
        autonomously. This mechanism uses <xref
        target="RFC6206">Trickle</xref> to optimize the
        dissemination as described in <xref
        target="DIOTransmission"></xref>.</t>

        <t>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.</t>

        <t>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.</t>

        <t>In particular, RPL may disseminate IPv6 Neighbor Discovery (ND)
        information such as the <xref target="RFC4861"></xref> Prefix
        Information Option (PIO) and the <xref target="RFC4191"></xref> 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
        <xref target="RFC4191"></xref>, <xref target="RFC4861"></xref>, <xref
        target="RFC4862"></xref>, and <xref target="RFC6275"></xref>. As a
        router, the RPL node may advertise the information from the options as
        required for the specific link, for instance, in an ND Router Advertisement (RA) message,
        though the exact operation is out of scope.</t>

        <t>A set of companion documents to this specification will provide
        further guidance in the form of applicability statements specifying a
        set of operating points appropriate to the Building Automation, Home
        Automation, Industrial, and Urban application scenarios.</t>
      </section>

      <section title="Expectations of Link-Layer Type">
        <t>In compliance with the layered architecture of IP, RPL does not
        rely on any particular features of a specific link-layer technology.
        RPL is designed to be able to operate over a variety of different link
        layers, including ones that are constrained, potentially lossy, or
        typically utilized in conjunction with highly constrained host or
        router devices, such as but not limited to, low-power wireless or PLC
        (Power Line Communication) technologies.</t>

        <t>Implementers may find <xref target="RFC3819"></xref> a useful
        reference when designing a link-layer interface between RPL and a
        particular link-layer technology.</t>
      </section>
    </section>

    <section anchor="Terminology" title="Terminology">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>

      <t>Additionally, this document uses terminology from <xref
      target="ROLL-TERMS"></xref>, and introduces the following
      terminology: <list hangIndent="15" style="hanging">
          <t hangText="DAG:">Directed Acyclic Graph. A directed graph having
          the property that all edges are oriented in such a way that no
          cycles exist. All edges are contained in paths oriented toward and
          terminating at one or more root nodes.</t>

          <t hangText="DAG root:">A DAG root is a node within the DAG that has
          no outgoing edge. Because the graph is acyclic, by definition, all
          DAGs must have at least one DAG root and all paths terminate at a
          DAG root.</t>

          <t hangText="Destination-Oriented DAG (DODAG):">
<vspace />
A DAG rooted at a
          single destination, i.e., at a single DAG root (the DODAG root) with
          no outgoing edges.</t>

          <t hangText="DODAG root:">A DODAG root is the DAG root of a DODAG.
          The DODAG root may act as a border router for the DODAG; in
          particular, it may aggregate routes in the DODAG and may
          redistribute DODAG routes into other routing protocols.</t>

          <t hangText="Virtual DODAG root:"><vspace />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).</t>

          <t hangText="Up:">Up refers to the direction from leaf nodes towards
          DODAG roots, following DODAG edges. This follows the common
          terminology used in graphs and depth-first-search, where vertices
          further from the root are "deeper" or "down" and vertices closer
          to the root are "shallower" or "up".</t>

          <t hangText="Down:">Down refers to the direction from DODAG roots
          towards leaf nodes, in the reverse direction of DODAG edges. This
          follows the common terminology used in graphs and
          depth-first-search, where vertices further from the root are
          "deeper" or "down" and vertices closer to the root are
          "shallower" or "up".</t>

          <t hangText="Rank:">A node's Rank defines the node's individual
          position relative to other nodes with respect to a DODAG root. Rank
          strictly increases in the Down direction and strictly decreases in
          the Up direction. The exact way Rank is computed depends on the
          DAG's Objective Function (OF). The Rank may analogously track a
          simple topological distance, may be calculated as a function of link
          metrics, and may consider other properties such as constraints.</t>

          <t hangText="Objective Function (OF):"><vspace />An OF defines how routing metrics,
          optimization objectives, and related functions are used to compute
          Rank. Furthermore, the OF dictates how parents in the DODAG are
          selected and, thus, the DODAG formation.</t>

          <t hangText="Objective Code Point (OCP):"><vspace />An OCP is an identifier that
          indicates which Objective Function the DODAG uses.</t>

          <t hangText="RPLInstanceID:">A RPLInstanceID is a unique identifier within a network.
          DODAGs with the same RPLInstanceID share the same Objective
          Function.</t>

          <t hangText="RPL Instance:">A RPL Instance is a set of one or more DODAGs that share a
          RPLInstanceID. At most, a RPL node can belong to one DODAG in a RPL
          Instance. Each RPL Instance operates independently of other RPL
          Instances. This document describes operation within a single RPL
          Instance.</t>

          <t hangText="DODAGID:">A DODAGID is the identifier of a DODAG root. The DODAGID
          is unique within the scope of a RPL Instance in the LLN. The tuple
          (RPLInstanceID, DODAGID) uniquely identifies a DODAG.</t>

          <t hangText="DODAG Version:">A DODAG Version is a specific iteration ("Version") of a
          DODAG with a given DODAGID.</t>

          <t hangText="DODAGVersionNumber:">A DODAGVersionNumber is a sequential counter that is
          incremented by the root to form a new Version of a DODAG. A DODAG
          Version is identified uniquely by the (RPLInstanceID, DODAGID,
          DODAGVersionNumber) tuple.</t>

          <t hangText="Goal:">The Goal is an application-specific goal that is
          defined outside the scope of RPL. Any node that roots a DODAG will
          need to know about this Goal to decide whether or not the Goal can be satisfied. 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
          is connected to a specific database host to store the collected
          data).</t>

          <t hangText="Grounded:">A DODAG is grounded when the DODAG root can
          satisfy the Goal.</t>

          <t hangText="Floating:">A DODAG is floating if it is not grounded. A
          floating DODAG is not expected to have the properties required to
          satisfy the goal. It may, however, provide connectivity to other
          nodes within the DODAG.</t>

          <t hangText="DODAG parent:">A parent of a node within a DODAG is one
          of the immediate successors of the node on a path towards the DODAG
          root. A DODAG parent's Rank is lower than the node's. (See <xref
          target="RankComparison"></xref>).</t>

          <t hangText="Sub-DODAG:">The sub-DODAG of a node is the set of other
          nodes whose paths to the DODAG root pass through that node. Nodes in
          the sub-DODAG of a node have a greater Rank than that node. (See
          <xref target="RankComparison"></xref>).</t>

          <t hangText="Local DODAG:">Local DODAGs contain one and only one
          root node, and they allow that single root node to allocate and manage a
          RPL Instance, identified by a local RPLInstanceID, without
          coordination with other nodes. Typically, this is done in order to
          optimize routes to a destination within the LLN. (See <xref
          target="RPLInstance"></xref>).</t>

          <t hangText="Global DODAG:">A Global DODAG uses a global
          RPLInstanceID that may be coordinated among several other nodes.
          (See <xref target="RPLInstance"></xref>).</t>

          <t hangText="DIO:">DODAG Information Object (see <xref
          target="DAGInformationObject"></xref>)</t>

          <t hangText="DAO:">Destination Advertisement Object (see <xref
          target="DestinationAdvertisementObject"></xref>)</t>

          <t hangText="DIS:">DODAG Information Solicitation (see <xref
          target="DAGInformationSolicitation"></xref>)</t>

          <t hangText="CC:">Consistency Check (see <xref
          target="ConsistencyCheck"></xref>)</t>
        </list></t>

      <t>As they form networks, LLN devices often mix the roles of host and
      router when compared to traditional IP networks. In this document,
      "host" refers to an LLN device that can generate but does not forward
      RPL traffic; "router" refers to an LLN device that can forward as well
      as generate RPL traffic; and "node" refers to any RPL device, either a
      host or a router.</t>
    </section>

    <section anchor="ProtocolModel" title="Protocol Overview">
      <t>The aim of this section is to describe RPL in the spirit of <xref
      target="RFC4101"></xref>. Protocol details can be found in further
      sections.</t>

      <section anchor="UpwardTopology" title="Topologies">
        <t>This section describes the basic RPL topologies that may be formed,
        and the rules by which these are constructed, i.e., the rules governing
        DODAG formation.</t>

        <section anchor="Subnet routing" title="Constructing Topologies">
          <t>LLNs, such as Radio Networks, do not typically have predefined
          topologies, for example, those imposed by point-to-point wires, so
          RPL has to discover links and then select peers sparingly.</t>

          <t>In many cases, because Layer 2 ranges overlap only partially, RPL
          forms non-transitive / Non-Broadcast Multi-Access (NBMA) network topologies upon which it computes
          routes.</t>

          <t>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.</t>
        </section>

        <section anchor="TopologyIdentifiers" title="RPL Identifiers">
          <t>RPL uses four values to identify and maintain a topology: <list
              style="symbols">
              <t>The first is a RPLInstanceID. A RPLInstanceID identifies a
              set of one or more Destination Oriented DAGs (DODAGs). A network
              may have multiple RPLInstanceIDs, each of which defines an
              independent set of DODAGs, which may be optimized for different
              Objective Functions (OFs) and/or applications. The set of DODAGs
              identified by a RPLInstanceID is called a RPL Instance. All
              DODAGs in the same RPL Instance use the same OF.</t>

              <t>The second is a DODAGID. The scope of a DODAGID is a RPL
              Instance. The combination of RPLInstanceID and DODAGID uniquely
              identifies a single DODAG in the network. A RPL Instance may
              have multiple DODAGs, each of which has an unique DODAGID.</t>

              <t>The third is a DODAGVersionNumber. The scope of a
              DODAGVersionNumber is a DODAG. A DODAG is sometimes
              reconstructed from the DODAG root, by incrementing the
              DODAGVersionNumber. The combination of RPLInstanceID, DODAGID,
              and DODAGVersionNumber uniquely identifies a DODAG Version.</t>

              <t>The fourth is Rank. The scope of Rank is a DODAG Version.
              Rank establishes a partial order over a DODAG Version, defining
              individual node positions with respect to the DODAG root.</t>
            </list></t>
        </section>

        <section title="Instances, DODAGs, and DODAG Versions">
          <t>A RPL Instance contains one or more DODAG roots. A RPL Instance
          may provide routes to certain destination prefixes, reachable via
          the DODAG roots or alternate paths within the DODAG. These roots may
          operate independently, or they may coordinate over a network that is not
          necessarily as constrained as an LLN.</t>

          <t>A RPL Instance may comprise:</t>

          <t><list style="symbols">
              <t>a single DODAG with a single root <list>
                  <t>For example, a DODAG optimized to minimize latency rooted
                  at a single centralized lighting controller in a Home
                  Automation application.</t>
                </list></t>

              <t>multiple uncoordinated DODAGs with independent roots
              (differing DODAGIDs) <list>
                  <t>For example, multiple data collection points in an urban
                  data collection application that do not have suitable
                  connectivity to coordinate with each other or that use the
                  formation of multiple DODAGs as a means to dynamically and
                  autonomously partition the network.</t>
                </list></t>

              <t>a single DODAG with a virtual root that coordinates LLN sinks
              (with the same DODAGID) over a backbone network.<list>
                  <t>For example, multiple border routers operating with a
                  reliable transit link, e.g., in support of an IPv6 Low-Power Wireless
   Personal Area Network (6LoWPAN)
                  application, that are capable of acting as logically equivalent
                  interfaces to the sink of the same DODAG.</t>
                </list></t>

              <t>a combination of the above as suited to some application
              scenario.</t>
            </list></t>

          <t>Each RPL packet is associated with a particular RPLInstanceID
          (see <xref target="loopdetect"></xref>) and, therefore, RPL Instance
          (<xref target="RPLInstance"></xref>). The provisioning or automated
          discovery of a mapping between a RPLInstanceID and a type or service
          of application traffic is out of scope for this specification (to be
          defined in future companion specifications).</t>

          <t><xref target="figInstance"></xref> depicts an example of a RPL
          Instance comprising three DODAGs with DODAG roots R1, R2, and R3.
          Each of these DODAG roots advertises the same RPLInstanceID. The
          lines depict connectivity between parents and children.</t>

          <t><xref target="figDODAGVersion"></xref> depicts how a DODAGVersionNumber increment leads to a new DODAG Version. This
          depiction illustrates a DODAGVersionNumber increment that results
          in a different DODAG topology. Note that a new DODAG Version does
          not always imply a different DODAG topology. To accommodate certain
          topology changes requires a new DODAG Version, as described later in
          this specification.</t>

          <t>In the following examples, please note that tree-like structures
          are depicted for simplicity, although the DODAG structure allows for
          each node to have multiple parents when the connectivity supports
          it.</t>

          <figure anchor="figInstance" title="RPL Instance">
            <artwork><![CDATA[
 
  +----------------------------------------------------------------+
  |                                                                |
  | +--------------+                                               |
  | |              |                                               |
  | |     (R1)     |            (R2)                   (R3)        |
  | |     /  \     |            /| \                  / |  \       |
  | |    /    \    |           / |  \                /  |   \      |
  | |  (A)    (B)  |         (C) |  (D)     ...    (F) (G)  (H)    |
  | |  /|\     |\  |         /   | / |\             |\  |    |     |
  | | : : :    : : |        :   (E)  : :            :  `:    :     |
  | |              |            / \                                |
  | +--------------+           :   :                               |
  |      DODAG                                                     |
  |                                                                |
  +----------------------------------------------------------------+
                             RPL Instance                           
]]></artwork>
          </figure>

          <figure anchor="figDODAGVersion" title="DODAG Version">
            <artwork><![CDATA[
                                                                     
         +----------------+                +----------------+        
         |                |                |                |        
         |      (R1)      |                |      (R1)      |        
         |      /  \      |                |      /         |        
         |     /    \     |                |     /          |        
         |   (A)    (B)   |         \      |   (A)          |        
         |   /|\   / |\   |    ------\     |   /|\          |        
         |  : : (C)  : :  |           \    |  : : (C)       |        
         |                |           /    |        \       |        
         |                |    ------/     |         \      |        
         |                |         /      |         (B)    |        
         |                |                |          |\    |        
         |                |                |          : :   |        
         |                |                |                |        
         +----------------+                +----------------+        
             Version N                        Version N+1            
                                                                     
]]></artwork>
          </figure>
        </section>
      </section>

      <section title="Upward Routes and DODAG Construction">
        <t>RPL provisions routes Up towards DODAG roots, forming a DODAG
        optimized according to an Objective Function (OF). RPL nodes construct
        and maintain these DODAGs through DODAG Information Object (DIO)
        messages.</t>

        <section title="Objective Function (OF)">
          <t>The Objective Function (OF) defines how RPL nodes select and
          optimize routes within a RPL Instance. The OF is identified by an
          Objective Code Point (OCP) within the DIO Configuration option. An
          OF defines how nodes translate one or more metrics and constraints,
          which are themselves defined in <xref
          target="RFC6551"></xref>, into a value called
          Rank, which approximates the node's distance from a DODAG root. An
          OF also defines how nodes select parents. Further details may be
          found in <xref target="OFGuide"></xref>, <xref
          target="RFC6551"></xref>, <xref
          target="RFC6552"></xref>, and related companion
          specifications.</t>
        </section>

        <section anchor="DODAGRepair" title="DODAG Repair">
          <t>A DODAG root institutes a global repair operation by incrementing
          the DODAGVersionNumber. This initiates a new DODAG Version. Nodes
          in the new DODAG Version can choose a new position whose Rank is not
          constrained by their Rank within the old DODAG Version.</t>

          <t>RPL also supports mechanisms that may be used for local repair
          within the DODAG Version. The DIO message specifies the necessary
          parameters as configured from and controlled by policy at the DODAG
          root.</t>
        </section>

        <section title="Security">
          <t>RPL supports message confidentiality and integrity. It is
          designed such that link-layer mechanisms can be used when available
          and appropriate; yet, in their absence, RPL can use its own
          mechanisms. RPL has three basic security modes.</t>

          <t>In the first, called "unsecured", RPL control messages are sent
          without any additional security mechanisms. Unsecured mode does not
          imply that the RPL network is unsecure: it could be using other
          present security primitives (e.g., link-layer security) to meet
          application security requirements.</t>

          <t>In the second, called "preinstalled", nodes joining a RPL
          Instance have preinstalled keys that enable them to process and
          generate secured RPL messages.</t>

          <t>The third mode is called "authenticated".  In authenticated mode,
          nodes have preinstalled keys as in preinstalled mode, but the
          preinstalled 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 <xref
          target="KeyInstallation"></xref>.</t>
        </section>

        <section title="Grounded and Floating DODAGs">
          <t>DODAGs can be grounded or floating: the DODAG root advertises
          which is the case. A grounded DODAG offers connectivity to hosts
          that are required for satisfying the application-defined goal. A
          floating DODAG is not expected to satisfy the goal; in most cases, it
          only provides routes to nodes within the DODAG. Floating DODAGs may
          be used, for example, to preserve interconnectivity during
          repair.</t>
        </section>

        <section title="Local DODAGs">
          <t>RPL nodes can optimize routes to a destination within an LLN by
          forming a Local DODAG whose DODAG root is the desired destination.
          Unlike global DAGs, which can consist of multiple DODAGs, local DAGs
          have one and only one DODAG and therefore one DODAG root. Local
          DODAGs can be constructed on demand.</t>
        </section>

        <section title="Administrative Preference">
          <t>An implementation/deployment may specify that some DODAG roots
          should be used over others through an administrative preference.
          Administrative preference offers a way to control traffic and
          engineer DODAG formation in order to better support application
          requirements or needs.</t>
        </section>

        <section title="Data-Path Validation and Loop Detection">
          <t>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.</t>

          <t>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.</t>

          <t>For example, if a node receives a packet flagged as moving in the
          Upward direction, and if that packet records that the transmitter is
          of a lower (lesser) Rank than the receiving node, then the receiving
          node is able to conclude that the packet has not progressed in the
          Upward direction and that the DODAG is inconsistent.</t>
        </section>

        <section anchor="daop" title="Distributed Algorithm Operation">
          <t>A high-level overview of the distributed algorithm, which
          constructs the DODAG, is as follows:</t>

          <t><list style="symbols">
              <t>Some nodes are configured to be DODAG roots, with associated
              DODAG configurations.</t>

              <t>Nodes advertise their presence, affiliation with a DODAG,
              routing cost, and related metrics by sending link-local
              multicast DIO messages to all-RPL-nodes.</t>

              <t>Nodes listen for DIOs and use their information to join a new
              DODAG (thus, selecting DODAG parents), or to maintain an existing
              DODAG, according to the specified Objective Function and Rank of
              their neighbors.</t>

              <t>Nodes provision routing table entries, for the destinations
              specified by the DIO message, via their DODAG parents in the
              DODAG Version. Nodes that decide to join a DODAG 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.</t>
            </list></t>
        </section>
      </section>

      <section title="Downward Routes and Destination Advertisement">
        <t>RPL uses Destination Advertisement Object (DAO) messages to
        establish Downward routes. DAO messages are an optional feature for
        applications that require point-to-multipoint (P2MP) or point-to-point (P2P) traffic. RPL supports two modes
        of Downward traffic: Storing (fully stateful) or Non-Storing (fully
        source routed); see <xref target="DownwardRoutes" />. Any given RPL Instance is either storing or
        non-storing. In both cases, P2P packets travel Up toward a DODAG root
        then Down to the final destination (unless the destination is on the
        Upward route). In the Non-Storing case, the packet will travel all the
        way to a DODAG root before traveling Down. In the Storing case, the
        packet may be directed Down towards the destination by a common
        ancestor of the source and the destination prior to reaching a DODAG
        root.</t>

        <t>As of the writing of this specification, no implementation is expected to support
        both Storing and Non-Storing modes of operation. Most implementations
        are expected to support either no Downward routes, Non-Storing mode
        only, or Storing mode only. Other modes of operation, such as a hybrid
        mix of Storing and Non-Storing mode, are out of scope for this
        specification and may be described in other companion
        specifications.</t>

        <t>This specification describes a basic mode of operation in support
        of P2P traffic. Note that more optimized P2P solutions may be
        described in companion specifications.</t>
      </section>

      <section title="Local DODAGs Route Discovery">
        <t>Optionally, a RPL network can support on-demand discovery of DODAGs
        to specific destinations within an LLN. Such Local DODAGs behave
        slightly differently than Global DODAGs: they are uniquely defined by
        the combination of DODAGID and RPLInstanceID. The RPLInstanceID
        denotes whether a DODAG is a Local DODAG.</t>
      </section>

      <section anchor="DAGRank" title="Rank Properties">
        <t>The Rank of a node is a scalar representation of the location of
        that node within a DODAG Version. The Rank is used to avoid and detect
        loops and, as such, must demonstrate certain properties. The exact
        calculation of the Rank is left to the Objective Function. 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.</t>

        <t>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 considered a scalar representation of the
        location or radius of a node within a DODAG Version.</t>

        <t>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 <xref target="OFGuide"></xref> for
        more information.</t>

        <t>The Rank is not a path cost, although its value can be derived from
        and influenced by path metrics. The Rank has properties of its own
        that are not necessarily those of all metrics: <list hangIndent="8"
            style="hanging" hangIndent="15">
            <t hangText="Type:">The Rank is an abstract numeric value.</t>

            <t hangText="Function:">The Rank is the expression of a relative
            position within a DODAG Version with regard to neighbors, and it is
            not necessarily a good indication or a proper expression of a
            distance or a path cost to the root.</t>

            <t hangText="Stability:">The stability of the Rank determines the
            stability of the routing topology. Some dampening or filtering is
            RECOMMENDED to keep the topology stable; thus, the Rank does
            not necessarily change as fast as some link or node metrics would.
            A new DODAG Version would be a good opportunity to reconcile the
            discrepancies that might form over time between metrics and Ranks
            within a DODAG Version.</t>

            <t hangText="Properties:">The Rank is incremented in a strictly
            monotonic fashion, and it can be used to validate a progression from
            or towards the root. A metric, like bandwidth or jitter, does not
            necessarily exhibit this property.</t>

            <t hangText="Abstract:">The Rank does not have a physical unit,
            but rather a range of increment per hop, where the assignment of
            each increment is to be determined by the Objective Function.</t>
          </list></t>

        <t>The Rank value feeds into DODAG parent selection, according to the
        RPL loop-avoidance strategy. Once a parent has been added, and a Rank
        value for the node within the DODAG has been advertised, the node's
        further options with regard to DODAG parent selection and movement
        within the DODAG are restricted in favor of loop avoidance.</t>

        <section anchor="RankComparison" title="Rank Comparison (DAGRank())">
          <t>Rank may be thought of as a fixed-point number, where the
          position of the radix point between the integer part and the
          fractional part is determined by MinHopRankIncrease.
          MinHopRankIncrease is the minimum increase in Rank between a node
          and any of its DODAG parents. A DODAG root provisions
          MinHopRankIncrease. MinHopRankIncrease creates a trade-off 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 effect on Rank but cannot
          support many hops.</t>

          <t>When an Objective Function computes Rank, the Objective Function
          operates on the entire (i.e., 16-bit) Rank quantity. When Rank is
          compared, e.g., for determination of parent relationships or loop
          detection, the integer portion of the Rank is to be used. The
          integer portion of the Rank is computed by the DAGRank() macro as
          follows, where floor(x) is the function that evaluates to the
          greatest integer less than or equal to x:</t>

          <figure>
            <artwork><![CDATA[
                                                                     
           DAGRank(rank) = floor(rank/MinHopRankIncrease)            
                                                                     
]]></artwork>
          </figure>

          <t>For example, if a 16-bit Rank quantity is decimal 27, and the
          MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) =
          1. The integer part of the Rank is 1 and the fractional part is
          11/16.</t>

          <t>Following the conventions in this document, using the macro DAGRank(node) may
          be interpreted as DAGRank(node.rank), where node.rank is the Rank
          value as maintained by the node.</t>

          <t>A Node A has a Rank less than the Rank of a Node B if DAGRank(A)
          is less than DAGRank(B).</t>

          <t>A Node A has a Rank equal to the Rank of a Node B if DAGRank(A)
          is equal to DAGRank(B).</t>

          <t>A Node A has a Rank greater than the Rank of a Node B if
          DAGRank(A) is greater than DAGRank(B).</t>
        </section>

        <section title="Rank Relationships">
          <t>Rank computations maintain the following properties for any nodes
          M and N that are neighbors in the LLN:</t>

          <t><list style="empty">
              <t>DAGRank(M) is less than DAGRank(N):</t> <t>In this case,
              the position of M is closer to the DODAG root than the position
              of N.&nbsp; 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 a Rank less than DAGRank(N). In
              other words, the Rank presented by a Node N MUST be greater than
              that presented by any of its parents.</t>

              <t>DAGRank(M) equals DAGRank(N):</t><t>In this case, the
              positions of M and N within the DODAG and with respect to the
              DODAG root are similar or identical. Routing through a node with
              equal Rank may cause a routing loop (i.e., if that node chooses
              to route through a node with equal Rank as well).</t>

              <t>DAGRank(M) is greater than DAGRank(N):</t><t>In this
              case, the position of M is farther from the DODAG root than the
              position of N.&nbsp; Further, Node M may in fact be in the sub-DODAG
              of Node N.&nbsp; If Node N selects Node M as DODAG parent, there is a
              risk of creating a loop.</t>
            </list></t>

          <t>As an example, the Rank could be computed in such a way so as to
          closely track ETX (expected transmission count, a fairly common
          routing metric used in LLN and defined in <xref
          target="RFC6551"></xref>) when the metric that
          an Objective Function minimizes is ETX, or latency, or in a more
          complicated way as appropriate to the Objective Function being used
          within the DODAG.</t>
        </section>
      </section>

      <section anchor="ConstrainedLLNs"
               title="Routing Metrics and Constraints Used by RPL">
        <t>Routing metrics are used by routing protocols to compute shortest
        paths. Interior Gateway Protocols (IGPs) such as IS-IS (<xref
        target="RFC5120"></xref>) and OSPF (<xref target="RFC4915"></xref>)
        use static link metrics. Such link metrics can simply reflect the
        bandwidth or can also be computed according to a polynomial function
        of several metrics defining different link characteristics. Some
        routing protocols support more than one metric: in the vast majority
        of the cases, one metric is used per (sub-)topology. Less often, a
        second metric may be used as a tiebreaker in the presence of Equal
        Cost Multiple Paths (ECMPs). The optimization of multiple metrics is
        known as an NP-complete problem and is sometimes supported by some
        centralized path computation engine.</t>

        <t>In contrast, LLNs do require the support of both static and dynamic
        metrics. Furthermore, both link and node metrics are required. In the
        case of RPL, it is virtually impossible to define one metric, or even
        a composite metric, that will satisfy all use cases.</t>

        <t>In addition, RPL supports constraint-based routing where
        constraints may be applied to both link and nodes. If a link or a node
        does not satisfy a required constraint, it is "pruned" from the
        candidate neighbor set, thus leading to a constrained shortest
        path.</t>

        <t>An Objective Function specifies the objectives used to compute the
        (constrained) path. Furthermore, nodes are configured to support a set
        of metrics and constraints and select their parents in the DODAG
        according 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
        regard to the rules for Rank computation.</t>

        <t>The Objective Function is decoupled from the routing metrics and
        constraints used by RPL. Whereas the OF dictates rules such as
        DODAG parent selection, load balancing, and so on, the set of metrics
        and/or constraints used, and thus those that determine the preferred path, are
        based on the information carried within the DAG container option in
        DIO messages.</t>

        <t>The set of supported link/node constraints and metrics is specified
        in <xref target="RFC6551"></xref>.</t>

        <t><list hangIndent="11" style="hanging">
            <t hangText="Example 1:">Shortest path: path offering the shortest
            end-to-end delay.</t>

            <t hangText="Example 2:">Shortest Constrained path: the path that
            does not traverse any battery-operated node and that optimizes the
            path reliability.</t>
          </list></t>
      </section>

      <section title="Loop Avoidance">
        <t>RPL tries to avoid creating loops when undergoing topology changes
        and includes Rank-based data-path validation mechanisms for detecting
        loops when they do occur (see <xref target="forwarding"></xref> for
        more details). In practice, this means that RPL guarantees neither
        loop-free path selection nor tight delay convergence times, but it can
        detect and repair a loop as soon as it is used. RPL uses this loop
        detection to ensure that packets make forward progress within the
        DODAG Version and trigger repairs when necessary.</t>

        <section title="Greediness and Instability">
          <t>A node is greedy if it attempts to move deeper (increase Rank) in
          the DODAG Version in order to increase the size of the parent set or
          improve some other metric. Once a node has joined a DODAG Version,
          RPL disallows certain behaviors, including greediness, in order to
          prevent resulting instabilities in the DODAG Version.</t>

          <t>Suppose a node is willing to receive and process a DIO message
          from a node in its own sub-DODAG and, in general, a node deeper than
          itself. In this case, a possibility exists that a feedback loop is
          created, wherein two or more nodes continue to try and move in the
          DODAG Version while attempting to optimize against each other. In
          some cases, this will result in instability. It is for this reason
          that RPL limits the cases where a node may process DIO messages from
          deeper nodes to some form of local repair. This approach creates an
          "event horizon", whereby a node cannot be influenced beyond some
          limit into an instability by the action of nodes that may be in its
          own sub-DODAG.</t>

          <section anchor="ExGreedyExample"
                   title="Example: Greedy Parent Selection and Instability">
            <figure anchor="Greedy" title="Greedy DODAG Parent Selection">
              <artwork><![CDATA[
                                                                     
      (A)                    (A)                    (A)              
       |\                     |\                     |\              
       | `-----.              | `-----.              | `-----.       
       |        \             |        \             |        \      
      (B)       (C)          (B)        \            |        (C)    
                               \        |            |        /      
                                `-----. |            | .-----'       
                                       \|            |/              
                                       (C)          (B)              
                                                                     
           -1-                    -2-                    -3-         
                                                                     
]]></artwork>
            </figure>

            <t><xref target="Greedy"></xref> depicts a DODAG in three different
            configurations. A usable link between (B) and (C) exists in all three
            configurations. In <xref target="Greedy"></xref>-1, Node (A) is a
            DODAG parent for Nodes (B) and (C). In <xref
            target="Greedy"></xref>-2, Node (A) is a DODAG parent for Nodes
            (B) and (C), and Node (B) is also a DODAG parent for Node (C). In
            <xref target="Greedy"></xref>-3, Node (A) is a DODAG parent for
            Nodes (B) and (C), and Node (C) is also a DODAG parent for Node
            (B).</t>

            <t>If a RPL node is too greedy, in that it attempts to optimize
            for an additional number of parents beyond its most preferred
            parents, then an instability can result. Consider the DODAG
            illustrated in <xref target="Greedy"></xref>-1. In this example,
            Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but
            we will consider the case when they are operating under the greedy
            condition that will try to optimize for two parents.</t>

            <t><list style="symbols">
                <t>Let <xref target="Greedy"></xref>-1 be the initial
                condition.</t>

                <t>Suppose Node (C) first is able to leave the DODAG and
                rejoin at a lower Rank, taking both Nodes (A) and (B) as DODAG
                parents as depicted in <xref target="Greedy"></xref>-2. Now
                Node (C) is deeper than both Nodes (A) and (B), and Node (C)
                is satisfied to have two DODAG parents.</t>

                <t>Suppose Node (B), in its greediness, is willing to receive
                and process a DIO message from Node (C) (against the rules of
                RPL), and then Node (B) leaves the DODAG and rejoins at a
                lower Rank, taking both Nodes (A) and (C) as DODAG parents.
                Now Node (B) is deeper than both Nodes (A) and (C) and is
                satisfied with two DAG parents.</t>

                <t>Then, Node (C), because it is also greedy, will leave and
                rejoin deeper, to again get two parents and have a lower Rank
                then both of them.</t>

                <t>Next, Node (B) will again leave and rejoin deeper, to again
                get two parents.</t>

                <t>Again, Node (C) leaves and rejoins deeper.</t>

                <t>The process will repeat, and the DODAG will oscillate
                between <xref target="Greedy"></xref>-2 and <xref
                target="Greedy"></xref>-3 until the nodes count to infinity
                and restart the cycle again.</t>

                <t>This cycle can be averted through mechanisms in RPL: <list>
                    <t>Nodes (B) and (C) stay at a Rank sufficient to attach
                    to their most preferred parent (A) and don't go for any
                    deeper (worse) alternate parents (Nodes are not
                    greedy).</t>

                    <t>Nodes (B) and (C) do not process DIO messages from
                    nodes deeper than themselves (because such nodes are
                    possibly in their own sub-DODAGs).</t>
                  </list></t>
              </list>These mechanisms are further described in <xref
            target="DAGDiscoveryRulesMove"></xref>.</t>
          </section>
        </section>

        <section title="DODAG Loops">
          <t>A DODAG loop may occur when a node detaches from the DODAG and
          reattaches to a device in its prior sub-DODAG. In particular, this may happen 
          when DIO messages are missed. Strict use of the DODAGVersionNumber can eliminate this type of loop, but this type of
          loop may possibly be encountered when using some local repair
          mechanisms.</t>

          <t>For example, consider the local repair mechanism that allows a
          node to detach from the DODAG, advertise a Rank of INFINITE_RANK (in
          order to poison its routes / inform its sub-DODAG), and then 
          reattach to the DODAG. In some of these cases, the node may 
          reattach 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 data-path
          validation mechanisms would eventually detect and trigger correction
          of the loop).</t>
        </section>

        <section title="DAO Loops">
          <t>A DAO loop may occur when the parent has a route installed upon
          receiving and processing a DAO message from a child, but the child
          has subsequently cleaned up the related DAO state. This loop happens
          when a No-Path (a DAO message that invalidates a previously
          announced prefix, see <xref target="DAOOptions" />) 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 <xref
          target="DAOInconsistencyDetection"></xref>.)</t>
        </section>
      </section>
    </section>

    <section title="Traffic Flows Supported by RPL">
      <t>RPL supports three basic traffic flows: multipoint-to-point (MP2P),
      point-to-multipoint (P2MP), and point-to-point (P2P).</t>

      <section title="Multipoint-to-Point Traffic">
        <t>Multipoint-to-point (MP2P) is a dominant traffic flow in many LLN
        applications (<xref target="RFC5867"></xref>, <xref
        target="RFC5826"></xref>, <xref target="RFC5673"></xref>, and <xref
        target="RFC5548"></xref>). The destinations of MP2P flows are
        designated nodes that have some application significance, such as
        providing connectivity to the larger Internet or core private IP
        network. RPL supports MP2P traffic by allowing MP2P destinations to be
        reached via DODAG roots.</t>
      </section>

      <section title="Point-to-Multipoint Traffic">
        <t>Point-to-multipoint (P2MP) is a traffic pattern required by several
        LLN applications (<xref target="RFC5867"></xref>, <xref
        target="RFC5826"></xref>, <xref target="RFC5673"></xref>, and <xref
        target="RFC5548"></xref>). RPL supports P2MP traffic by using a
        destination advertisement mechanism that provisions Down routes toward
        destinations (prefixes, addresses, or multicast groups), and away from
        roots. Destination advertisements can update routing tables as the
        underlying DODAG topology changes.</t>
      </section>

      <section title="Point-to-Point Traffic">
        <t>RPL DODAGs provide a basic structure for point-to-point (P2P)
        traffic. For a RPL network to support P2P traffic, a root must be able
        to route packets to a destination. Nodes within the network may also
        have routing tables to destinations. A packet flows towards a root
        until it reaches an ancestor that has a known route to the
        destination. As pointed out later in this document, in the most
        constrained case (when nodes cannot store routes), that common
        ancestor may be the DODAG root. In other cases, it may be a node closer
        to both the source and destination.</t>

        <t>RPL also supports the case where a P2P destination is a 'one-hop'
        neighbor.</t>

        <t>RPL neither specifies nor precludes additional mechanisms for
        computing and installing potentially more optimal routes to support
        arbitrary P2P traffic.</t>
      </section>
    </section>

    <section anchor="RPLInstance" title="RPL Instance">
      <t>Within a given LLN, there may be multiple, logically independent RPL
      Instances. A RPL node may belong to multiple RPL Instances, and it may act
      as a router in some and as a leaf in others. This document describes how
      a single instance behaves.</t>

      <t>There are two types of RPL Instances: Local and Global. RPL divides
      the RPLInstanceID space between Global and Local instances to allow for
      both coordinated and unilateral allocation of RPLInstanceIDs. Global RPL
      Instances are coordinated, have one or more DODAGs, and are typically
      long-lived. Local RPL Instances are always a single DODAG whose singular
      root owns the corresponding DODAGID and allocates the local
      RPLInstanceID in a unilateral manner. Local RPL Instances can be used,
      for example, for constructing DODAGs in support of a future on-demand
      routing solution. The mode of operation of Local RPL Instances is out of
      scope for this specification and may be described in other companion
      specifications.</t>

      <t>The definition and provisioning of RPL Instances are out of scope for
      this specification. Guidelines may be application and implementation
      specific, and they 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.</t>

      <t>Control and data packets within RPL network are tagged to
      unambiguously identify of which RPL Instance they are a part.</t>

      <t>Every RPL control message has a RPLInstanceID field. Some RPL control
      messages, when referring to a local RPLInstanceID as defined below, may
      also include a DODAGID.</t>

      <t>Data packets that flow within the RPL network expose the
      RPLInstanceID as part of the RPL Packet Information that RPL requires,
      as further described in <xref target="loopdetect"></xref>. 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.</t>

      <section anchor="RPLinstanceID" title="RPL Instance ID">
        <t>A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms
        for allocating and provisioning global RPLInstanceID are out of scope
        for this 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.</t>

        <t>A global RPLInstanceID is encoded in a RPLInstanceID field as
        follows: <figure anchor="GRIDFormat"
            title="RPLInstanceID Field Format for Global Instances">
            <artwork><![CDATA[          
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |0|     ID      |  Global RPLInstanceID in 0..127
    +-+-+-+-+-+-+-+-+          

]]></artwork>
          </figure></t>

        <t>A local RPLInstanceID is autoconfigured by the node that owns the
        DODAGID and it MUST be unique for that DODAGID. The DODAGID used to
        configure the local RPLInstanceID MUST be a reachable IPv6 address of
        the node, and it MUST be used as an endpoint of all communications within
        that Local instance.</t>

        <t>A local RPLInstanceID is encoded in a RPLInstanceID field as
        follows: <figure anchor="LRIDFormat"
            title="RPLInstanceID Field Format for Local Instances">
            <artwork><![CDATA[                   
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |1|D|   ID      |  Local RPLInstanceID in 0..63
    +-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>The 'D' flag in a local RPLInstanceID is always set to 0 in RPL
        control messages. It is used in data packets to indicate whether the
        DODAGID is the source or the destination of the packet. If the 'D' flag
        is set to 1, then the destination address of the IPv6 packet MUST be
        the DODAGID. If the 'D' flag is cleared, then the source address of the
        IPv6 packet MUST be the DODAGID.</t>

        <t>For example, consider a Node A that is the DODAG root of a Local
        RPL Instance, and has allocated a local RPLInstanceID. By definition,
        all traffic traversing that Local RPL Instance will either originate
        or terminate at Node A.&nbsp; In this case, the DODAGID will be the reachable
        IPv6 address of Node A.&nbsp; All traffic will contain the address of
        Node A, and thus the DODAGID, in either the source or destination address.
        Thus, the local RPLInstanceID may indicate that the DODAGID is
        equivalent to either the source address or the destination address by
        setting the 'D' flag appropriately.</t>
      </section>
    </section>

    <section anchor="RPLControlMessage" title="ICMPv6 RPL Control Message">
      <t>This document defines the RPL control message, a new ICMPv6 <xref
      target="RFC4443"></xref> message. A RPL control message is identified by
      a code and composed of a base that depends on the code (and a series of
      options).</t>

      <t>Most RPL control messages 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
      value of ff02::1a.</t>

      <t>In accordance with <xref target="RFC4443"></xref>, the RPL Control
      Message consists of an ICMPv6 header followed by a message body. The
      message body is comprised of a message base and possibly a number of
      options as illustrated in <xref target="RPLCtrlICMPFormat"></xref>.</t>

      <t><figure anchor="RPLCtrlICMPFormat" title="RPL Control Message">
          <artwork><![CDATA[
     0                   1                   2                   3   
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                             Base                              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                           Option(s)                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure></t>

      <t>The RPL control message is an ICMPv6 information message with a
      Type of 155.</t>

      <t>The Code field identifies the type of RPL control message. This
      document defines codes for the following RPL control message types (see <xref
      target="RPLCtrlCodeReg"></xref>)):</t>

      <t><list style="symbols">
          <t>0x00: DODAG Information Solicitation (<xref
          target="DAGInformationSolicitation"></xref>)</t>

          <t>0x01: DODAG Information Object (<xref
          target="DAGInformationObject"></xref>)</t>

          <t>0x02: Destination Advertisement Object (<xref
          target="DestinationAdvertisementObject"></xref>)</t>

          <t>0x03: Destination Advertisement Object Acknowledgment (<xref
          target="DestinationAdvertisementObjectAck"></xref>)</t>

          <t>0x80: Secure DODAG Information Solicitation (<xref
          target="SecureDAGInformationSolicitation"></xref>)</t>

          <t>0x81: Secure DODAG Information Object (<xref
          target="SecureDAGInformationObject"></xref>)</t>

          <t>0x82: Secure Destination Advertisement Object (<xref
          target="SecureDestinationAdvertisementObject"></xref>)</t>

          <t>0x83: Secure Destination Advertisement Object Acknowledgment
          (<xref target="SecureDestinationAdvertisementObjectAck"></xref>)</t>

          <t>0x8A: Consistency Check (<xref
          target="ConsistencyCheck"></xref>)</t>
        </list></t>

      <t>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.</t>

      <t>The checksum is computed as specified in <xref
      target="RFC4443"></xref>. 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.</t>

      <t>The high order bit (0x80) of the code denotes whether the RPL message
      has security enabled. Secure RPL messages have a format to support
      confidentiality and integrity, illustrated in <xref
      target="RPLSecureCtrlICMPFormat"></xref>.</t>

      <t><figure anchor="RPLSecureCtrlICMPFormat"
          title="Secure RPL Control Message">
          <artwork><![CDATA[
     0                   1                   2                   3   
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                           Security                            .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                             Base                              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                           Option(s)                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure></t>

      <t>The remainder of this section describes the currently defined RPL
      control message Base formats followed by the currently defined RPL
      Control Message options.</t>

      <section anchor="RPLSecurityFields" title="RPL Security Fields">
        <t>Each RPL message has a secure variant. The secure variants provide
        integrity and replay protection as well as optional confidentiality
        and delay protection. Because security covers the base message as well
        as options, in secured messages the security information lies between
        the checksum and base, as shown in <xref
        target="RPLSecureCtrlICMPFormat"></xref>.</t>

        <t>The level of security and the algorithms in use are indicated in
        the protocol messages as described below:</t>

        <t><figure anchor="RPLSecuritySection" title="Security Section">
            <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|  Reserved   |   Algorithm   |KIM|Resvd| LVL |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Counter                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                        Key Identifier                         .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
]]></artwork>
          </figure></t>

        <t>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 Sections <xref
        target="Security" format="counter"></xref> and <xref
        target="SecurityMechanisms" format="counter"></xref>.</t>

        <t><list hangIndent="23" style="hanging">
            <t hangText="Counter is Time (T):">If the counter's Time flag is
            set, then the Counter field is a timestamp. If the flag is cleared,
            then the counter is an incrementing counter. <xref
            target="SecurityCounter"></xref> describes the details of the 'T'
            flag and Counter field.</t>

            <t hangText="Reserved:">7-bit unused field. The field MUST be
            initialized to zero by the sender and MUST be ignored by the
            receiver.</t>

            <t hangText="Security Algorithm (Algorithm):">The Security
            Algorithm field specifies the encryption, MAC, and signature
            scheme the network uses. Supported values of this field are as
            follows:<figure anchor="SecurityEncoding"
                title="Security Algorithm (Algorithm) Encoding">
                <artwork><![CDATA[
      +-----------+-------------------+------------------------+
      | Algorithm |  Encryption/MAC   |        Signature       |
      +-----------+-------------------+------------------------+
      |     0     | CCM with AES-128  |      RSA with SHA-256  |
      |   1-255   |    Unassigned     |        Unassigned      |
      +-----------+-------------------+------------------------+
]]></artwork>
              </figure></t></list>

<t><xref target="CryptoMode"></xref> describes the
            algorithms in greater detail.</t>
        <t><list hangIndent="6" style="hanging">
            <t hangText="Key Identifier Mode (KIM):">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:</t></list></t>
            <figure anchor="KIMEncoding"
                title="Key Identifier Mode (KIM) Encoding">
                <artwork><![CDATA[
       +------+-----+-----------------------------+------------+
       | Mode | KIM |           Meaning           |    Key     |
       |      |     |                             | Identifier |
       |      |     |                             |   Length   |
       |      |     |                             |  (octets)  |
       +------+-----+-----------------------------+------------+
       |  0   | 00  | Group key used.             |     1      |
       |      |     | Key determined by Key Index |            |
       |      |     | field.                      |            |
       |      |     |                             |            |
       |      |     | Key Source is not present.  |            |
       |      |     | Key Index is present.       |            |
       +------+-----+-----------------------------+------------+
       |  1   | 01  | Per-pair key used.          |     0      |
       |      |     | Key determined by source    |            |
       |      |     | and destination of packet.  |            |
       |      |     |                             |            |
       |      |     | Key Source is not present.  |            |
       |      |     | Key Index is not present.   |            |
       +------+-----+-----------------------------+------------+
       |  2   | 10  | Group key used.             |     9      |
       |      |     | Key determined by Key Index |            |
       |      |     | and Key Source Identifier.  |            |
       |      |     |                             |            |
       |      |     | Key Source is present.      |            |
       |      |     | Key Index is present.       |            |
       +------+-----+-----------------------------+------------+
       |  3   | 11  | Node's signature key used.  |    0/9     |
       |      |     | If packet is encrypted,     |
       |      |     | it uses a group key, Key    |            |
       |      |     | Index and Key Source        |            |
       |      |     | specify key.                |            |
       |      |     |                             |            |
       |      |     | Key Source may be present.  |            |
       |      |     | Key Index may be present.   |            |
       +------+-----+-----------------------------+------------+
]]></artwork>
              </figure> 
<t>In Mode 3 (KIM=11), the presence or absence of the Key
            Source and Key Identifier depends on the Security Level (LVL)
            described below. If the Security Level indicates there is
            encryption, then the fields are present; if it indicates there is
            no encryption, then the fields are not present.</t>
        <t><list hangIndent="6" style="hanging">
            <t hangText="Resvd:">3-bit unused field. The field MUST be
            initialized to zero by the sender and MUST be ignored by the
            receiver.</t>

            <t hangText="Security Level (LVL):">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:</t> </list></t><figure
                anchor="LVLEncoding" title="Security Level (LVL) Encoding">
                <artwork><![CDATA[
                   +---------------------------+
                   |         KIM=0,1,2         |
           +-------+--------------------+------+
           |  LVL  |     Attributes     | MAC  |
           |       |                    | Len  |
           +-------+--------------------+------+
           |   0   |       MAC-32       |  4   |
           |   1   |     ENC-MAC-32     |  4   |
           |   2   |       MAC-64       |  8   |
           |   3   |     ENC-MAC-64     |  8   |
           |  4-7  |     Unassigned     | N/A  |
           +-------+--------------------+------+

                         +---------------------+    
                         |        KIM=3        |    
                 +-------+---------------+-----+    
                 |  LVL  |  Attributes   | Sig |    
                 |       |               | Len |    
                 +-------+---------------+-----+    
                 |   0   |   Sign-3072   | 384 |
                 |   1   | ENC-Sign-3072 | 384 |
                 |   2   |   Sign-2048   | 256 |
                 |   3   | ENC-Sign-2048 | 256 |
                 |  4-7  |  Unassigned   | N/A |    
                 +-------+---------------+-----+

]]></artwork>
              </figure>
<t>The MAC attribute indicates that the message has a
            MAC of the specified length. The ENC
            attribute indicates that the message is encrypted. The Sign
            attribute indicates that the message has a signature of the
            specified length.</t>

        <t><list hangIndent="12" style="hanging">
            <t hangText="Flags:">8-bit unused field reserved for flags. The
            field MUST be initialized to zero by the sender and MUST be
            ignored by the receiver.</t>

            <t hangText="Counter:">The Counter field indicates the
            non-repeating 4-octet value used to construct the cryptographic
            mechanism that implements packet protection and allows for the
            provision of semantic security. See <xref
            target="SecurityNonce"></xref>.</t>

            <t hangText="Key Identifier:">The Key Identifier field indicates
            which key was used to protect the packet. This field provides
            various levels of granularity of packet protection, including
            peer-to-peer keys, group keys, and signature keys. This field is
            represented as indicated by the Key Identifier Mode field and is
            formatted as follows:</t> </list> </t><figure anchor="KeyIdentifier"
                title="Key Identifier">
                <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                          Key Source                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                           Key Index                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
]]></artwork>
              </figure> 
<t><list hangIndent="12" style="hanging">
                <t hangText="Key Source:">The Key Source field, when present,
                indicates the logical identifier of the originator of a group
                key. When present, this field is 8 bytes in length.</t>

                <t hangText="Key Index:">The Key Index field, when present,
                allows unique identification of different keys with the same
                originator. It is the responsibility of each key originator to
                make sure that actively used keys that it issues have distinct
                key indices and that all key indices have a value unequal to
                0x00. Value 0x00 is reserved for a preinstalled, shared key.
                When present this field is 1 byte in length.</t>
              </list></t></t>
          

        <t>Unassigned bits of the Security section are reserved. They MUST be
        set to zero on transmission and MUST be ignored on reception.</t>
      </section>

      <section anchor="DAGInformationSolicitation"
               title="DODAG Information Solicitation (DIS)">
        <t>The DODAG Information Solicitation (DIS) message may be used to
        solicit a DODAG Information Object from a RPL node. Its use is
        analogous to that of a Router Solicitation as specified in IPv6
        Neighbor Discovery; a node may use DIS to probe its neighborhood for
        nearby DODAGs. <xref target="DIOTransmission"></xref> describes how
        nodes respond to a DIS.</t>

        <section title="Format of the DIS Base Object">
          <t><figure anchor="DISBase" title="The DIS Base Object">
              <artwork><![CDATA[
     0                   1                   2                    
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3              
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |   Reserved    |   Option(s)... 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             
]]></artwork>
            </figure></t>

          <t><list hangIndent="12" style="hanging">
              <t hangText="Flags:">8-bit unused field reserved for flags. The
              field MUST be initialized to zero by the sender and MUST be
              ignored by the receiver.</t>

              <t hangText="Reserved:">8-bit unused field. The field MUST be
              initialized to zero by the sender and MUST be ignored by the
              receiver.</t>
            </list></t>

          <t>Unassigned bits of the DIS Base are reserved. They MUST be set to
          zero on transmission and MUST be ignored on reception.</t>
        </section>

        <section anchor="SecureDAGInformationSolicitation" title="Secure DIS">
          <t>A Secure DIS message follows the format in <xref
          target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
          the DIS message shown in <xref target="DISBase"></xref>.</t>
        </section>

        <section title="DIS Options">
          <t>The DIS message MAY carry valid options.</t>

          <t>This specification allows for the DIS message to carry the
          following options: <?rfc subcompact="yes"?><list>
              <t>0x00 Pad1</t>

              <t>0x01 PadN</t>

              <t>0x07 Solicited Information</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section anchor="DAGInformationObject"
               title="DODAG Information Object (DIO)">
        <t>The DODAG Information Object carries information that allows a node
        to discover a RPL Instance, learn its configuration parameters, select
        a DODAG parent set, and maintain the DODAG.</t>

        <section title="Format of the DIO Base Object">
          <t><figure anchor="DIObase" title="The DIO Base Object">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RPLInstanceID |Version Number |             Rank              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |G|0| MOP | Prf |     DTSN      |     Flags     |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            DODAGID                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Option(s)...
    +-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t><list hangIndent="18" style="hanging">
              <t hangText="Grounded (G):">The Grounded 'G' flag indicates
              whether the DODAG advertised can satisfy the application-defined
              goal. If the flag is set, the DODAG is grounded. If the flag is
              cleared, the DODAG is floating.</t>

              <t hangText="Mode of Operation (MOP):">The Mode of Operation
              (MOP) field identifies the mode of operation of the RPL Instance
              as administratively provisioned at and distributed by the DODAG
              root. All nodes who join the DODAG must be able to honor the MOP
              in order to fully participate as a router, or else they must
              only join as a leaf. MOP is encoded as in the figure
              below:<figure anchor="MOPEncoding"
                  title="Mode of Operation (MOP) Encoding">
                  <artwork><![CDATA[
                                                                     
            +-----+-----------------------------------------------------+
            | MOP | Description                                         |
            +-----+-----------------------------------------------------+
            |  0  | No Downward routes maintained by RPL                |
            |  1  | Non-Storing Mode of Operation                       |
            |  2  | Storing Mode of Operation with no multicast support |
            |  3  | Storing Mode of Operation with multicast support    | 
            |     |                                                     |
            |     | All other values are unassigned                     |
            +-----+-----------------------------------------------------+
]]></artwork>

                  <postamble>A value of 0 indicates that destination
                  advertisement messages are disabled and the DODAG maintains
                  only Upward routes.</postamble>
                </figure></t>

              <t hangText="DODAGPreference (Prf):">A 3-bit unsigned integer
              that defines how preferable the root of this DODAG is compared
              to other DODAG roots within the instance. DAGPreference ranges
              from 0x00 (least preferred) to 0x07 (most preferred). The
              default is 0 (least preferred). <xref
              target="DAGDiscovery"></xref> describes how DAGPreference
              affects DIO processing.</t>

              <t hangText="Version Number:">8-bit unsigned integer set by the
              DODAG root to the DODAGVersionNumber. <xref
              target="DAGDiscovery"></xref> describes the rules for DODAGVersionNumbers and how they affect DIO processing.</t>

              <t hangText="Rank:">16-bit unsigned integer indicating the DODAG
              Rank of the node sending the DIO message. <xref
              target="DAGDiscovery"></xref> describes how Rank is set and how
              it affects DIO processing.</t>

              <t hangText="RPLInstanceID:">8-bit field set by the DODAG root
              that indicates of which RPL Instance the DODAG is a part.</t>

              <t
              hangText="Destination Advertisement Trigger Sequence Number (DTSN):">8-bit
              unsigned integer set by the node issuing the DIO message. The
              Destination Advertisement Trigger Sequence Number (DTSN) flag is
              used as part of the procedure to maintain Downward routes. The
              details of this process are described in <xref
              target="DownwardRoutes"></xref>.</t>

              <t hangText="Flags:">8-bit unused field reserved for flags. The
              field MUST be initialized to zero by the sender and MUST be
              ignored by the receiver.</t>

              <t hangText="Reserved:">8-bit unused field. The field MUST be
              initialized to zero by the sender and MUST be ignored by the
              receiver.</t>

              <t hangText="DODAGID:">128-bit IPv6 address set by a DODAG root
              that uniquely identifies a DODAG. The DODAGID MUST be a
              routable IPv6 address belonging to the DODAG root.</t>
            </list></t>

          <t>Unassigned bits of the DIO Base are reserved. They MUST be set to
          zero on transmission and MUST be ignored on reception.</t>
        </section>

        <section anchor="SecureDAGInformationObject" title="Secure DIO">
          <t>A Secure DIO message follows the format in <xref
          target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
          the DIO message shown in <xref target="DIObase"></xref>.</t>
        </section>

        <section title="DIO Options">
          <t>The DIO message MAY carry valid options.</t>

          <t>This specification allows for the DIO message to carry the
          following options: <?rfc subcompact="yes"?><list>
              <t>0x00 Pad1</t>

              <t>0x01 PadN</t>

              <t>0x02 DAG Metric Container</t>

              <t>0x03 Routing Information</t>

              <t>0x04 DODAG Configuration</t>

              <t>0x08 Prefix Information</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section anchor="DestinationAdvertisementObject"
               title="Destination Advertisement Object (DAO)">
        <t>The Destination Advertisement Object (DAO) is used to propagate
        destination information Upward along the DODAG. In Storing mode, the
        DAO message is unicast by the child to the selected parent(s). In
        Non-Storing mode, the DAO message is unicast to the DODAG root. The DAO
        message may optionally, upon explicit request or error, be
        acknowledged by its destination with a Destination Advertisement
        Acknowledgement (DAO-ACK) message back to the sender of the DAO.</t>

        <section title="Format of the DAO Base Object">
          <t><figure anchor="DAObject" title="The DAO Base Object">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RPLInstanceID |K|D|   Flags   |   Reserved    | DAOSequence   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            DODAGID*                           +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Option(s)...
    +-+-+-+-+-+-+-+-+
]]></artwork>

              <postamble>The '*' denotes that the DODAGID is not always
              present, as described below.</postamble>
            </figure></t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="RPLInstanceID:">8-bit field indicating the topology
              instance associated with the DODAG, as learned from the DIO.</t>

              <t hangText="K:">The 'K' flag indicates that the recipient is
              expected to send a DAO-ACK back. (See <xref
              target="DAOBaseRules"></xref>.)</t>

              <t hangText="D:">The 'D' flag indicates that the DODAGID field
              is present. This flag MUST be set when a local RPLInstanceID is
              used.</t>

              <t hangText="Flags:">The 6 bits remaining unused in the Flags
              field are reserved for flags. The field MUST be initialized to
              zero by the sender and MUST be ignored by the receiver.</t>

              <t hangText="Reserved:">8-bit unused field. The field MUST be
              initialized to zero by the sender and MUST be ignored by the
              receiver.</t>

              <t hangText="DAOSequence:">Incremented at each unique DAO
              message from a node and echoed in the DAO-ACK message.</t>

              <t hangText="DODAGID (optional):">128-bit unsigned integer set
              by a DODAG root that uniquely identifies a DODAG. This field is
              only present when the 'D' flag is set. This field is typically
              only present when a local RPLInstanceID is in use, in order to
              identify the DODAGID that is associated with the RPLInstanceID.
              When a global RPLInstanceID is in use, this field need not be
              present.</t>
            </list></t>

          <t>Unassigned bits of the DAO Base are reserved. They MUST be set to
          zero on transmission and MUST be ignored on reception.</t>
        </section>

        <section anchor="SecureDestinationAdvertisementObject"
                 title="Secure DAO">
          <t>A Secure DAO message follows the format in <xref
          target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
          the DAO message shown in <xref target="DAObject"></xref>.</t>
        </section>

        <section anchor="DAOOptions" title="DAO Options">
          <t>The DAO message MAY carry valid options.</t>

          <t>This specification allows for the DAO message to carry the
          following options: <?rfc subcompact="yes"?><list>
              <t>0x00 Pad1</t>

              <t>0x01 PadN</t>

              <t>0x05 RPL Target</t>

              <t>0x06 Transit Information</t>

              <t>0x09 RPL Target Descriptor</t>
            </list><?rfc subcompact="no"?></t>

          <t>A special case of the DAO message, termed a No-Path, is used in
          Storing mode to clear Downward routing state that has been
          provisioned through DAO operation. The No-Path carries a Target
          option and an associated Transit Information option with a lifetime
          of 0x00000000 to indicate a loss of reachability to that Target.</t>

        </section>
      </section>

      <section anchor="DestinationAdvertisementObjectAck"
               title="Destination Advertisement Object Acknowledgement (DAO-ACK)">
        <t>The DAO-ACK message is sent as a unicast packet by a DAO recipient
        (a DAO parent or DODAG root) in response to a unicast DAO message.</t>

        <section title="Format of the DAO-ACK Base Object">
          <t><figure anchor="DAOackbject" title="The DAO ACK Base Object">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RPLInstanceID |D|  Reserved   |  DAOSequence  |    Status     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            DODAGID*                           +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Option(s)...
    +-+-+-+-+-+-+-+-+
]]></artwork>

              <postamble>The '*' denotes that the DODAGID is not always
              present, as described below.</postamble>
            </figure></t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="RPLInstanceID:">8-bit field indicating the topology
              instance associated with the DODAG, as learned from the DIO.</t>

              <t hangText="D:">The 'D' flag indicates that the DODAGID field
              is present. This would typically only be set when a local
              RPLInstanceID is used.</t>

              <t hangText="Reserved:">The 7-bit field, reserved for flags.</t>

              <t hangText="DAOSequence:">Incremented at each DAO message from
              a node, and echoed in the DAO-ACK by the recipient. The
              DAOSequence is used to correlate a DAO message and a DAO ACK
              message and is not to be confused with the Transit Information
              option Path Sequence that is associated to a given Target Down
              the DODAG.</t>

              <t hangText="Status:">Indicates the completion. Status 0 is
              defined as unqualified acceptance in this specification. The
              remaining status values are reserved as rejection codes. No
              rejection status codes are defined in this specification,
              although status codes SHOULD be allocated according to the
              following guidelines in future specifications: <?rfc subcompact="yes"?>
              <list hangIndent="10" style="hanging">
                  <t hangText="      0:">Unqualified acceptance (i.e., the node
                  receiving the DAO-ACK is not rejected).</t>

                  <t hangText="  1-127:">Not an outright rejection; the node
                  sending the DAO-ACK is willing to act as a parent, but the
                  receiving node is suggested to find and use an alternate
                  parent instead.</t>

                  <t hangText="127-255:">Rejection; the node sending the
                  DAO-ACK is unwilling to act as a parent.</t>
                </list><?rfc subcompact="no"?></t>

              <t hangText="DODAGID (optional):">128-bit unsigned integer set
              by a DODAG root that uniquely identifies a DODAG. This field is
              only present when the 'D' flag is set. Typically, this field is 
              only present when a local RPLInstanceID is in use in order to
              identify the DODAGID that is associated with the RPLInstanceID.
              When a global RPLInstanceID is in use, this field need not be
              present.</t>
            </list></t>

          <t>Unassigned bits of the DAO-ACK Base are reserved. They MUST be
          set to zero on transmission and MUST be ignored on reception.</t>
        </section>

        <section anchor="SecureDestinationAdvertisementObjectAck"
                 title="Secure DAO-ACK">
          <t>A Secure DAO-ACK message follows the format in <xref
          target="RPLSecureCtrlICMPFormat"></xref>, where the base format is
          the DAO-ACK message shown in <xref target="DAOackbject"></xref>.</t>
        </section>

        <section anchor="DAOackOptions" title="DAO-ACK Options">
          <t>This specification does not define any options to be carried by
          the DAO-ACK message.</t>
        </section>
      </section>

      <section anchor="ConsistencyCheck" title="Consistency Check (CC)">
        <t>The CC message is used to check secure message counters and issue
        challenge-responses. A CC message MUST be sent as a secured RPL
        message.</t>

        <section title="Format of the CC Base Object">
          <t><figure anchor="CC" title="The CC Base Object">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RPLInstanceID |R|    Flags    |           CC Nonce            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            DODAGID                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Destination Counter                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Option(s)...
    +-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="RPLInstanceID:">8-bit field indicating the topology
              instance associated with the DODAG, as learned from the DIO.</t>

              <t hangText="R:">The 'R' flag indicates whether the CC message
              is a response. A message with the 'R' flag cleared is a request;
              a message with the 'R' flag set is a response.</t>

              <t hangText="Flags:">The 7 bits remaining unused in the Flags
              field are reserved for flags. The field MUST be initialized to
              zero by the sender and MUST be ignored by the receiver.</t>

              <t hangText="CC Nonce:">16-bit unsigned integer set by a CC
              request. The corresponding CC response includes the same CC
              nonce value as the request.</t>

              <t hangText="DODAGID:">128-bit field, contains the identifier of the DODAG
root.</t>

              <t hangText="Destination Counter:">32-bit unsigned integer value
              indicating the sender's estimate of the destination's current
              security counter value. If the sender does not have an estimate,
              it SHOULD set the Destination Counter field to zero.</t>
            </list></t>

          <t>Unassigned bits of the CC Base are reserved. They MUST be set to
          zero on transmission and MUST be ignored on reception.</t>

          <t>The Destination Counter value allows new or recovered nodes to
          resynchronize through CC message exchanges. This is important to
          ensure that a Counter value is not repeated for a given security key
          even in the event of devices recovering from a failure that created
          a loss of Counter state. For example, where a CC request or other
          RPL message is received with an initialized counter within the
          message Security section, the provision of the Incoming Counter
          within the CC response message allows the requesting node to reset
          its Outgoing Counter to a value greater than the last value received
          by the responding node; the Incoming Counter will also be updated
          from the received CC response.</t>
        </section>

        <section title="CC Options">
          <t>This specification allows for the CC message to carry the
          following options: <?rfc subcompact="yes"?><list>
              <t>0x00 Pad1</t>

              <t>0x01 PadN</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section anchor="RPLMsgOptions" title="RPL Control Message Options">
        <section title="RPL Control Message Option Generic Format">
          <t>RPL Control Message options all follow this format: <figure
              anchor="DIOsub" title="RPL Option Generic Format">
              <artwork><![CDATA[
     0                   1                   2      
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
    |  Option Type  | Option Length | Option Data
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
]]></artwork>
            </figure></t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">8-bit identifier of the type of
              option. The Option Type values are assigned by IANA (see <xref
              target="RPLCtrlMsgOptionsReg"></xref>.)</t>

              <t hangText="Option Length:">8-bit unsigned integer,
              representing the length in octets of the option, not including
              the Option Type and Length fields.</t>

              <t hangText="Option Data:">A variable length field that contains
              data specific to the option.</t>
            </list></t>

          <t>When processing a RPL message containing an option for which the
          Option Type value is not recognized by the receiver, the receiver
          MUST silently ignore the unrecognized option and continue to process
          the following option, correctly handling any remaining options in
          the message.</t>

          <t>RPL message options may have alignment requirements. Following
          the convention in IPv6, options with alignment requirements are
          aligned in a packet such that multi-octet values within the Option
          Data field of each option fall on natural boundaries (i.e., fields
          of width n octets are placed at an integer multiple of n octets from
          the start of the header, for n = 1, 2, 4, or 8).</t>
        </section>

        <section title="Pad1">
          <t>The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
          messages, and its format is as follows:</t>

          <t><figure anchor="DIOsubPad1" title="Format of the Pad1 Option">
              <artwork><![CDATA[
     0
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |   Type = 0x00 |
    +-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>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.</t>

          <t>NOTE! The format of the Pad1 option is a special case -- it has
          neither Option Length nor Option Data fields.</t>
        </section>

        <section title="PadN">
          <t>The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
          messages, and its format is as follows:</t>

          <t><figure anchor="DIOsubPadN" title="Format of the Pad N Option">
              <artwork><![CDATA[
     0                   1                   2      
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
    |   Type = 0x01 | Option Length | 0x00 Padding...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
]]></artwork>
            </figure></t>

          <t>The PadN option is used to insert two or more octets of padding
          into the message to enable options alignment. PadN option data MUST
          be ignored by the receiver.</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x01</t>

              <t hangText="Option Length:">For N octets of padding, where 2
              &lt;= N &lt;= 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.</t>

              <t hangText="Option Data:">For N (N &gt; 1) octets of padding,
              the Option Data consists of N-2 zero-valued octets.</t>
            </list></t>
        </section>

        <section title="DAG Metric Container">
          <t>The DAG Metric Container option MAY be present in DIO or DAO
          messages, and its format is as follows:</t>

          <t><figure anchor="DIOsubLLNMetric"
              title="Format of the DAG Metric Container Option">
              <artwork><![CDATA[
     0                   1                   2      
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
    |   Type = 0x02 | Option Length | Metric Data
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
]]></artwork>
            </figure></t>

          <t>The DAG Metric Container is used to report metrics along the DODAG.
          The DAG Metric Container may contain a number of discrete node, link,
          and aggregate path metrics and constraints specified in <xref
          target="RFC6551"></xref> as chosen by the
          implementer.</t>

          <t>The DAG Metric Container MAY appear more than once in the same RPL
          control message, for example, to accommodate a use case where the
          Metric Data is longer than 256 bytes. More information is in <xref
          target="RFC6551"></xref>.</t>

          <t>The processing and propagation of the DAG Metric Container is
          governed by implementation specific policy functions.</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x02</t>

              <t hangText="Option Length:">The Option Length field contains
              the length in octets of the Metric Data.</t>

              <t hangText="Metric Data:">The order, content, and coding of the
              DAG Metric Container data is as specified in <xref
              target="RFC6551"></xref>.</t>
            </list></t>
        </section>

        <section anchor="dejaneiro" title="Route Information">
          <t>The Route Information Option (RIO) MAY be present in DIO messages, and
          it carries the same information as the IPv6 Neighbor Discovery (ND)
          RIO  as defined in <xref
          target="RFC4191"></xref>. 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 an 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 whose 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:</t>

          <t><figure anchor="DIOsubRouteInformation"
              title="Format of the Route Information Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x03 | Option Length | Prefix Length |Resvd|Prf|Resvd|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Route Lifetime                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                   Prefix (Variable Length)                    .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>The RIO is used to indicate that
          connectivity to the specified destination prefix is available from
          the DODAG root.</t>

          <t>In the event that a RPL control message may need to specify
          connectivity to more than one destination, the RIO may be repeated.</t>

          <t><xref target="RFC4191"></xref> should be consulted as the
          authoritative reference with respect to the RIO. The field descriptions are transcribed here for
          convenience:</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x03</t>

              <t hangText="Option Length:">Variable, length of the option in
              octets excluding the Type and Length fields. Note that this
              length is expressed in units of single octets, unlike in IPv6
              ND.</t>

              <t hangText="Prefix Length:">8-bit unsigned integer. The number
              of leading bits in the prefix that are valid. The value ranges
              from 0 to 128. The Prefix field has the number of bytes inferred
              from the Option Length field, that must be at least the Prefix
              Length. Note that in RPL, this means that the Prefix field may
              have lengths other than 0, 8, or 16.</t>

              <t hangText="Prf:">2-bit signed integer. The Route Preference
              indicates whether to prefer the router associated with this
              prefix over others, when multiple identical prefixes (for
              different routers) have been received. If the Reserved (10)
              value is received, the RIO MUST be ignored.
              Per <xref target="RFC4191"></xref>, the Reserved (10) value
              MUST NOT be sent. (<xref target="RFC4191"></xref> restricts the
              Preference to just three values to reinforce that it is not a
              metric.)</t>

              <t hangText="Resvd:">Two 3-bit unused fields. They MUST be
              initialized to zero by the sender and MUST be ignored by the
              receiver.</t>

              <t hangText="Route Lifetime:">32-bit unsigned integer.  The length of time in
         seconds (relative to the time the packet is sent) that the
         prefix is valid for route determination.  A value of all one
         bits (0xFFFFFFFF) represents infinity.</t>

<!-- *AD, please confirm the change from (0xffffffff) to (0xFF).
There are 3 instances in this document:
  A value of all one bits (0xFF) represents infinity.

This change was made per the following reply from Pascal (to a 
question we sent earlier in the process):

[Pascal]  The field is in octet long so 0xFF is correct. I think we
should uppercase all the Oxff... to 0xFF...
-->

              <t hangText="Prefix:">Variable-length field containing an IP
              address or a prefix of an IPv6 address. The Prefix Length field
              contains the number of valid leading bits in the prefix. The
              bits in the prefix after the prefix length (if any) are reserved
              and MUST be initialized to zero by the sender and ignored by the
              receiver. Note that in RPL, this field may have lengths other
              than 0, 8, or 16.</t>
            </list></t>

          <t>Unassigned bits of the RIO are reserved.
          They MUST be set to zero on transmission and MUST be ignored on
          reception.</t>
        </section>

        <section title="DODAG Configuration">
          <t>The DODAG Configuration option MAY be present in DIO messages,
          and its format is as follows:</t>

          <t><figure anchor="DIOsubDAGConfig"
              title="Format of the DODAG Configuration Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x04 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl.  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  DIOIntMin.   |   DIORedun.   |        MaxRankIncrease        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      MinHopRankIncrease       |              OCP              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    | Def. Lifetime |      Lifetime Unit            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>The DODAG Configuration option is used to distribute
          configuration information for DODAG Operation through the DODAG.</t>

          <t>The information communicated in this option is generally static
          and unchanging within the DODAG, therefore it is not necessary to
          include in every DIO. This information is configured at the DODAG
          root and distributed throughout the DODAG with the DODAG
          Configuration option. Nodes other than the DODAG root MUST NOT
          modify this information when propagating the DODAG Configuration
          option. This option MAY be included occasionally by the DODAG root
          (as determined by the DODAG root), and MUST be included in response
          to a unicast request, e.g. a unicast DODAG Information Solicitation
          (DIS) message.</t>

          <t><list hangIndent="30" style="hanging">
              <t hangText="Option Type:">0x04</t>

              <t hangText="Option Length:">14</t>

              <t hangText="Flags:">The 4-bits remaining unused in the Flags
              field are reserved for flags. The field MUST be initialized to
              zero by the sender and MUST be ignored by the receiver.</t>

              <t hangText="Authentication Enabled (A):">1-bit flag
              describing the security mode of the network. The bit describes
              whether a node must authenticate with a key authority before
              joining the network as a router. If the DIO is not a secure DIO,
              the 'A' bit MUST be zero.</t>

              <t hangText="Path Control Size (PCS):">3-bit unsigned integer
              used to configure the number of bits that may be allocated to
              the Path Control field (see <xref target="PathControl"></xref>).
              Note that when PCS is consulted to determine the width of the
              Path Control field, a value of 1 is added, i.e., a PCS value of 0
              results in 1 active bit in the Path Control field. The default
              value of PCS is DEFAULT_PATH_CONTROL_SIZE.</t>

              <t hangText="DIOIntervalDoublings:">8-bit unsigned integer used
              to configure Imax of the DIO Trickle timer (see <xref
              target="TrickleParameters"></xref>). The default value of
              DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.</t>

              <t hangText="DIOIntervalMin:">8-bit unsigned integer used to
              configure Imin of the DIO Trickle timer (see <xref
              target="TrickleParameters"></xref>). The default value of
              DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.</t>

              <t hangText="DIORedundancyConstant:">8-bit unsigned integer used
              to configure k of the DIO Trickle timer (see <xref
              target="TrickleParameters"></xref>). The default value of
              DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT.</t>

              <t hangText="MaxRankIncrease:">16-bit unsigned integer used to
              configure DAGMaxRankIncrease, the allowable increase in Rank in
              support of local repair. If DAGMaxRankIncrease is 0, then this
              mechanism is disabled.</t>

              <t hangText="MinHopRankIncrease:">16-bit unsigned integer used to
              configure MinHopRankIncrease as described in <xref
              target="RankComparison"></xref>. The default value of
              MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE.</t>

<t hangText="Objective Code Point (OCP):">16-bit unsigned
              integer. The OCP field identifies the OF and is managed by the
              IANA.</t>
            <t hangText="Reserved:">7-bit unused field. The field MUST be
            initialized to zero by the sender and MUST be ignored by the
            receiver.</t>

              <t hangText="Default Lifetime:">8-bit unsigned integer. This is
              the lifetime that is used as default for all RPL routes. It is
              expressed in units of Lifetime Units, e.g., the default lifetime
              in seconds is (Default Lifetime) * (Lifetime Unit).</t>

              <t hangText="Lifetime Unit:">16-bit unsigned integer. Provides
              the unit in seconds that is used to express route lifetimes in
              RPL. For very stable networks, it can be hours to days.</t>
            </list></t>
        </section>

        <section title="RPL Target">
          <t>The RPL Target option MAY be present in DAO messages, and its
          format is as follows:</t>

          <t><figure anchor="RPLtargetopt"
              title="Format of the RPL Target Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x05 | Option Length |     Flags     | Prefix Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                Target Prefix (Variable Length)                |
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>The RPL Target option is used to indicate a Target IPv6 address,
          prefix, or multicast group that is reachable or queried along the
          DODAG. In a DAO, the RPL Target option indicates reachability.</t>

          <t>A RPL Target option MAY optionally be paired with a RPL Target
          Descriptor option (<xref target="RPLtargetdescopt"></xref>) that
          qualifies the target.</t>

          <t>A set of one or more Transit Information options (<xref
          target="TransitInformation"></xref>) MAY directly follow a set of
          one or more Target options in a DAO message (where each Target option
          MAY be paired with a RPL Target Descriptor option as above). The
          structure of the DAO message, detailing how Target options are used
          in conjunction with Transit Information options is further
          described in <xref target="DAOStructure"></xref>.</t>

          <t>The RPL Target option may be repeated as necessary to indicate
          multiple targets.</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x05</t>

              <t hangText="Option Length:">Variable, length of the option in
              octets excluding the Type and Length fields.</t>

              <t hangText="Flags:">8-bit unused field reserved for flags. The
              field MUST be initialized to zero by the sender and MUST be
              ignored by the receiver.</t>

              <t hangText="Prefix Length:">8-bit unsigned integer. Number of
              valid leading bits in the IPv6 Prefix.</t>

              <t hangText="Target Prefix:">Variable-length field identifying
              an IPv6 destination address, prefix, or multicast group. The
              Prefix Length field contains the number of valid leading bits in
              the prefix. The bits in the prefix after the prefix length (if
              any) are reserved and MUST be set to zero on transmission and
              MUST be ignored on receipt.</t>
            </list></t>
        </section>

        <section anchor="TransitInformation" title="Transit Information">
          <t>The Transit Information option MAY be present in DAO messages,
          and its format is as follows:</t>

          <t><figure anchor="TransitInformationOption"
              title="Format of the Transit Information Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x06 | Option Length |E|    Flags    | Path Control  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Path Sequence | Path Lifetime |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    +                                                               +
    |                                                               |
    +                        Parent Address*                        +
    |                                                               |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
]]></artwork>

              <postamble>The '*' denotes that the DODAG Parent Address subfield is not always
              present, as described below.</postamble>
            </figure></t>

          <t>The Transit Information option is used for a node to indicate
          attributes for a path to one or more destinations. The destinations
          are indicated by one or more Target options that immediately precede
          the Transit Information option(s).</t>

          <t>The Transit Information option can be used for a node to indicate
          its DODAG parents to an ancestor that is collecting DODAG routing
          information, typically, for the purpose of constructing source
          routes. In the Non-Storing mode of operation, this ancestor will be
          the DODAG root, and this option is carried by the DAO message. In
          the Storing mode of operation, the DODAG Parent Address subfield is not needed,
          since the DAO message is sent directly to the parent. The option
          length is used to determine whether or not the DODAG Parent Address subfield is present.</t>

          <t>A non-storing node that has more than one DAO parent MAY include
          a Transit Information option for each DAO parent as part of the
          non-storing destination advertisement operation. The node may
          distribute the bits in the Path Control field among different groups
          of DAO parents in order to signal a preference among parents. That
          preference may influence the decision of the DODAG root when
          selecting among the alternate parents/paths for constructing
          Downward routes.</t>

          <t>One or more Transit Information options MUST be preceded by one
          or more RPL Target options. In this manner, the RPL Target option
          indicates the child node, and the Transit Information option(s)
          enumerates the DODAG parents. The structure of the DAO message,
          further detailing how Target options are used in conjunction with
          Transit Information options, is further described in <xref
          target="DAOStructure"></xref>.</t>

          <t>A typical non-storing node will use multiple Transit Information
          options, and it will send the DAO message thus formed directly to
          the root. A typical storing node will use one Transit Information
          option with no parent field and will send the DAO message thus
          formed, with additional adjustments, to Path Control as detailed
          later, to one or multiple parents.</t>

          <t>For example, in a Non-Storing mode of operation let Tgt(T) denote
          a Target option for a Target T.&nbsp; Let Trnst(P) denote a Transit
          Information option that contains a parent address P.&nbsp; 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} is described by the Transit Information
          options as having the parents {P1, P2, P3}. The non-storing node
          would then address that DAO message directly to the DODAG root and
          forward that DAO message through one of the DODAG parents: P1, P2, or
          P3.</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x06</t>

              <t hangText="Option Length:">Variable, depending on whether or
              not the DODAG Parent Address subfield is present.</t>

              <t hangText="External (E):">1-bit flag. The 'E' flag is set to
              indicate that the parent router redistributes external targets
              into the RPL network. An external Target is a Target that has
              been learned through an alternate protocol. The external targets
              are listed in the Target options that immediately precede the
              Transit Information option. An external Target is not expected
              to support RPL messages and options.</t>

              <t hangText="Flags:">The 7 bits remaining unused in the Flags
              field are reserved for flags. The field MUST be initialized to
              zero by the sender and MUST be ignored by the receiver.</t>

              <t hangText="Path Control:">8-bit bit field. 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 that
              contain two bits each: PC1, PC2, PC3, and PC4, as illustrated in
              <xref target="PathControlEncoding"></xref>. The subfields are
              ordered by preference, with PC1 being the most preferred and PC4
              being the least preferred. Within a subfield, there is no order
              of preference. By grouping the parents (as in ECMP) and ordering
              them, the parents may be associated with specific bits in the
              Path Control field in a way that communicates preference.
              <figure anchor="PathControlEncoding"
                  title="Path Control Preference Subfield Encoding">
                  <artwork><![CDATA[
                                                                     
                                 0 1 2 3 4 5 6 7                     
                                +-+-+-+-+-+-+-+-+                    
                                |PC1|PC2|PC3|PC4|                    
                                +-+-+-+-+-+-+-+-+                    
]]></artwork>
                </figure></t>

              <t hangText="Path Sequence:">8-bit unsigned integer. When a RPL
              Target option is issued by the node that owns the Target prefix
              (i.e., in a DAO message), that node sets the Path Sequence and
              increments the Path Sequence each time it issues a RPL Target
              option with updated information.</t>

              <t hangText="Path Lifetime:">8-bit unsigned integer. The length
              of time in Lifetime Units (obtained from the Configuration
              option) that the prefix is valid for route determination. The
              period starts when a new Path Sequence is seen. A value of all
              one bits (0xFF) represents infinity. A value of all zero bits
              (0x00) indicates a loss of reachability. A DAO message that
              contains a Transit Information option with a Path Lifetime of
              0x00 for a Target is referred as a No-Path (for that Target) in
              this document.</t>

              <t hangText="Parent Address (optional):">IPv6 address of the
              DODAG parent of the node originally issuing the Transit
              Information option. This field may not be present, as according
              to the DODAG Mode of Operation (Storing or Non-Storing) and
              indicated by the Transit Information option length.</t>
            </list></t>

          <t>Unassigned bits of the Transit Information option are reserved.
          They MUST be set to zero on transmission and MUST be ignored on
          reception.</t>
        </section>

        <section title="Solicited Information">
          <t>The Solicited Information option MAY be present in DIS messages,
          and its format is as follows:</t>

          <t><figure anchor="SolicitedInformation"
              title="Format of the Solicited Information Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D|  Flags  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            DODAGID                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version Number |
    +-+-+-+-+-+-+-+-+
        
]]></artwork>
            </figure></t>

          <t>The Solicited Information option is used for a node to request
          DIO messages from a subset of neighboring nodes. The Solicited
          Information option may specify a number of predicate criteria to be
          matched by a receiving node. This is used by the requester to limit
          the number of replies from "non-interesting" nodes. These predicates
          affect whether a node resets its DIO Trickle timer, as described in
          <xref target="DIOTransmission"></xref>.</t>

          <t>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.)</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x07</t>

              <t hangText="Option Length:">19</t>

              <t hangText="V:">The 'V' flag is the Version predicate. The
              Version predicate is true if the receiver's DODAGVersionNumber
              matches the requested Version Number. If the 'V' flag is cleared,
              then the Version field is not valid and the Version field MUST
              be set to zero on transmission and ignored upon receipt.</t>

              <t hangText="I:">The 'I' flag is the InstanceID predicate. The
              InstanceID predicate is true when the RPL node's current
              RPLInstanceID matches the requested RPLInstanceID. If the 'I' flag
              is cleared, then the RPLInstanceID field is not valid and the
              RPLInstanceID field MUST be set to zero on transmission and
              ignored upon receipt.</t>

              <t hangText="D:">The 'D' flag is the DODAGID predicate. The
              DODAGID predicate is true if the RPL node's parent set has the
              same DODAGID as the DODAGID field. If the 'D' flag is cleared, then
              the DODAGID field is not valid and the DODAGID field MUST be set
              to zero on transmission and ignored upon receipt.</t>

              <t hangText="Flags:">The 5 bits remaining unused in the Flags
              field are reserved for flags. The field MUST be initialized to
              zero by the sender and MUST be ignored by the receiver.</t>

              <t hangText="Version Number:">8-bit unsigned integer containing
              the value of DODAGVersionNumber that is being solicited when
              valid.</t>

              <t hangText="RPLInstanceID:">8-bit unsigned integer containing
              the RPLInstanceID that is being solicited when valid.</t>

              <t hangText="DODAGID:">128-bit unsigned integer containing the
              DODAGID that is being solicited when valid.</t>
            </list></t>

          <t>Unassigned bits of the Solicited Information option are reserved.
          They MUST be set to zero on transmission and MUST be ignored on
          reception.</t>
        </section>

        <section title="Prefix Information">
          <t>The Prefix Information Option (PIO) MAY be present in DIO messages, and
          carries the information that is specified for the IPv6 ND Prefix
          Information option in <xref target="RFC4861"></xref>, <xref
          target="RFC4862"></xref>, and <xref target="RFC6275"></xref> for use
          by RPL nodes and IPv6 hosts. In particular, a RPL node may use this
          option for the purpose of Stateless Address Autoconfiguration
          (SLAAC) from a prefix advertised by a parent as specified in <xref
          target="RFC4862"></xref>, and advertise its own address as specified
          in <xref target="RFC6275"></xref>. 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 overwrite the Interface ID if the 'R' flag is set to
          indicate its full address in the PIO.  The format of the option is
          modified (Type, Length, Prefix) in order to be carried as a RPL
          option as follows:</t>
<t>If the only desired effect of a received PIO in a DIO is to provide
   the global address of the parent node to the receiving node, then the
   sender resets the 'A' and 'L' bits and sets the 'R' bit. Upon 
   receipt, the RPL will not autoconfigure an address or a connected
   route from the prefix <xref target="RFC4862" />. As in all cases, when the 'L' bit is
   not set, the RPL node MAY include the prefix in PIOs it sends to its
   children.</t>

          <t><figure anchor="DIOsubPrefixInformation"
              title="Format of the Prefix Information Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x08 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Valid Lifetime                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Preferred Lifetime                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Reserved2                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            Prefix                             +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>The PIO may be used to distribute the
          prefix in use inside the DODAG, e.g., for address
          autoconfiguration.</t>

          <t><xref target="RFC4861"></xref> and <xref target="RFC6275"></xref>
          should be consulted as the authoritative reference with respect to
          the PIO. The field descriptions are
          transcribed here for convenience:</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x08</t>

              <t hangText="Option Length:">30. Note that this length is
              expressed in units of single octets, unlike in IPv6 ND.</t>

              <t hangText="Prefix Length:">8-bit unsigned integer. The number
              of leading bits in the Prefix field 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 PIO). It also assists with
              address autoconfiguration as specified in <xref
              target="RFC4862"></xref>, for which there may be more
              restrictions on the prefix length.</t>

              <t hangText="L:">1-bit on-link flag. When set, it 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.</t>

              <t hangText="A:">1-bit autonomous address-configuration flag.
              When set, it indicates that this prefix can be used for stateless
              address configuration as specified in <xref
              target="RFC4862"></xref>. 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.</t>

              <t hangText="R:">1-bit router address flag. When set, it indicates
              that the Prefix field contains a complete IPv6 address assigned
              to the sending router that can be used as parent in a target
              option. The indicated prefix is the first prefix length bits of
              the Prefix field. The router IPv6 address has the same scope and
              conforms to the same lifetime values as the advertised prefix.
              This use of the Prefix field is compatible with its use in
              advertising the prefix itself, since Prefix Advertisement uses
              only the leading bits. Interpretation of this flag bit is thus
              independent of the processing required for the on-link (L) and
              autonomous address-configuration (A) flag bits.</t>

              <t hangText="Reserved1:">5-bit unused field. It MUST be
              initialized to zero by the sender and MUST be ignored by the
              receiver.</t>

              <t hangText="Valid Lifetime:">32-bit unsigned integer. The length
              of time in seconds (relative to the time the packet is sent)
              that the prefix is valid for the purpose of on-link
              determination. A value of all one bits (0xFFFFFFFF) represents
              infinity. The Valid Lifetime is also used by <xref
              target="RFC4862"></xref>.</t>

              <t hangText="Preferred Lifetime:">32-bit unsigned integer. The
              length of time in seconds (relative to the time the packet is
              sent) that addresses generated from the prefix via stateless
              address autoconfiguration remain preferred <xref
              target="RFC4862"></xref>. A value of all one bits (0xFFFFFFFF)
              represents infinity. See <xref target="RFC4862"></xref>. Note
              that the value of this field MUST NOT exceed the Valid Lifetime
              field to avoid preferring addresses that are no longer
              valid.</t>

              <t hangText="Reserved2:">This field is unused. It MUST be
              initialized to zero by the sender and MUST be ignored by the
              receiver.</t>

              <t hangText="Prefix:">An IPv6 address or a prefix of an IPv6
              address. The Prefix Length field contains the number of valid
              leading bits in the prefix. The bits in the prefix after the
              prefix length are reserved and MUST be initialized to zero by
              the sender and ignored by the receiver. A router SHOULD NOT send
              a prefix option for the link-local prefix, and a host SHOULD
              ignore such a prefix option. A non-storing node SHOULD refrain
              from advertising a prefix till it owns an address of that
              prefix, and then it SHOULD advertise its full address in this
              field, with the 'R' flag set. The children of a node that so
              advertises a full address with the 'R' flag set may then use
              that address to determine the content of the DODAG Parent Address
              subfield of the Transit Information option.</t>
            </list></t>

          <t>Unassigned bits of the PIO are reserved.
          They MUST be set to zero on transmission and MUST be ignored on
          reception.</t>
        </section>

        <section anchor="RPLtargetdescoptsec" title="RPL Target Descriptor">
          <t>The RPL Target option MAY be immediately followed by one opaque
          descriptor that qualifies that specific target.</t>

          <t><figure anchor="RPLtargetdescopt"
              title="Format of the RPL Target Descriptor Option">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x09 |Opt Length = 4 |           Descriptor           
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Descriptor (cont.)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>The RPL Target Descriptor option is used to qualify a target,
          something that is sometimes called "tagging".</t>

          <t>At most, there can be one descriptor per target. The descriptor is
          set by the node that injects the Target in the RPL network. It MUST
          be copied but not modified by routers that propagate the Target Up
          the DODAG in DAO messages.</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Option Type:">0x09</t>

              <t hangText="Option Length:">4</t>

              <t hangText="Descriptor:">32-bit unsigned integer. Opaque.</t>
            </list></t>
        </section>
      </section>
    </section>

    <section anchor="SequenceNumbers" title="Sequence Counters">
      <t>This section describes the general scheme for bootstrap and operation
      of sequence counters in RPL, such as the DODAGVersionNumber in the DIO
      message, the DAOSequence in the DAO message, and the Path Sequence in
      the Transit Information option.</t>

      <section title="Sequence Counter Overview">
        <t>This specification utilizes three different sequence numbers to
        validate the freshness and the synchronization of protocol
        information:</t>

        <t><list hangIndent="24" style="hanging">
            <t hangText="DODAGVersionNumber:">This sequence counter is
            present in the DIO Base to indicate the Version of the DODAG being
            formed. The DODAGVersionNumber is monotonically incremented by the
            root each time the root decides to form a new Version of the DODAG
            in order to revalidate the integrity and allow a global repair 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 in which a router is operating.
            An older (lesser) value indicates that the originating router has
            not migrated to the new DODAG Version and cannot be used as a
            parent once the receiving node has migrated to the newer DODAG
            Version.</t>

            <t hangText="DAOSequence:">This sequence counter is present in
            the DAO Base to correlate a DAO message and a DAO ACK message. The
            DAOSequence number is locally significant to the node that issues
            a DAO message for its own consumption to detect the loss of a DAO
            message and enable retries.</t>

            <t hangText="Path Sequence:">This sequence counter is present in
            the Transit Information option in a DAO message. The purpose of
            this counter is to differentiate a movement where a newer route
            supersedes a stale one from a route redundancy scenario where
            multiple routes exist in parallel for the 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 the same Target is issued to multiple parents
            at a given point in time for the purpose of route redundancy, then
            the Path Sequence is the same in all the DAO messages for that
            same target.</t>
          </list></t>
      </section>

      <section title="Sequence Counter Operation">
        <t>RPL sequence counters are subdivided in a 'lollipop' fashion <xref
        target="Perlman83"></xref>, where the values from 128 and greater are
        used as a linear sequence to indicate a restart and bootstrap the
        counter, and the values less than or equal to 127 used as a circular
        sequence number space of size 128 as in <xref
        target="RFC1982"></xref>. Consideration is given to the mode of
        operation when transitioning from the linear region to the circular
        region. Finally, when operating in the circular region, if sequence
        numbers are detected to be too far apart, then they are not comparable,
        as detailed below.</t>

        <t>A window of comparison, SEQUENCE_WINDOW = 16, is configured based
        on a value of 2^N, where N is defined to be 4 in this
        specification.</t>

        <t>For a given sequence counter: <list style="numbers">
            <t>The sequence counter SHOULD be initialized to an implementation
            defined value, which is 128 or greater prior to use. A recommended
            value is 240 (256 - SEQUENCE_WINDOW).</t>

            <t>When a sequence counter increment would cause the sequence
            counter to increment beyond its maximum value, the sequence
            counter MUST wrap back to zero. When incrementing a sequence
            counter greater than or equal to 128, the maximum value is 255.
            When incrementing a sequence counter less than 128, the maximum
            value is 127.</t>

            <t>When comparing two sequence counters, the following rules MUST
            be applied: <list style="numbers">
                <t>When a first sequence counter A is in the interval
                [128..255] and a second sequence counter B is in [0..127]:
                <list style="numbers">
                    <t>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.</t>

                    <t>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.</t>
                  </list> 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.</t>

                <t>In the case where both sequence counters to be compared are
                less than or equal to 127, and in the case where both sequence
                counters to be compared are greater than or equal to 128:<list
                    style="numbers">
                    <t>If the absolute magnitude of difference between the two
                    sequence counters is less than or equal to
                    SEQUENCE_WINDOW, then a comparison as described in <xref
                    target="RFC1982"></xref> is used to determine the
                    relationships greater than, less than, and equal.</t>

                    <t>If the absolute magnitude of difference of the two
                    sequence counters is greater than SEQUENCE_WINDOW, then a
                    desynchronization has occurred and the two sequence
                    numbers are not comparable.</t>
                  </list></t>
              </list></t>

            <t>If two sequence numbers are determined not to be comparable,
            i.e., the results of the comparison are not defined, then a node
            should consider the comparison as if it has evaluated in such a
            way so as to give precedence to the sequence number that has most
            recently been observed to increment. Failing this, the node should
            consider the comparison as if it has evaluated in such a way so as
            to minimize the resulting changes to its own state.</t>
          </list></t>
      </section>
    </section>

    <section anchor="UpwardRoutes" title="Upward Routes">
      <t>This section describes how RPL discovers and maintains Upward routes.
      It describes the use of DODAG Information Objects (DIOs), the messages
      used to discover and maintain these routes. It specifies how RPL
      generates and responds to DIOs. It also describes DODAG Information
      Solicitation (DIS) messages, which are used to trigger DIO
      transmissions.</t>

      <t>As mentioned in <xref target="daop"></xref>, 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 Upward until it eventually hits a common ancestor from which
      it will be routed Downward 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 cannot forward
      the packet outside, then the DODAG root has to drop it.</t>

      <t>A DIO message can also transport explicit routing information: <list
          hangIndent="24" style="hanging">
          <t hangText="DODAGID:">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
          the DODAGID.</t>

          <t hangText="RIO Prefix:">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 <xref target="dejaneiro"></xref>, which
          incorporates the RIO from <xref target="RFC4191"></xref>. 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 the same instance.</t>
        </list></t>

      <section anchor="DIOBaseRules" title="DIO Base Rules">
        <t><list style="numbers">
            <t>For the following DIO Base fields, a node that is not a DODAG
            root MUST advertise the same values as its preferred DODAG parent
            (defined in <xref target="parentset"></xref>). In this way, these
            values will propagate Down the DODAG unchanged and advertised by
            every node that has a route to that DODAG root. These fields are as follows:
            <?rfc subcompact="yes"?><list>
                <t>Grounded (G)</t>

                <t>Mode of Operation (MOP)</t>

                <t>DAGPreference (Prf)</t>

                <t>Version</t>

                <t>RPLInstanceID</t>

                <t>DODAGID</t>
              </list><?rfc subcompact="no"?></t>

            <t>A node MAY update the following fields at each hop: <?rfc subcompact="yes"?><list>
                <t>Rank</t>

                <t>DTSN</t>
              </list><?rfc subcompact="no"?></t>

            <t>The DODAGID field each root sets MUST be unique within the RPL
            Instance and MUST be a routable IPv6 address belonging to the
            root.</t>
          </list></t>
      </section>

      <section anchor="DAGDiscovery"
               title="Upward Route Discovery and Maintenance">
        <t>Upward route discovery allows a node to join a DODAG by discovering
        neighbors that are members of the DODAG of interest and identifying a
        set of parents. The exact policies for selecting neighbors and parents
        is implementation dependent and driven by the OF. This section
        specifies the set of rules those policies must follow for
        interoperability.</t>

        <section anchor="parentset"
                 title="Neighbors and Parents within a DODAG Version">
          <t>RPL's Upward route discovery algorithms and processing are in
          terms of three logical sets of link-local nodes. First, the
          candidate neighbor set is a subset of the nodes that can be reached
          via link-local multicast. The selection of this set is
          implementation 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. Conceptually, the preferred parent is a
          single parent; although, it may be a set of multiple parents if those
          parents are equally preferred and have identical Rank.</t>

          <t>More precisely: <list style="numbers">
              <t>The DODAG parent set MUST be a subset of the candidate
              neighbor set.</t>

              <t>A DODAG root MUST have a DODAG parent set of size zero.</t>

              <t>A node that is not a DODAG root MAY maintain a DODAG parent
              set of size greater than or equal to one.</t>

              <t>A node's preferred DODAG parent MUST be a member of its DODAG
              parent set.</t>

              <t>A node's Rank MUST be greater than all elements of its DODAG
              parent set.</t>

              <t>When Neighbor Unreachability Detection (NUD) <xref
              target="RFC4861"></xref>, or an equivalent mechanism, determines
              that a neighbor is no longer reachable, a RPL node MUST NOT
              consider this node in the candidate neighbor set when
              calculating and advertising routes until it determines that it
              is again reachable. Routes through an unreachable neighbor MUST
              be removed from the routing table.</t>
            </list></t>

          <t>These rules ensure that there is a consistent partial order on
          nodes within the DODAG. As long as node Ranks do not change,
          following the above rules ensures that every node's route to a DODAG
          root is loop-free, as Rank decreases on each hop to the root.</t>

          <t>The OF can guide candidate neighbor set and parent set selection,
          as discussed in <xref target="RFC6552"></xref>.</t>
        </section>

        <section anchor="DAGDiscoveryRules"
                 title="Neighbors and Parents across DODAG Versions">
          <t>The above rules govern a single DODAG Version. The rules in this
          section define how RPL operates when there are multiple DODAG
          Versions.</t>

          <section anchor="DAGDiscoveryRulesSeq" title="DODAG Version">
            <t><list style="numbers">
                <t>The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber)
                uniquely defines a DODAG Version. Every element of a node's
                DODAG parent set, as conveyed by the last heard DIO message
                from each DODAG parent, MUST belong to the same DODAG Version.
                Elements of a node's candidate neighbor set MAY belong to
                different DODAG Versions.</t>

                <t>A node is a member of a DODAG Version if every element of
                its DODAG parent set belongs to that DODAG Version, or if that
                node is the root of the corresponding DODAG.</t>

                <t>A node MUST NOT send DIOs for DODAG Versions of which it is
                not a member.</t>

                <t>DODAG roots MAY increment the DODAGVersionNumber that they
                advertise and thus move to a new DODAG Version. When a DODAG
                root increments its DODAGVersionNumber, it MUST follow the
                conventions of Serial Number Arithmetic as described in <xref
                target="SequenceNumbers"></xref>. Events triggering the
                increment of the DODAGVersionNumber are described later in
                this section and in <xref target="Manageability"></xref>.</t>

                <t>Within a given DODAG, a node that is a not a root MUST NOT
                advertise a DODAGVersionNumber higher than the highest
                DODAGVersionNumber it has heard. Higher is defined as the
                greater-than operator in <xref
                target="SequenceNumbers"></xref>.</t>

                <t>Once a node has advertised a DODAG Version by sending a
                DIO, it MUST NOT be a member of a previous DODAG Version of
                the same DODAG (i.e., with the same RPLInstanceID, the same
                DODAGID, and a lower DODAGVersionNumber). Lower is defined as
                the less-than operator in <xref
                target="SequenceNumbers"></xref>.</t>
              </list></t>

            <t>When the DODAG parent set becomes empty on a node that is not a
            root, (i.e., the last parent has been removed, causing the node no longer to
            be associated with that DODAG), then the DODAG
            information should not be suppressed until after the expiration of
            an implementation-specific local timer. During the interval prior
            to suppression of the "old" DODAG state, the node will be able to
            observe if the DODAGVersionNumber has been incremented should any
            new parents appear. This will help protect against the possibility
            of loops that may occur if that node were to inadvertently rejoin
            the old DODAG Version in its own prior sub-DODAG.</t>

            <t>As the DODAGVersionNumber is incremented, a new DODAG Version
            spreads outward from the DODAG root. A parent that advertises the
            new DODAGVersionNumber cannot belong to the sub-DODAG of a node
            advertising an older DODAGVersionNumber. Therefore, a node can
            safely add a parent of any Rank with a newer DODAGVersionNumber
            without forming a loop.</t>

            <t>For example, suppose that a node has left a DODAG with
            DODAGVersionNumber N.&nbsp; Suppose that a 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 adding that candidate neighbor as a parent could cause a
            loop. In this case, if that candidate neighbor 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. For this reason, it is
            useful for the detached node to remember the original DODAG
            information, including the DODAGVersionNumber N.</t>

            <t>Exactly when a DODAG root increments the DODAGVersionNumber is
            implementation 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.</t>

            <t>After a node transitions to and advertises a new DODAG Version,
            the rules above make it unable to advertise the previous DODAG
            Version (prior DODAGVersionNumber) once it has committed to
            advertising the new DODAG Version.</t>
          </section>

          <section anchor="DAGDiscoveryRulesRoot" title="DODAG Roots">
            <t><list style="numbers">
                <t>A DODAG root without possibility to satisfy the
                application-defined goal MUST NOT set the Grounded bit.</t>

                <t>A DODAG root MUST advertise a Rank of ROOT_RANK.</t>

                <t>A node whose DODAG parent set is empty MAY become the DODAG
                root of a floating DODAG. It MAY also set its DAGPreference
                such that it is less preferred.</t>
              </list></t>

            <t>In a deployment that uses non-LLN 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 the 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).</t>
          </section>

          <section anchor="DAGSelection" title="DODAG Selection">
            <t>The Objective Function and the set of advertised routing
            metrics and constraints of a DAG determine how a node selects its
            neighbor set, parent set, and preferred parents. This selection
            implicitly also determines the DODAG within a DAG. Such selection
            can include administrative preference (Prf) as well as metrics or
            other considerations.</t>

            <t>If a node has the option to join a more preferred DODAG while
            still meeting other optimization objectives, then the node will
            generally seek to join the more preferred DODAG as determined by
            the OF. All else being equal, it is left to the implementation to
            determine which DODAG is most preferred (since, as a reminder, a
            node must only join one DODAG per RPL Instance).</t>
          </section>

          <section anchor="DAGDiscoveryRulesMove"
                   title="Rank and Movement within a DODAG Version">
            <t><list style="numbers">
                <t>A node MUST NOT advertise a Rank less than or equal to any
                member of its parent set within the DODAG Version.</t>

                <t>A node MAY advertise a Rank lower than its prior
                advertisement within the DODAG Version.</t>

                <t>Let L be the lowest Rank within a DODAG Version that a
                given node has advertised. Within the same DODAG Version, that
                node MUST NOT advertise an effective Rank higher than L +
                DAGMaxRankIncrease. INFINITE_RANK is an exception to this
                rule: a node MAY advertise an INFINITE_RANK within a DODAG
                Version without restriction. If a node's Rank were to be
                higher than allowed by L + DAGMaxRankIncrease, when it
                advertises Rank, it MUST advertise its Rank as
                INFINITE_RANK.</t>

                <t>A node MAY, at any time, choose to join a different DODAG
                within a RPL Instance. Such a join has no Rank restrictions,
                unless that different DODAG is a DODAG Version of which this
                node has previously been a member; in which case, the rule of
                the previous bullet (3) must be observed. Until a node
                transmits a DIO indicating its new DODAG membership, it MUST
                forward packets along the previous DODAG.</t>

                <t>A node MAY, at any time after hearing the next
                DODAGVersionNumber advertised from suitable DODAG parents,
                choose to migrate to the next DODAG Version within the
                DODAG.</t>
              </list></t>

            <t>Conceptually, an implementation is maintaining a DODAG parent
            set within the DODAG Version. Movement entails changes to the
            DODAG parent set. Moving Up does not present the risk to create a
            loop but moving Down might, so that operation is subject to
            additional constraints.</t>

            <t>When a node migrates to the next DODAG Version, the DODAG
            parent set needs to be rebuilt for the new Version. An
            implementation could defer to migrate for some reasonable amount
            of time, to see if some other neighbors with potentially better
            metrics but higher Rank announce themselves. Similarly, when a
            node jumps into a new DODAG, it needs to construct a new DODAG
            parent set for this new DODAG.</t>

            <t>If a node needs to move Down a DODAG that it is attached to,
            increasing its Rank, then it MAY poison its routes and delay
            before moving as described in <xref
            target="DAGDiscoveryRulesPoison"></xref>.</t>

            <t>A node is allowed to join any DODAG Version that it has never
            been a prior member of without any restrictions, but if the node
            has been a prior member of the DODAG Version, then it must continue
            to observe the rule that it may not advertise 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.</t>
          </section>

          <section anchor="DAGDiscoveryRulesPoison" title="Poisoning">
            <t><list style="numbers">
                <t>A node poisons routes by advertising a Rank of
                INFINITE_RANK.</t>

                <t>A node MUST NOT have any nodes with a Rank of INFINITE_RANK
                in its parent set.</t>
              </list></t>

            <t>Although an implementation may advertise INFINITE_RANK for the
            purposes of poisoning, doing so is not the same as setting Rank to
            INFINITE_RANK. For example, a node may continue to send data
            packets whose RPL Packet Information includes a Rank that is not
            INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs.</t>

            <t>When a (former) parent is observed to advertise a Rank of
            INFINITE_RANK, that (former) parent has detached from the DODAG
            and is no longer able to act as a parent, nor is there any way
            that another node may be considered to have a Rank greater-than
            INFINITE_RANK. Therefore, that (former) parent cannot act as a
            parent any longer and is removed from the parent set.</t>
          </section>

          <section anchor="DAGDiscoveryRulesdetach" title="Detaching">
            <t><list style="numbers">
                <t>A node unable to stay connected to a DODAG within a given
                DODAG Version, i.e., that cannot retain non-empty parent set
                without violating the rules of this specification, MAY detach
                from this DODAG Version. A node that detaches becomes the root of
                its own floating DODAG and SHOULD immediately advertise this
                new situation in a DIO as an alternate to poisoning.</t>
              </list></t>
          </section>

          <section anchor="DAGDiscoveryRulesfollow" title="Following a Parent">
            <t><list style="numbers">
                <t>If a node receives a DIO from one of its DODAG parents,
                indicating that the parent has left the DODAG, that node
                SHOULD stay in its current DODAG through an alternative DODAG
                parent, if possible. It MAY follow the leaving parent.</t>
              </list></t>

            <t>A DODAG parent may have moved, migrated to the next DODAG
            Version, or jumped to a different DODAG. A node ought to give some
            preference to remaining in the current DODAG, if possible via an
            alternate parent, but ought to follow the parent if there are no
            other options.</t>
          </section>
        </section>

        <section title="DIO Message Communication">
          <t>When a DIO message is received, the receiving node must first
          determine whether or not the DIO message should be accepted for
          further processing, and subsequently present the DIO message for
          further processing if eligible.</t>

          <t><list style="numbers">
              <t>If the DIO message is malformed, then the DIO message is not
              eligible for further processing and a node MUST silently discard
              it. (See <xref target="Manageability"></xref> for error
              logging).</t>

              <t>If the sender of the DIO message is a member of the candidate
              neighbor set and the DIO message is not malformed, the node MUST
              process the DIO.</t>
            </list></t>

          <section title="DIO Message Processing">
            <t>As DIO messages are received from candidate neighbors, the
            neighbors may be promoted to DODAG parents by following the rules
            of DODAG discovery as described in <xref
            target="DAGDiscovery"></xref>. When a node places a neighbor into
            the DODAG parent set, the node becomes attached to the DODAG
            through the new DODAG parent node.</t>

            <t>The most preferred parent should be used to restrict which
            other nodes may become DODAG parents. Some nodes in the DODAG
            parent set may be of a Rank less than or equal to the most
            preferred DODAG parent. (This case may occur, for example, if an
            energy-constrained device is at a lesser Rank but should be
            avoided per an optimization objective, resulting in a more
            preferred parent at a greater Rank.)</t>
          </section>
        </section>
      </section>

      <section anchor="DIOTransmission" title="DIO Transmission">
        <t>RPL nodes transmit DIOs using a Trickle timer <xref
        target="RFC6206"></xref>. A DIO from a sender with a
        lesser DAGRank that causes no changes to the recipient's parent set,
        preferred parent, or Rank SHOULD be considered consistent with respect
        to the Trickle timer.</t>

        <t>The following packets and events MUST be considered inconsistencies
        with respect to the Trickle timer, and cause the Trickle timer to
        reset:</t>

        <t><list style="symbols">
            <t>When a node detects an inconsistency when forwarding a packet,
            as detailed in <xref target="loopdetect"></xref>.</t>

            <t>When a node receives a multicast DIS message without a
            Solicited Information option, unless a DIS flag restricts this
            behavior.</t>

            <t>When a node receives a multicast DIS with a Solicited
            Information option and the node matches all of the predicates in
            the Solicited Information option, unless a DIS flag restricts this
            behavior.</t>

            <t>When a node joins a new DODAG Version (e.g., by updating its
            DODAGVersionNumber, joining a new RPL Instance, etc.).</t>
          </list></t>

        <t>Note that this list is not exhaustive, and an implementation MAY
        consider other messages or events to be inconsistencies.</t>

        <t>A node SHOULD NOT reset its DIO Trickle timer in response to
        unicast DIS messages. When a node receives a unicast DIS without a
        Solicited Information option, it MUST unicast a DIO to the sender in
        response. This DIO MUST include a DODAG Configuration option. When a
        node receives a unicast DIS message with a Solicited Information
        option and matches the predicates of that Solicited Information
        option, it MUST unicast a DIO to the sender in response. This unicast
        DIO MUST include a DODAG Configuration option. Thus, a node MAY
        transmit a unicast DIS message to a potential DODAG parent in order to
        probe for DODAG Configuration and other parameters.</t>

        <section anchor="TrickleParameters" title="Trickle Parameters">
          <t>The configuration parameters of the Trickle timer are specified
          as follows:</t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Imin:">learned from the DIO message as
              (2^DIOIntervalMin) ms. The default value of DIOIntervalMin is
              DEFAULT_DIO_INTERVAL_MIN.</t>

              <t hangText="Imax:">learned from the DIO message as
              DIOIntervalDoublings. The default value of DIOIntervalDoublings
              is DEFAULT_DIO_INTERVAL_DOUBLINGS.</t>

              <t hangText="k:">learned from the DIO message as
              DIORedundancyConstant. The default value of
              DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. In
              RPL, when k has the value of 0x00, this is to be treated as a
              redundancy constant of infinity in RPL, i.e., Trickle never
              suppresses messages.</t>
            </list></t>
        </section>
      </section>

      <section title="DODAG Selection">
        <t>The DODAG selection is implementation and OF dependent. In order to
        limit erratic movements, and all metrics being equal, nodes SHOULD
        keep their previous selection. Also, nodes SHOULD provide a means to
        filter out a parent whose availability is detected as fluctuating, at
        least when more stable choices are available.</t>

        <t>When connection to a grounded DODAG is not possible or preferable
        for security or other reasons, scattered DODAGs MAY aggregate as much
        as possible into larger DODAGs in order to allow connectivity within
        the LLN.</t>

        <t>A node SHOULD verify that bidirectional connectivity and adequate
        link quality is available with a candidate neighbor before it
        considers that candidate as a DODAG parent.</t>
      </section>

      <section anchor="OperationAsALeaf" title="Operation as a Leaf Node">
        <t>In some cases, a RPL node may attach to a DODAG as a leaf node only.
        One example of such a case is when a node does not understand or does
        not support (policy) the RPL Instance's OF or advertised
        metric/constraint. As specified in <xref target="mgmtPolicy"></xref>,
        related to policy function, the node may either join the DODAG as a
        leaf node or may not join the DODAG. As mentioned in <xref
        target="mgmtFault"></xref>, it is then recommended to log a fault.</t>

        <t>A leaf node does not extend DODAG connectivity; however, in some cases,
        the leaf node may still need to transmit DIOs on occasion, in
        particular, when the leaf node may not have always been acting as a
        leaf node and an inconsistency is detected.</t>

        <t>A node operating as a leaf node must obey the following rules:</t>

        <t><list style="numbers">
            <t>It MUST NOT transmit DIOs containing the DAG Metric
            Container.</t>

            <t>Its DIOs MUST advertise a DAGRank of INFINITE_RANK.</t>

            <t>It MAY suppress DIO transmission, unless the DIO transmission
            has been triggered due to detection of inconsistency when a packet
            is being forwarded or in response to a unicast DIS message, in
            which case the DIO transmission MUST NOT be suppressed.</t>

            <t>It MAY transmit unicast DAOs as described in <xref
            target="DownwardDiscovery"></xref>.</t>

            <t>It MAY transmit multicast DAOs to the '1 hop' neighborhood as
            described in <xref target="MulticastDAO"></xref>.</t>
          </list></t>

        <t>A particular case that requires a leaf node to send a DIO is if
        that leaf node was a prior member of another DODAG and another node
        forwards a message assuming the old topology, triggering an
        inconsistency. The leaf node needs to transmit a DIO in order to
        repair the inconsistency. Note that due to the lossy nature of LLNs,
        even though the leaf node may have optimistically poisoned its routes
        by advertising a Rank of INFINITE_RANK in the old DODAG prior to
        becoming a leaf node, that advertisement may have become lost and a
        leaf node must be capable to send a DIO later in order to repair the
        inconsistency.</t>

        <t>In the general case, the leaf node MUST NOT advertise itself as a
        router (i.e., send DIOs).</t>
      </section>

      <section title="Administrative Rank">
        <t>In some cases, it might be beneficial to adjust the Rank advertised
        by a node beyond that computed by the OF based on some implementation-specific policy and properties of the node. For example, a node that
        has a limited battery should be a leaf unless there is no other choice,
        and may then augment the Rank computation specified by the OF in order
        to expose an exaggerated Rank.</t>
      </section>
    </section>

    <section anchor="DownwardRoutes" title="Downward Routes">
      <t>This section describes how RPL discovers and maintains Downward
      routes. RPL constructs and maintains Downward routes with Destination
      Advertisement Object (DAO) messages. Downward routes support P2MP flows,
      from the DODAG roots toward the leaves. Downward routes also support P2P
      flows: P2P messages can flow toward a DODAG root (or a common ancestor)
      through an Upward route, then away from the DODAG root to a destination
      through a Downward route.</t>

      <t>This specification describes the two modes a RPL Instance may choose
      from for maintaining Downward routes. In the first mode, called
      "Storing", nodes store Downward routing tables for their sub-DODAG. Each
      hop on a Downward route in a storing network examines its routing table
      to decide on the next hop. In the second mode, called "Non-Storing",
      nodes do not store Downward routing tables. Downward packets are routed
      with source routes populated by a DODAG root <xref
      target="RFC6554"></xref>.</t>

      <t>RPL allows a simple one-hop P2P optimization for both storing and
      non-storing networks. A node may send a P2P packet destined to a one-hop
      neighbor directly to that node.</t>

      <section title="Destination Advertisement Parents">
        <t>To establish Downward routes, RPL nodes send DAO messages Upward.
        The next-hop destinations of these DAO messages are called "DAO
        parents". The collection of a node's DAO parents is called the "DAO
        parent set".</t>

        <t><list style="numbers">
            <t>A node 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.</t>

            <t>A node's DAO parent set MUST be a subset of its DODAG parent
            set.</t>

            <t>In Storing mode operation, a node MUST NOT address unicast DAO
            messages to nodes that are not DAO parents.</t>

            <t>In Storing mode operation, the IPv6 source and destination
            addresses of a DAO message MUST be link-local addresses.</t>

            <t>In Non-Storing mode operation, a node MUST NOT address unicast
            DAO messages to nodes that are not DODAG roots.</t>

            <t>In Non-Storing mode operation, the IPv6 source and destination
            addresses of a DAO message MUST be a unique-local or a global
            address.</t>
          </list></t>

        <t>The selection of DAO parents is implementation and Objective
        Function specific.</t>
      </section>

      <section anchor="DownwardDiscovery"
               title="Downward Route Discovery and Maintenance">
        <t>Destination Advertisement may be configured to be entirely
        disabled, or operate in either a Storing or Non-Storing mode, as
        reported in the MOP in the DIO message.</t>

        <t><list style="numbers">
            <t>All nodes who join a DODAG MUST abide by the MOP setting from
            the root. Nodes that do not have the capability to fully
            participate as a router, e.g., that do not match the advertised
            MOP, MAY join the DODAG as a leaf.</t>

            <t>If the MOP is 0, indicating no Downward routing, nodes MUST NOT
            transmit DAO messages and MAY ignore DAO messages.</t>

            <t>In Non-Storing mode, the DODAG root SHOULD store source routing
            table entries for destinations learned from DAOs. The DODAG root
            MUST be able to generate source routes for those destinations
            learned from DAOs that were stored.</t>

            <t>In Storing mode, all non-root, non-leaf nodes MUST store
            routing table entries for destinations learned from DAOs.</t>
          </list></t>

        <t>A DODAG can have one of several possible modes of operation, as
        defined by the MOP field. Either it does not support Downward routes,
        it supports Downward routes through source routing from DODAG roots,
        or it supports Downward routes through in-network routing tables.</t>

        <t>When Downward routes are supported through source routing from
        DODAG roots, it is generally expected that the DODAG root has stored
        the source routing information learned from DAOs in order to construct
        the source routes. If the DODAG root fails to store some information,
        then some destinations may be unreachable.</t>

        <t>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.</t>

        <t>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 (<xref target="mgmtFault"></xref>). Future extensions to RPL
        may elaborate on refined actions/behaviors to manage this case.</t>

        <t>As of the writing of this specification, RPL does not support mixed-mode operation,
        where some nodes source route and other store routing tables: future
        extensions to RPL may support this mode of operation.</t>

        <section title="Maintenance of Path Sequence">
          <t>For each Target that is associated with (owned by) a node, that
          node is responsible to emit DAO messages in order to provision the
          Downward routes. The Target+Transit information contained in those
          DAO messages subsequently propagates Up the DODAG. The Path Sequence
          counter in the Transit information option is used to indicate
          freshness and update stale Downward routing information as described
          in <xref target="SequenceNumbers"></xref>.</t>

          <t>For a Target that is associated with (owned by) a node, that node
          MUST increment the Path Sequence counter, and generate a new DAO
          message, when:<list style="numbers">
              <t>the Path Lifetime is to be updated (e.g., a refresh or a
              no-Path).</t>

              <t>the DODAG Parent Address subfield list is to be changed.</t>
            </list></t>

          <t>For a Target that is associated with (owned by) a node, that node
          MAY increment the Path Sequence counter, and generate a new DAO
          message, on occasion in order to refresh the Downward routing
          information. In Storing mode, the node generates such a DAO to each of
          its DAO parents in order to enable multipath. All DAOs generated at
          the same time for the same Target MUST be sent with the same Path
          Sequence in the Transit Information.</t>
        </section>

        <section title="Generation of DAO Messages">
          <t>A node might send DAO messages when it receives DAO messages, as
          a result of changes in its DAO parent set, or in response to another
          event such as the expiry of a related prefix lifetime. In the case
          of receiving DAOs, it matters whether the DAO message is "new" or
          contains new information. In Non-Storing mode, every DAO message a
          node receives is "new".  In Storing mode, a DAO message is "new" if
          it satisfies any of these criteria for a contained Target: <list
              style="numbers">
              <t>it has a newer Path Sequence number,</t>

              <t>it has additional Path Control bits, or</t>

              <t>it is a No-Path DAO message that removes the last Downward route
              to a prefix.</t>
            </list></t>

          <t>A node that receives a DAO message from its sub-DODAG MAY
          suppress scheduling a DAO message transmission if that DAO message
          is not new.</t>
        </section>
      </section>

      <section anchor="DAOBaseRules" title="DAO Base Rules">
        <t><list style="numbers">
            <t>If a node sends a DAO message with newer or different
            information than the prior DAO message transmission, it MUST
            increment the DAOSequence field by at least one. A DAO message
            transmission that is identical to the prior DAO message
            transmission MAY increment the DAOSequence field.</t>

            <t>The RPLInstanceID and DODAGID fields of a DAO message MUST be
            the same value as the members of the node's parent set and the
            DIOs it transmits.</t>

            <t>A node MAY set the 'K' flag in a unicast DAO message to solicit
            a unicast DAO-ACK in response in order to confirm the attempt.</t>

            <t>A node receiving a unicast DAO message with the 'K' flag set
            SHOULD respond with a DAO-ACK. A node receiving a DAO message
            without the 'K' flag set MAY respond with a DAO-ACK, especially to
            report an error condition.</t>

            <t>A node that sets the 'K' flag in a unicast DAO message but does
            not receive a DAO-ACK in response MAY reschedule the DAO message
            transmission for another attempt, up until an
            implementation-specific number of retries.</t>

            <t>Nodes SHOULD ignore DAOs without newer sequence numbers and
            MUST NOT process them further.</t>
          </list></t>

        <t>Unlike the Version field of a DIO, which is incremented only by a
        DODAG root and repeated unchanged by other nodes, DAOSequence values
        are unique to each node. The sequence number space for unicast and
        multicast DAO messages can be either the same or distinct. It is
        RECOMMENDED to use the same sequence number space.</t>
      </section>

      <section anchor="DAOStructure" title="Structure of DAO Messages">
        <t>DAOs follow a common structure in both storing and non-storing
        networks. In the most general form, a DAO message may include several
        groups of options, where each group consists of one or more Target
        options followed by one or more Transit Information options. The
        entire group of Transit Information options applies to the entire
        group of Target options. Later sections describe further details for
        each mode of operation.</t>

        <t><list style="numbers">
            <t>RPL nodes MUST include one or more RPL Target options in each
            DAO message they transmit. One RPL Target option MUST have a
            prefix that includes the node's IPv6 address if that node needs
            the DODAG to provision Downward routes to that node. The RPL
            Target option MAY be immediately followed by an opaque RPL Target
            Descriptor option that qualifies it.</t>

            <t>When a node updates the information in a Transit Information
            option for a Target option that covers one of its addresses, it
            MUST increment the Path Sequence number in that Transit
            Information option. The Path Sequence number MAY be incremented
            occasionally to cause a refresh to the Downward routes.</t>

            <t>One or more RPL Target options in a unicast DAO message MUST be
            followed by one or more Transit Information options. All the
            transit options apply to all the Target options that immediately
            precede them.</t>

            <t>Multicast DAOs MUST NOT include the DODAG Parent Address subfield in Transit
            Information options.</t>

            <t>A node that receives and processes a DAO message containing
            information for a specific Target, and that has prior information
            for that Target, MUST use the Path Sequence number in the Transit
            Information option associated with that Target in order to
            determine whether or not the DAO message contains updated
            information per <xref target="SequenceNumbers"></xref>.</t>

            <t>If a node receives a DAO message that does not follow the above
            rules, it MUST discard the DAO message without further
            processing.</t>
          </list></t>

        <t>In Non-Storing mode, 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 a Target in a DAO message MUST be
        collocated in the same router, or reachable on-link 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:</t>

        <t><list style="numbers">
            <t>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 on-link.</t>

            <t>A PIO with an '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 also
            sets the 'L' flag indicating that the prefix is on-link, then it
            MUST advertise the whole prefix as Target in a DAO message. If
       the 'L' flag is cleared and the 'R' flag is set, indicating that
       the parent provides its own address in the PIO, then the parent 
       MUST advertise that address as a DAO target.</t>

            <t>An address that is advertised as Target in a DAO message MUST
            be collocated in the same router or reachable on-link by the router
            that owns the address that is indicated in the associated Transit
            Information.</t>

            <t>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.</t>

            <t>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 DODAG Parent Address subfield 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.</t>
          </list></t>

        <t>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 ensures that the whole prefix is already
        reachable from the root. However, 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.</t>
      </section>

      <section anchor="ScheduleDAO" title="DAO Transmission Scheduling">
        <t>Because DAOs flow Upward, receiving a unicast DAO can trigger
        sending a unicast DAO to a DAO parent.</t>

        <t><list style="numbers">
            <t>On receiving a unicast DAO message with updated information,
            such as containing a Transit Information option with a new Path
            Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO
            message immediately. It SHOULD delay sending the DAO message in
            order to aggregate DAO information from other nodes for which it
            is a DAO parent.</t>

            <t>A node SHOULD delay sending a DAO message with a timer
            (DelayDAO). Receiving a DAO message starts the DelayDAO timer. DAO
            messages received while the DelayDAO timer is active do not reset
            the timer. When the DelayDAO timer expires, the node sends a
            DAO.</t>

            <t>When a node adds a node to its DAO parent set, it SHOULD
            schedule a DAO message transmission.</t>
          </list></t>

        <t>DelayDAO's value and calculation is implementation dependent. A
        default value of DEFAULT_DAO_DELAY is defined in this
        specification.</t>
      </section>

      <section title="Triggering DAO Messages">
        <t>Nodes can trigger their sub-DODAG to send DAO messages. Each node
        maintains a DAO Trigger Sequence Number (DTSN), which it communicates
        through DIO messages.</t>

        <t><list style="numbers">
            <t>If a node hears one of its DAO parents increment its DTSN, the
            node MUST schedule a DAO message transmission using rules in Sections <xref
            target="DAOBaseRules" format="counter"></xref> and <xref
            target="ScheduleDAO" format="counter"></xref>.</t>

            <t>In Non-Storing mode, if a node hears one of its DAO parents
            increment its DTSN, the node MUST increment its own DTSN.</t>
          </list></t>

        <t>In a Storing mode of operation, as part of routine routing table
        updates and maintenance, a storing node MAY increment DTSN in order to
        reliably trigger a set of DAO updates from its immediate children. In
        a Storing mode of operation, it is not necessary to trigger DAO updates
        from the entire sub-DODAG, since that state information will propagate
        hop-by-hop Up the DODAG.</t>

        <t>In a Non-Storing mode of operation, a DTSN increment will also
        cause the immediate children of a node to increment their DTSN in
        turn, triggering a set of DAO updates from the entire sub-DODAG. Typically, in a
        Non-Storing mode of operation, 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. Typically, in a Non-Storing mode of operation, all non-root
        nodes would increment their DTSN only when their parent(s) are
        observed to do so.</t>

        <t>In general, a node may trigger DAO updates according to
        implementation-specific logic, such as based on the detection of a
        Downward route inconsistency or occasionally based upon an internal
        timer.</t>

        <t>  In a storing network, selecting a proper DelayDAO for triggered DAOs 
  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
  DelayDAO inversely proportional to Rank.  Note that this suggestion
  is intended as an optimization to allow efficient aggregation (it is
  not required for correct operation in the general case).</t>
      </section>

      <section anchor="DAONonStoring" title="Non-Storing Mode">
        <t>In Non-Storing mode, RPL routes messages Downward using IP source
        routing. The following rule applies to nodes that are in Non-Storing
        mode. Storing mode has a separate set of rules, described in <xref
        target="DAOStoring"></xref>.</t>

        <t><list style="numbers">
            <t>The DODAG Parent Address subfield of a Transit Information option MUST
            contain one or more addresses. All of these addresses MUST be
            addresses of DAO parents of the sender.</t>

            <t>DAOs are sent directly to the root along a default route
            installed as part of the parent selection.</t>

            <t>When a node removes a node from its DAO parent set, it MAY
            generate a new DAO message with an updated Transit Information
            option.</t>
          </list></t>

        <t>In Non-Storing mode, a node uses DAOs to report its DAO parents to
        the DODAG root. The DODAG root can piece together a Downward route to
        a node by using DAO parent sets from each node in the route. The Path
        Sequence information may be used to detect stale DAO information. The
        purpose of this per-hop route calculation is to minimize traffic when
        DAO parents change. If nodes reported complete source routes, then on
        a DAO parent change, the entire sub-DODAG would have to send new DAOs
        to the DODAG root. Therefore, in Non-Storing mode, a node can send a
        single DAO, although it might choose to send more than one DAO message
        to each of multiple DAO parents.</t>

        <t>Nodes pack DAOs by sending a single DAO message with multiple RPL
        Target options. Each RPL Target option has its own, immediately
        following, Transit Information options.</t>
      </section>

      <section anchor="DAOStoring" title="Storing Mode">
        <t>In Storing mode, RPL routes messages Downward by the IPv6
        destination address. The following rules apply to nodes that are in
        Storing mode:</t>

        <t><list style="numbers">
            <t>The DODAG Parent Address subfield of a Transmit Information option MUST
            be empty.</t>

            <t>On receiving a unicast DAO, a node MUST compute if the DAO
            would change the set of prefixes that the node itself advertises.
            This computation SHOULD include consultation of the Path Sequence
            information in the Transit Information options associated with the
            DAO, to determine if the DAO message contains newer information
            that supersedes the information already stored at the node. If so,
            the node MUST generate a new DAO message and transmit it,
            following the rules in <xref target="ScheduleDAO"></xref>. Such a
            change includes receiving a No-Path DAO.</t>

            <t>When a node generates a new DAO, it SHOULD unicast it to each
            of its DAO parents. It MUST NOT unicast the DAO message to nodes
            that are not DAO parents.</t>

            <t>When a node removes a node from its DAO parent set, it SHOULD
            send a No-Path DAO message (<xref target="DAOOptions"></xref>) to
            that removed DAO parent to invalidate the existing route.</t>

            <t>If messages to an advertised Downward address suffer from a
            forwarding error, Neighbor Unreachable Detection (NUD), or similar
            failure, a node MAY mark the address as unreachable and generate
            an appropriate No-Path DAO.</t>
          </list></t>

        <t>DAOs advertise to which destination addresses and prefixes a node has
        routes. Unlike in Non-Storing mode, these DAOs do not communicate
        information about the routes themselves: that information is stored
        within the network and is implicit from the IPv6 source address. When
        a storing node generates a DAO, it uses the stored state of DAOs it
        has received to produce a set of RPL Target options and their
        associated Transmit Information options.</t>

        <t>Because this information is stored within each node's routing
        tables, in Storing mode, DAOs are communicated directly to DAO parents,
        who store this information.</t>
      </section>

      <section anchor="PathControl" title="Path Control">
        <t>A DAO message from a node contains one or more Target options. Each
        Target option specifies either a prefix advertised by the node, a
        prefix of addresses reachable outside the LLN, the address of a
        destination in the node's sub-DODAG, or a multicast group to which a node
        in the sub-DODAG is listening. The Path Control field of the
        Transit Information option allows nodes to request or allow for
        multiple Downward routes. A node constructs the Path Control field of
        a Transit Information option as follows:</t>

        <t><list style="numbers">
            <t>The bit width of the Path Control field MUST be equal to the
            value (PCS + 1), where PCS is specified in the control field of
            the DODAG Configuration option. Bits greater than or equal to the
            value (PCS + 1) MUST be cleared on transmission and MUST be
            ignored on reception. Bits below that value are considered
            "active" bits.</t>

            <t>The node MUST logically construct groupings of its DAO parents
            while populating the Path Control field, where each group consists
            of DAO parents of equal preference. Those groups MUST then be
            ordered according to preference, which allows for a logical
            mapping of DAO parents onto Path Control subfields (see <xref
            target="PathControlEncoding"></xref>). Groups MAY be repeated in
            order to extend over the entire bit width of the patch control
            field, but the order, including repeated groups, MUST be retained
            so that preference is properly communicated.</t>

            <t>For a RPL Target option describing a node's own address or a
            prefix outside the LLN, at least one active bit of the Path
            Control field MUST be set. More active bits of the Path Control
            field MAY be set.</t>

            <t>If a node receives multiple DAOs with the same RPL Target
            option, it MUST bitwise-OR the Path Control fields it receives.
            This aggregated bitwise-OR represents the number of Downward
            routes the prefix requests.</t>

            <t>When a node sends a DAO message to one of its DAO parents, it
            MUST select one or more of the bits that are set active in the
            subfield that is mapped to the group containing that DAO parent
            from the aggregated Path Control field. A given bit can only be
            presented as active to one parent. The DAO message it transmits to
            its parent MUST have these active bits set and all other active
            bits cleared.</t>

            <t>For the RPL Target option and DAOSequence number, the DAOs a
            node sends to different DAO parents MUST have disjoint sets of
            active Path Control bits. A node MUST NOT set the same active bit
            on DAOs to two different DAO parents.</t>

            <t>Path Control bits SHOULD be allocated according to the
            preference mapping of DAO parents onto Path Control subfields,
            such that the active Path Control bits, or groupings of bits, that
            belong to a particular Path Control subfield are allocated to DAO
            parents within the group that was mapped to that subfield.</t>

            <t>In a Non-Storing mode of operation, a node MAY pass DAOs
            through without performing any further processing on the Path
            Control field.</t>

            <t>A node MUST NOT unicast a DAO message that has no active bits
            in the Path Control field set. It is possible that, for a given
            Target option, a node does not have enough aggregate Path
            Control bits to send a DAO message containing that Target to each
            of its DAO parents, in which case those least preferred DAO
            Parents may not get a DAO message for that Target.</t>
          </list></t>

        <t>The Path Control field allows a node to bound how many Downward
        routes will be generated to it. It sets a number of bits in the Path
        Control field equal to the maximum number of Downward routes it
        prefers. At most, each bit is sent to one DAO parent; clusters of bits
        can be sent to a single DAO parent for it to divide among its own DAO
        parents.</t>

        <t>A node that provisions a DAO route for a Target that has an
        associated Path Control field SHOULD use the content of that Path
        Control field in order to determine an order of preference among
        multiple alternative DAO routes for that Target. The Path Control
        field assignment is derived from preference (of the DAO parents), as
        determined on the basis of this node's best knowledge of the
        "end-to-end" aggregated metrics in the Downward direction as per the
        Objective Function. In Non-Storing mode the root can determine the
        Downward route by aggregating the information from each received DAO,
        which includes the Path Control indications of preferred DAO
        parents.</t>

        <section anchor="PathControlExample" title="Path Control Example">
          <t>Suppose that there is an LLN operating in Storing mode that
          contains a Node N with four parents, P1, P2, P3, and P4. Let N have
          three children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such
          that there will be 8 active bits in the Path Control field:
          11111111b. Consider the following example:</t>

          <t>The Path Control field is split into four subfields, PC1
          (11000000b), PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b),
          such that those four subfields represent four different levels of
          preference per <xref target="PathControlEncoding"></xref>. The
          implementation at Node N, in this example, groups {P1, P2} to be of
          equal preference to each other and the most preferred group
          overall. {P3} is less preferred to {P1, P2}, and more preferred to
          {P4}. Let Node N then perform its Path Control mapping such that:
          <figure>
              <artwork><![CDATA[
           {P1, P2} -> PC1 (11000000b) in the Path Control field
           {P3}     -> PC2 (00110000b) in the Path Control field
           {P4}     -> PC3 (00001100b) in the Path Control field
           {P4}     -> PC4 (00000011b) in the Path Control field
]]></artwork>
            </figure>Note that the implementation repeated {P4} in order to
          get complete coverage of the Path Control field.</t>

          <t><list style="numbers">
              <t>Let C1 send a DAO containing a Target T with a Path Control
              10000000b. Node N stores an entry associating 10000000b with the
              Path Control field for C1 and Target T.</t>

              <t>Let C2 send a DAO containing a Target T with a Path Control
              00010000b. Node N stores an entry associating 00010000b with the
              Path Control field for C1 and Target T.</t>

              <t>Let C3 send a DAO containing a Target T with a Path Control
              00001100b. Node N stores an entry associating 00001100b with the
              Path Control field for C1 and Target T.</t>

              <t>At some later time, Node N generates a DAO for Target T.&nbsp; 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.&nbsp; Thus, the aggregate Path Control field
              has the active bits set as: 10011100b.</t>

              <t>Node N then distributes the aggregate Path Control bits among
              its parents P1, P2, P3, and P4 in order to prepare the DAO
              messages.</t>

              <t>P1 and P2 are eligible to receive active bits from the most
              preferred subfield (11000000b). Those bits are 10000000b in the
              aggregate Path Control field. Node N must set the bit to one of the
              two parents only. In this case, Node P1 is allocated the bit
              and gets the Path Control field 10000000b for its DAO. There are
              no bits left to allocate to Node P2; thus, Node P2 would have a
              Path Control field of 00000000b and a DAO cannot be generated to
              Node P2 since there are no active bits.</t>

              <t>The second-most preferred subfield (00110000b) has the active
              bits 00010000b. Node N has mapped P3 to this subfield. Node N
              may allocates the active bit to P3, constructing a DAO for P3
              containing Target T with a Path Control of 00010000b.</t>

              <t>The third-most preferred subfield (00001100b) has the active
              bits 00001100b. Node N has mapped P4 to this subfield. Node N
              may allocate both bits to P4, constructing a DAO for P4
              containing Target T with a Path Control of 00001100b.</t>

              <t>The least preferred subfield (00000011b) has no active bits.
              Had there been active bits, those bits would have been added to
              the Path Control field of the DAO constructed for P4.</t>

              <t>The process of populating the DAO messages destined for P1,
              P2, P3, P4 with other targets (other than T) proceeds 
              according to the aggregate Path Control fields collected for those
              targets.</t>
            </list></t>
        </section>
      </section>

      <section anchor="MulticastDAO"
               title="Multicast Destination Advertisement Messages">
        <t>A special case of DAO operation, distinct from unicast DAO
        operation, is multicast DAO operation that may be used to populate
        '1-hop' routing table entries.</t>

        <t><list style="numbers">
            <t>A node MAY multicast a DAO message to the link-local scope
            all-RPL-nodes multicast address.</t>

            <t>A multicast DAO message MUST be used only to advertise
            information about the node itself, i.e., prefixes directly
            connected to or owned by the node, such as a multicast group that
            the node is subscribed to or a global address owned by the
            node.</t>

            <t>A multicast DAO message MUST NOT be used to relay connectivity
            information learned (e.g., through unicast DAO) from another
            node.</t>

            <t>A node MUST NOT perform any other DAO-related processing on a
            received multicast DAO message; in particular, a node MUST NOT
            perform the actions of a DAO parent upon receipt of a multicast
            DAO.</t>
          </list></t>

        <t><list style="symbols">
            <t>The multicast DAO may be used to enable direct P2P
            communication, without needing the DODAG to relay the packets.</t>
          </list></t>
      </section>
    </section>

    <section anchor="SecurityMechanisms" title="Security Mechanisms">
      <t>This section describes the generation and processing of secure RPL
      messages. The high-order bit of the RPL message code identifies whether or not
      a RPL message is secure. In addition to secure versions of basic
      control messages (DIS, DIO, DAO, DAO-ACK), RPL has several messages
      that are relevant only in networks that are security enabled.</t>

      <t>Implementation complexity and size is a core concern for LLNs such
      that it may be economically or physically impossible to include
      sophisticated security provisions in a RPL implementation. Furthermore,
      many deployments can utilize link-layer or other security mechanisms to
      meet their security requirements without requiring the use of security
      in RPL.</t>

      <t>Therefore, the security features described in this document are
      OPTIONAL to implement. A given implementation MAY support a subset
      (including the empty set) of the described security features, for
      example, it could support integrity and confidentiality, but not
      signatures. An implementation SHOULD clearly specify which security
      mechanisms are supported, and it is RECOMMENDED that implementers
      carefully consider security requirements and the availability of
      security mechanisms in their network.</t>

      <section anchor="SecurityOverview" title="Security Overview">
        <t>RPL supports three security modes:</t>

        <t><list style="symbols">
            <t>Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO,
            and DAO-ACK messages, which do not have Security sections. As a
            network could be using other security mechanisms, such as
            link-layer security, unsecured mode does not imply all messages
            are sent without any protection.</t>

            <t>Preinstalled. In this security mode, RPL uses secure messages.
            To join a RPL Instance, a node must have a preinstalled key.
            Nodes use this to provide message confidentiality, integrity, and
            authenticity. A node may, using this preinstalled key, join the
            RPL network as either a host or a router.</t>

            <t>Authenticated. In this security mode, RPL uses secure messages.
            To join a RPL Instance, a node must have a preinstalled 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 the writing of this specification,
            RPL supports only symmetric algorithms: authenticated mode is
            included for the benefit of potential future cryptographic
            primitives. See <xref target="KeyInstallation"></xref>.</t>
          </list></t>

        <t>Whether or not the RPL Instance uses unsecured mode is signaled by
        whether it uses secure RPL messages. Whether a secured network uses
        the preinstalled or authenticated mode is signaled by the 'A' bit of
        the DAG Configuration option.</t>

        <t>This specification specifies CCM -- Counter with CBC-MAC (Cipher
        Block Chaining - Message Authentication Code) -- as the cryptographic
        basis for RPL security <xref target="RFC3610"></xref>. In this
        specification, CCM uses AES-128 as its underlying cryptographic
        algorithm. There are bits reserved in the Security section to specify
        other algorithms in the future.</t>

        <t>All secured RPL messages have either a MAC or a signature. Optionally, secured RPL messages also have
        encryption protection for confidentiality. Secured RPL message formats
        support both integrated encryption/authentication schemes (e.g., CCM)
        as well as schemes that separately encrypt and authenticate
        packets.</t>
      </section>

      <section anchor="SecureJoining" title="Joining a Secure Network">
        <t>RPL security assumes that a node wishing to join a secured network
        has been pre-configured with a shared key for communicating with
        neighbors and the RPL root. To join a secure RPL network, a node
        either listens for secure DIOs or triggers secure DIOs by sending a
        secure DIS. In addition to the DIO/DIS rules in <xref
        target="UpwardRoutes"></xref>, secure DIO and DIS messages have these
        rules:</t>

        <t><list style="numbers">
            <t>If sent, this initial secure DIS MUST set the Key Identifier
            Mode field to 0 (00) and MUST set the Security Level field to 1
            (001). The key used MUST be the pre-configured group key (Key Index
            0x00).</t>

            <t>When a node resets its Trickle timer in response to a secure
            DIS (<xref target="DIOTransmission"></xref>), the next DIO it
            transmits MUST be a secure DIO with the same security
            configuration as the secure DIS. If a node receives multiple
            secure DIS messages before it transmits a DIO, the secure DIO MUST
            have the same security configuration as the last DIS to which it is
            responding.</t>

            <t>When a node sends a DIO in response to a unicast secure DIS
            (<xref target="DIOTransmission"></xref>), the DIO MUST be a secure
            DIO.</t>
          </list></t>

        <t>The above rules allow a node to join a secured RPL Instance using
        the pre-configured shared key. Once a node has joined the DODAG using
        the pre-configured shared key, the 'A' bit of the Configuration option
        determines its capabilities. If the 'A' bit of the Configuration option is
        cleared, then nodes can use this preinstalled, shared key to exchange
        messages normally: it can issue DIOs, DAOs, etc.</t>

        <t>If the 'A' bit of the Configuration option is set and the RPL
        Instance is operating in authenticated mode:</t>

        <t><list style="numbers">
            <t>A node MUST NOT advertise a Rank besides INFINITE_RANK in
            secure DIOs secured with Key Index 0x00. When processing DIO
            messages secured with Key Index 0x00, a processing node MUST
            consider the advertised Rank to be INFINITE_RANK. Any other value
            results in the message being discarded.</t>

            <t>Secure DAOs using a Key Index 0x00 MUST NOT have a RPL Target
            option with a prefix besides the node's address. If a node
            receives a secured DAO message using the preinstalled, shared key
            where the RPL Target option does not match the IPv6 source
            address, it MUST discard the secured DAO message without further
            processing.</t>
          </list></t>

        <t>The above rules mean that in RPL Instances where the 'A' bit is
        set, using Key Index 0x00, a node can join the RPL Instance as a host
        but not a router. A node must communicate with a key authority to
        obtain a key that will enable it to act as a router.</t>
      </section>

      <section anchor="KeyInstallation" title="Installing Keys">
        <t>Authenticated mode requires a would-be router to dynamically
        install new keys once they have joined a network as a host. Having
        joined as a host, the node uses standard IP messaging to communicate
        with an authorization server, which can provide new keys.</t>

        <t>The protocol to obtain such keys is 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.</t>
      </section>

      <section anchor="ConsistencyChecks" title="Consistency Checks">
        <t>RPL nodes send Consistency Check (CC) messages to protect against
        replay attacks and synchronize counters.</t>

        <t><list style="numbers">
            <t>If a node receives a unicast CC message with the 'R' bit cleared,
            and it is a member of or is in the process of joining the
            associated DODAG, it SHOULD respond with a unicast CC message to
            the sender. This response MUST have the 'R' bit set, and it MUST have
            the same CC nonce, RPLInstanceID, and DODAGID fields as the message
            it received.</t>

            <t>If a node receives a multicast CC message, it MUST discard the
            message with no further processing.</t>
          </list></t>

        <t>Consistency Check messages allow nodes to issue a
        challenge-response to validate a node's current counter value. Because
        the CC nonce is generated by the challenger, an adversary replaying
        messages is unlikely to be able to generate a correct response. The
        counter in the Consistency Check response allows the challenger to
        validate the counter values it hears.</t>
      </section>

      <section anchor="SecurityCounter" title="Counters">
        <t>In the simplest case, the counter value is an unsigned integer that
        a node increments by one or more on each secured RPL transmission. The
        counter MAY represent a timestamp that has the following
        properties:</t>

        <t><list style="numbers">
            <t>The timestamp MUST be at least six octets long.</t>

            <t>The timestamp MUST be in 1024 Hz (binary millisecond)
            granularity.</t>

            <t>The timestamp start time MUST be January 1, 1970, 12:00:00AM
            UTC.</t>

            <t>If the counter represents a 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 three rules as the
            timestamp described above. If E &gt; T &lt; S, then the counter is
            invalid and a node MUST NOT generate a packet. Otherwise, the
            counter value is equal to T-S.</t>

            <t>If the counter represents such a timestamp, a node MAY set the
            'T' flag of the Security section of secured RPL packets.</t>

            <t>If the Counter field does not present such a timestamp, then a
            node MUST NOT set the 'T' flag.</t>

            <t>If a node does not have a local timestamp that satisfies the
            above requirements, it MUST ignore the 'T' flag.</t>
          </list></t>

        <t>If a node supports such timestamps and it receives a message with
        the 'T' flag set, it MAY apply the temporal check on the received
        message described in <xref target="TemporalCheck"></xref>. If a node
        receives a message without the 'T' flag set, it MUST NOT apply this
        temporal check. A node's security policy MAY, for application reasons,
        include rejecting all messages without the 'T' flag set.</t>

        <t>The 'T' flag is present because many LLNs today already maintain
        global time synchronization at sub-millisecond granularity for
        security, application, and other reasons. Allowing RPL to leverage
        this existing functionality when present greatly simplifies solutions
        to some security problems, such as delay protection.</t>
      </section>

      <section title="Transmission of Outgoing Packets">
        <t>Given an outgoing RPL control packet and the required security
        protection, this section describes how RPL generates the secured
        packet to transmit. It also describes the order of cryptographic
        operations to provide the required protection.</t>

        <t>The requirement for security protection and the level of security
        to be applied to an outgoing RPL packet shall be determined by the
        node's security policy database. The configuration of this security
        policy database for outgoing packet processing is implementation
        specific.</t>

        <t>Where secured RPL messages are to be transmitted, a RPL node MUST
        set the Security section (T, Sec, KIM, and LVL) in the outgoing RPL
        packet to describe the protection level and security settings that are
        applied (see <xref target="RPLSecurityFields"></xref>). The Security
        subfield bit of the RPL Message Code field MUST be set to indicate the
        secure RPL message.</t>

        <t>The counter value used in constructing the AES-128 CCM nonce (<xref
        target="CCMNonce"></xref>) to secure the outgoing packet MUST be an
        increment of the last counter transmitted to the particular
        destination address.</t>

        <t>Where security policy specifies the application of delay
        protection, the Timestamp counter used in constructing the CCM nonce
        to secure the outgoing packet MUST be incremented according to the
        rules in <xref target="SecurityCounter"></xref>. Where a Timestamp
        counter is applied (indicated with the 'T' flag set), the locally
        maintained Timestamp counter MUST be included as part of the transmitted
        secured RPL message.</t>

        <t>The cryptographic algorithm used in securing the outgoing packet
        shall be specified by the node's security policy database and MUST be
        indicated in the value of the Sec field set within the outgoing
        message.</t>

        <t>The security policy for the outgoing packet shall determine the
        applicable KIM and Key Identifier specifying the
        security key to be used for the cryptographic packet processing,
        including the optional use of signature keys (see <xref
        target="RPLSecurityFields"></xref>). The security policy will also
        specify the algorithm (Algorithm) and level of protection (Level) in
        the form of authentication or authentication and encryption, and
        potential use of signatures that shall apply to the outgoing
        packet.</t>

        <t>Where encryption is applied, a node MUST replace the original
        packet payload with that payload encrypted using the security
        protection, key, and CCM nonce specified in the Security section of
        the packet.</t>

        <t>All secured RPL messages include integrity protection. In
        conjunction with the security algorithm processing, a node derives
        either a MAC or signature that MUST be
        included as part of the outgoing secured RPL packet.</t>
      </section>

      <section title="Reception of Incoming Packets">
        <t>This section describes the reception and processing of a secured
        RPL packet. Given an incoming secured RPL packet, where the Security
        subfield bit of the RPL Message Code field is set, this section
        describes how RPL generates an unencrypted variant of the packet and
        validates its integrity.</t>

        <t>The receiver uses the RPL security control fields to determine the
        necessary packet security processing. If the described level of
        security for the message type and originator 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).</t>

        <t>Where the message Security Level (LVL) indicates an encrypted RPL
        message, the node uses the key information identified through the KIM
        field as well as the CCM nonce as input to the message payload
        decryption processing. The CCM nonce shall be derived from the message
        Counter field and other received and locally maintained information
        (see <xref target="SecurityNonce"></xref>). The plaintext message
        contents shall be obtained by invoking the inverse cryptographic mode
        of operation specified by the Sec field of the received packet.</t>

        <t>The receiver shall use the CCM nonce and identified key information
        to check the integrity of the incoming packet. If the integrity check
        fails against the received MAC, a node
        MUST discard the packet.</t>

        <t>If the received message has an initialized (zero value) counter
        value and the receiver has an incoming counter currently maintained
        for the originator of the message, the receiver MUST initiate a
        counter resynchronization by sending a Consistency Check response
        message (see <xref target="ConsistencyCheck"></xref>) to the message
        source. The Consistency Check response message shall be protected with
        the current full outgoing counter maintained for the particular node
        address. That outgoing counter will be included within the security
        section of the message while the incoming counter will be included
        within the Consistency Check message payload.</t>

        <t>Based on the specified security policy, a node MAY apply replay
        protection for a received RPL message. The replay check SHOULD be
        performed before the authentication of the received packet. The
        counter, as obtained from the incoming packet, shall be compared against
        the watermark of the incoming counter maintained for the given
        origination node address. If the received message counter value is
        non-zero and less than the maintained incoming counter watermark, a
        potential packet replay is indicated and the node MUST discard the
        incoming packet.</t>

        <t>If delay protection is specified as part of the incoming packet
        security policy checks, the Timestamp counter is used to validate the
        timeliness of the received RPL message. If the incoming message
        Timestamp counter value indicates a message transmission time prior to
        the locally maintained transmission time counter for the originator
        address, a replay violation is indicated and the node MUST discard the
        incoming packet. If the received Timestamp counter value indicates a
        message transmission time that is earlier than the Current time less
        the acceptable packet delay, a delay violation is indicated and the
        node MUST discard the incoming packet.</t>

        <t>Once a message has been decrypted, where applicable, and has
        successfully passed its integrity check, replay check, and optionally delay-protection checks, the node can update its local security information,
        such as the source's expected counter value for replay comparison.</t>

        <t>A node MUST NOT update its security information on receipt of a
        message that fails security policy checks or other applied integrity,
        replay, or delay checks.</t>

        <section anchor="TemporalCheck" title="Timestamp Key Checks">
          <t>If the 'T' flag of a message is set and a node has a local
          timestamp that follows the requirements in <xref
          target="SecurityCounter"></xref>, then a node MAY check the temporal
          consistency of the message. The node computes the transmit time of
          the message by adding the counter value to the start time of the
          associated key. If this transmit time is past the end time of the
          key, the node MAY discard the message without further processing. If
          the transmit time is too far in the past or future compared to the
          local time on the receiver, it MAY discard the message without
          further processing.</t>
        </section>
      </section>

      <section title="Coverage of Integrity and Confidentiality">
        <t>For a RPL ICMPv6 message, the entire packet is within the scope of
        RPL security.</t>

        <t>MACs 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 <xref
        target="RFC4302"></xref> (IPsec Authenticated Header). MAC and
        signature calculations are performed before any compression that lower
        layers may apply.</t>

        <t>When a RPL ICMPv6 message is encrypted, encryption starts at the
        first byte after the Security section and continues to the last byte
        of the packet. The IPv6 header, ICMPv6 header, and RPL message up to
        the end of the Security section are not encrypted, as they are needed
        to correctly decrypt the packet.</t>

        <t>For example, a node sending a message with LVL=1, KIM=0, and
        Algorithm=0 uses the CCM algorithm <xref target="RFC3610"></xref> to
        create a packet with attributes ENC-MAC-32: it encrypts the packet and
        appends a 32-bit MAC. The block cipher key is determined by the Key
        Index. The CCM nonce is computed as described in <xref
        target="SecurityNonce"></xref>; the message to authenticate and
        encrypt is the RPL message starting at the first byte after the
        Security section and ends with the last byte of the packet. The
        additional authentication data starts with the beginning of the IPv6
        header and ends with the last byte of the RPL Security section.</t>
      </section>

      <section anchor="CryptoMode" title="Cryptographic Mode of Operation">
        <t>The cryptographic mode of operation described in this specification
        (Algorithm = 0) is based on CCM and the block-cipher AES-128 <xref
        target="RFC3610"></xref>. This mode of operation is widely supported
        by existing implementations. CCM mode requires a nonce (CCM
        nonce).</t>

        <section anchor="SecurityNonce" title="CCM Nonce">
          <t>A RPL node constructs a CCM nonce as follows:</t>

          <t><figure anchor="CCMNonce" title="CCM Nonce">
              <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Source Identifier                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Counter                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |KIM|Resvd| LVL |
    +-+-+-+-+-+-+-+-+                                                

        ]]></artwork>
            </figure></t>

          <t><list hangIndent="24" style="hanging">
              <t hangText="Source Identifier:">8 bytes. Source Identifier is
              set to the logical identifier of the originator of the protected
              packet.</t>

              <t hangText="Counter:">4 bytes. Counter is set to the
              (uncompressed) value of the corresponding field in the Security
              option of the RPL control message.</t>

              <t hangText="Key Identifier Mode (KIM):">2 bits. KIM is set to
              the value of the corresponding field in the Security option of
              the RPL control message.</t>

              <t hangText="Security Level (LVL):">3 bits. Security Level is
              set to the value of the corresponding field in the Security
              option of the RPL control message.</t>
            </list></t>

          <t>Unassigned bits of the CCM nonce are reserved. They MUST be set
          to zero when constructing the CCM nonce.</t>

          <t>All fields of the CCM nonce are represented in
          most significant octet and most significant bit first order.</t>
        </section>

        <section anchor="Signatures" title="Signatures">
          <t>If the KIM indicates the use of
          signatures (a value of 3), then a node appends a signature to the
          data payload of the packet. The Security Level (LVL) field describes
          the length of this signature.</t>

          <t>The signature scheme in RPL for Security Mode 3 is an
          instantiation of the RSA algorithm (RSASSA-PSS) as defined in
          Section 8.1 of <xref target="RFC3447"></xref>. As public key, it uses
          the pair (n,e), where n is a 2048&nbhy;bit or 3072-bit RSA modulus and
          where e=2^{16}+1. It uses CCM mode <xref target="RFC3610"></xref> as
          the encryption scheme with M=0 (as a stream-cipher). Note that
          although <xref target="RFC3610"></xref> disallows the CCM mode with
          M=0, RPL explicitly allows the CCM mode with M=0 when used in
          conjunction with a signature, because the signature provides
          sufficient data authentication. Here, the CCM mode with M=0 is
          specified as in <xref target="RFC3610"></xref>, but where the M'
          field in Section 2.2 MUST be set to 0. It uses the SHA-256 hash
          function specified in Section 6.2 of <xref target="FIPS180"></xref>.
          It uses the message encoding rules of Section 8.1 of <xref
          target="RFC3447"></xref>.</t>

          <t>Let 'a' be a concatenation of a 6-byte representation of
          counter and the message header. The packet payload is the
          right-concatenation of packet data 'm' and the signature 's'. This
          signature scheme is invoked with the right-concatenation of the
          message parts a and m, whereas the signature verification is invoked
          with the right-concatenation of the message parts a and m and with
          signature s.</t>

          <t>RSA signatures of this form provide sufficient protection for RPL
          networks. If needed, alternative signature schemes that produce
          more concise signatures is out of scope for this specification and
          may be the subject of a future specification.</t>

          <t>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.</t>
        </section>
      </section>
    </section>

    <section anchor="forwarding"
             title="Packet Forwarding and Loop Avoidance/Detection">
      <section anchor="PacketForwarding"
               title="Suggestions for Packet Forwarding">
        <t>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 RPL.</t>

        <t>When forwarding a packet to a destination, precedence is given to
        selection of a next-hop successor as follows:</t>

        <t><list style="numbers">
            <t>This specification only covers how a successor is selected from
            the DODAG Version that matches the RPLInstanceID marked in the
            IPv6 header of the packet being forwarded. Routing outside the
            instance can be done as long as additional rules are put in place
            such as strict ordering of instances and routing protocols to
            protect against loops. Such rules may be defined in a separate
            document.</t>

            <t>If a local administrative preference favors a route that has
            been learned from a different routing protocol than RPL, then use
            that successor.</t>

            <t>If the packet header specifies a source route by including an
            RH4 header as specified in <xref
            target="RFC6554"></xref>, then use that
            route. If the node fails to forward the packet with that specified
            source route, then that packet should be dropped. The node MAY log
            an error. The node may send an ICMPv6 error in Source Routing
            Header message to the source of the packet (see <xref
            target="ICMPv6ErrSrcRte"></xref>).</t>

            <t>If there is an entry in the routing table matching the
            destination that has been learned from a multicast destination
            advertisement (e.g., the destination is a one-hop neighbor), then
            use that successor.</t>

            <t>If there is an entry in the routing table matching the
            destination that has been learned from a unicast destination
            advertisement (e.g., the destination is located Down the
            sub-DODAG), then use that successor. If there are DAO Path Control
            bits associated with multiple successors, then consult the Path
            Control bits to order the successors by preference when choosing.
            If, for a given DAO Path Control bit, multiple successors are
            recorded as having asserted that bit, precedence should be given
            to the successor who most recently asserted that bit.</t>

            <t>If there is a DODAG Version offering a route to a prefix
            matching the destination, then select one of those DODAG parents
            as a successor according to the OF and routing metrics.</t>

            <t>Any other as-yet-unattempted DODAG parent may be chosen for the
            next attempt to forward a unicast packet when no better match
            exists.</t>

            <t>Finally, the packet is dropped. ICMP Destination Unreachable MAY
            be invoked (an inconsistency is detected).</t>
          </list></t>

        <t>Hop Limit MUST be decremented when forwarding per <xref
        target="RFC2460"></xref>.</t>

        <t>Note that the chosen successor MUST NOT be the neighbor that was
        the predecessor of the packet (split horizon), except in the case
        where it is intended for the packet to change from an Upward to a
        Downward 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.</t>
      </section>

      <section anchor="loopdetect" title="Loop Avoidance and Detection">
        <t>RPL loop avoidance mechanisms are kept simple and designed to
        minimize churn and states. Loops may form for a number of reasons,
        e.g., control packet loss. RPL includes a reactive loop detection
        technique that protects from meltdown and triggers repair of broken
        paths.</t>

        <t>RPL loop detection uses RPL Packet Information that is transported
        within the data packets, relying on an external mechanism such as
        <xref target="RFC6553"></xref> that places in the RPL
        Packet Information in an IPv6 Hop-by-Hop option header.</t>

        <t>The content of RPL Packet Information is defined as follows:</t>

        <t><list hangIndent="24" style="hanging">
            <t hangText="Down 'O':">1-bit flag indicating whether the packet
            is expected to progress Up or Down. A router sets the 'O' flag
            when the packet is expected to progress Down (using DAO routes),
            and clears it when forwarding toward the DODAG root (to a node
            with a lower Rank). A host or RPL leaf node MUST set the 'O' flag
            to 0.</t>

            <t hangText="Rank-Error 'R':">1-bit flag indicating whether a Rank
            error was detected. A Rank error is detected when there is a
            mismatch in the relative Ranks and the direction as indicated in
            the 'O' bit. A host or RPL leaf node MUST set the 'R' bit to
            0.</t>

            <t hangText="Forwarding-Error 'F':">1-bit flag indicating that
            this node cannot forward the packet further towards the
            destination. The 'F' bit might be set by a child node that does
            not have a route to destination for a packet with the Down 'O' bit
            set. A host or RPL leaf node MUST set the 'F' bit to 0.</t>

            <t hangText="RPLInstanceID:">8-bit field indicating the DODAG
            instance along which the packet is sent.</t>

            <t hangText="SenderRank:">16-bit field set to zero by the source
            and to DAGRank(rank) by a router that forwards inside the RPL
            network.</t>
          </list></t>

        <section anchor="sno" title="Source Node Operation">
          <t>If the source is aware of the RPLInstanceID that is preferred for
          the packet, then it MUST set the RPLInstanceID field associated with
          the packet accordingly; otherwise, it MUST set it to the
          RPL_DEFAULT_INSTANCE.</t>
        </section>

        <section title="Router Operation">
          <section anchor="RPLinstanceforwarding" title="Instance Forwarding">
            <t>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.</t>

            <t>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 the 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.</t>

            <t>A router that forwards a packet outside the RPL network MUST
            remove the RPL Packet Information.</t>

            <t>When a router receives a packet that specifies a given
            RPLInstanceID and the node can forward the packet along the DODAG
            associated to that instance, then the router MUST do so and leave
            the RPLInstanceID value unchanged.</t>

            <t>If any node cannot forward a packet along the DODAG associated
            with the RPLInstanceID, then the node SHOULD discard the packet and
            send an ICMP error message.</t>
          </section>

          <section anchor="LoopDetectInconsistency"
                   title="DAG Inconsistency Loop Detection">
            <t>The DODAG is inconsistent if the direction of a packet does not
            match the Rank relationship. A receiver detects an inconsistency
            if it receives a packet with either: <list>
                <t>the 'O' bit set (to Down) from a node of a higher Rank.</t>

                <t>the 'O' bit cleared (for Up) from a node of a lower
                Rank.</t>
              </list></t>

            <t>When the DODAG root increments the DODAGVersionNumber, a
            temporary Rank discontinuity may form between the next DODAG
            Version and the prior DODAG Version, in particular, if nodes are
            adjusting their Rank in the next DODAG Version and deferring their
            migration into the next DODAG Version. A router that is still a
            member of the prior DODAG Version may choose to forward a packet
            to a (future) parent that is in the next DODAG Version. In some
            cases, this could cause the parent to detect an inconsistency
            because the Rank-ordering in the prior DODAG Version is not
            necessarily the same as in the next DODAG Version, and the packet
            may be judged not to be making forward progress. If the sending
            router is aware that the chosen successor has already joined the
            next DODAG Version, then the sending router MUST update the
            SenderRank to INFINITE_RANK as it forwards the packets across the
            discontinuity into the next DODAG Version in order to avoid a
            false detection of Rank inconsistency.</t>

            <t>One inconsistency along the path is not considered a critical
            error and the packet may continue. However, a second detection along
            the path of the same packet should not occur and the packet MUST be
            dropped.</t>

            <t>This process is controlled by the Rank-Error bit associated
            with the packet. When an inconsistency is detected on a packet, if
            the Rank-Error bit was not set, then the Rank-Error bit is set. If
            it was set the packet MUST be discarded and the Trickle timer MUST
            be reset.</t>
          </section>

          <section anchor="DAOInconsistencyDetection"
                   title="DAO Inconsistency Detection and Recovery">
            <t>DAO inconsistency loop recovery is a mechanism that applies to
            Storing mode of operation only.</t>

            <t>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 <xref
            target="RFC4443"></xref>. 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.</t>

            <t>A DAO inconsistency happens when a router has a Downward route
            that was previously learned from a DAO message via a child, but
            that Downward route is not longer valid in the child, e.g., because
            that related state in the child has been cleaned up. With DAO
            inconsistency loop recovery, a packet can be used to recursively
            explore and clean up the obsolete DAO states along a sub-DODAG.</t>

            <t>In a general manner, a packet that goes Down should never go Up
            again. If DAO inconsistency loop recovery is applied, then the
            router SHOULD send the packet back to the parent that passed it
            with the Forwarding-Error 'F' bit set and the 'O' bit left
            untouched. Otherwise, the router MUST silently discard the
            packet.</t>

            <t>Upon receiving a packet with a Forwarding-Error bit set, the
            node MUST remove the routing states that caused forwarding to that
            neighbor, clear the Forwarding-Error bit, and attempt to send the
            packet again. The packet may be sent to an alternate neighbor,
            after the expiration of a user-configurable implementation-specific timer. If that alternate neighbor still has an
            inconsistent DAO state via this node, the process will recurse,
            this node will set the Forwarding-Error 'F' bit, and the routing
            state in the alternate neighbor will be cleaned up as well.</t>
          </section>
        </section>
      </section>
    </section>

    <section anchor="MulticastOperation" title="Multicast Operation">
      <t>This section describes a multicast routing operation over an IPv6 RPL
  network and, specifically, how unicast DAOs can be used to relay group
  registrations.  The same DODAG construct can be used to forward unicast
  and multicast traffic. This section is limited to a description of how
  group registrations may be exchanged and how the forwarding
  infrastructure operates. It does not provide a full description of
  multicast within an LLN and, in particular, does not describe the
  generation of DODAGs specifically targeted at multicast or the
  details of operating RPL for multicast -- that will be the subject of
  further specifications.</t>
 
<t>  The multicast group registration uses DAO messages that are identical
  to unicast except for the type of address that is transported.  The
  main difference is that the multicast traffic going down is copied to
  all the children that have registered with the multicast group, whereas
  unicast traffic is passed to one child only.</t>

      <t>Nodes that support the RPL Storing mode of operation SHOULD also
      support multicast DAO operations as described below. Nodes that only
      support the Non-Storing mode of operation are not expected to support
      this section.</t>

      <t>The multicast operation is controlled by the MOP field in the DIO.
      <list style="symbols">
          <t>If the MOP field requires multicast support, then a node that
          joins the RPL network as a router must operate as described in this
          section for multicast signaling and forwarding within the RPL
          network. A node that does not support the multicast operation
          required by the MOP field can only join as a leaf.</t>

          <t>If the MOP field does not require multicast support, then
          multicast is handled by some other way that is out of scope for this
          specification. (Examples may include a series of unicast copies or
          limited-scope flooding).</t>
        </list></t>

      <t>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-DODAGs if the transmission fails over
      that link. Alternatively, the router might select copying additional
      parents as it would do for DAO messages advertising unicast
      destinations; in which case, there might be duplicates that the router
      will need to prune.</t>

      <t>As a result, multicast routing states are installed in each router on
      the way from the listeners to the DODAG root, enabling the root to copy
      a multicast packet to all its children routers that had issued a DAO
      message including a Target option for that multicast group.</t>

      <t>For a multicast packet sourced from inside the DODAG, the packet is
      passed to the preferred parents, and if that fails, then to the
      alternates in the DODAG. The packet is also copied to all the registered
      children, except for the one that passed the packet. Finally, if there
      is a listener in the external infrastructure, then the DODAG root has to
      further propagate the packet into the external infrastructure.</t>

      <t>As a result, the DODAG root acts as an automatic proxy Rendezvous
      Point for the RPL network and as source towards the non-RPL domain for
      all multicast flows started in the RPL domain. So, regardless of whether
      the root is actually attached to a non-RPL domain, and regardless of
      whether the DODAG is grounded or floating, the root can serve inner
      multicast streams at all times.</t>
    </section>

    <section anchor="MaintenanceRoutingAdjacency"
             title="Maintenance of Routing Adjacency">
      <t>The selection of successors, along the default paths Up along the
      DODAG, or along the paths learned from destination advertisements Down
      along the DODAG, leads to the formation of routing adjacencies that
      require maintenance.</t>

      <t>In IGPs, such as OSPF <xref target="RFC4915"></xref> or IS-IS <xref
      target="RFC5120"></xref>, the maintenance of a routing adjacency
      involves the use of keepalive mechanisms (Hellos) or other protocols
      such as the <xref target="RFC5881"> Bidirectional Forwarding Detection (BFD)
      </xref>  and the MANET <xref target="RFC6130">
      Neighborhood Discovery Protocol (NHDP)</xref>. 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.</t>

      <t>By contrast with those routing protocols, RPL does not define any
      keepalive 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 keepalives). 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.</t>

      <t>Example reactive mechanisms that can be used include: <list>
          <t>The <xref target="RFC4861"> Neighbor Unreachability Detection
          </xref> mechanism.</t>

          <t><xref target="RFC5184">Layer 2 triggers</xref> derived from
          events such as association states and L2 acknowledgements.</t>
        </list></t>
    </section>

    <section anchor="OFGuide" title="Guidelines for Objective Functions">
      <t>An Objective Function (OF), in conjunction with routing metrics and
      constraints, allows for the selection of a DODAG to join, and a number
      of peers in that DODAG as parents. The OF is used to compute an ordered
      list of parents. The OF is also responsible to compute the Rank of the
      device within the DODAG Version.</t>

      <t>The Objective Function is indicated in the DIO message using an
      Objective Code Point (OCP), and it indicates the method that must be used
      to construct the DODAG. The Objective Code Points are specified in <xref
      target="RFC6552"></xref> and related companion
      specifications.</t>

      <section title="Objective Function Behavior">
        <t>Most Objective Functions are expected to follow the same abstract
        behavior at a node: <list style="symbols">
            <t>The parent selection is triggered each time an event indicates
            that a potential next-hop information is updated. This might
            happen upon the reception of a DIO message, a timer elapse, all
            DODAG parents are unavailable, or a trigger indicating that the
            state of a candidate neighbor has changed.</t>

            <t>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 might not match a required criterion for an Objective
            Function, for instance, a degree of security. As a result, some
            interfaces might be completely excluded from the computation, for
            example, if those interfaces cannot satisfy some advertised
            constraints, while others might be more or less preferred.</t>

            <t>An OF scans all the candidate neighbors on the possible
            interfaces to check whether they can act as a router for a DODAG.
            There might be many of them and a candidate neighbor might
            need to pass some validation tests before it can be used. In
            particular, some link layers require experience on the activity
            with a router to enable the router as a next hop.</t>

            <t>An OF computes 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.<list
                style="symbols">
                <t>The increase in Rank must be at least
                MinHopRankIncrease.</t>

                <t>To keep loop avoidance and metric optimization in
                alignment, the increase in Rank should reflect any increase in
                the metric value. For example, with a purely additive metric,
                such as ETX, the increase in Rank can be made proportional to
                the increase in the metric.</t>

                <t>Candidate neighbors that would cause the Rank of the node
                to increase are not considered for parent selection.</t>
              </list></t>

            <t>Candidate neighbors that advertise an OF incompatible with the
            set of OFs specified by the policy functions are ignored.</t>

            <t>As it scans all the candidate neighbors, the OF keeps the
            current best parent and compares its capabilities with the current
            candidate neighbor. The OF defines a number of tests that are
            critical to reach the objective. A test between the routers
            determines an order relation. <list style="symbols">
                <t>If the routers are equal for that relation, then the next
                test is attempted between the routers,</t>

                <t>Else the best of the two routers becomes the current best
                parent, and the scan continues with the next candidate
                neighbor.</t>

                <t>Some OFs may include a test to compare the Ranks that would
                result if the node joined either router.</t>
              </list></t>

            <t>When the scan is complete, the preferred parent is elected and
            the node's Rank is computed as the preferred parent Rank plus the
            step in Rank with that parent.</t>

            <t>Other rounds of scans might be necessary to elect alternate
            parents. In the next rounds: <list style="symbols">
                <t>Candidate neighbors that are not in the same DODAG are
                ignored.</t>

                <t>Candidate neighbors that are of greater Rank than the node
                are ignored.</t>

                <t>Candidate neighbors of an equal Rank to the node are
                ignored for parent selection.</t>

                <t>Candidate neighbors of a lesser Rank than the node are
                preferred.</t>
              </list></t>
          </list></t>
      </section>
    </section>

    <section anchor="NDGuide"
             title="Suggestions for Interoperation with Neighbor Discovery">
      <t>This specification directly borrows the Prefix Information Option
      (PIO) and the Route Information Option (RIO) from IPv6 ND. It is
      envisioned that, as future specifications build on this base, there may
      be additional cause to leverage parts of IPv6 ND. This section provides
      some suggestions for future specifications.</t>

      <t>First and foremost, RPL is a routing protocol. One should take great
      care to preserve architecture when mapping functionalities between RPL
      and ND. RPL is for routing only. That said, there may be persuading
      technical reasons to allow for sharing options between RPL and IPv6 ND
      in a particular implementation/deployment.</t>

      <t>In general, the following guidelines apply: <list style="symbols">
          <t>RPL Type codes must be allocated from the RPL Control Message
          options registry.</t>

          <t>RPL Length fields must be expressed in units of single octets, as
          opposed to ND Length fields, which are expressed in units of 8 octets.</t>

          <t>RPL options are generally not required to be aligned to 8-octet
          boundaries.</t>

          <t>When mapping/transposing an IPv6 ND option for redistribution as
          a RPL option, any padding octets should be removed when possible.
          For example, the Prefix Length field in the PIO is sufficient to
          describe the length of the Prefix field. When mapping/transposing a
          RPL option for redistribution as an IPv6 ND option, any such padding
          octets should be restored. This procedure must be unambiguous.</t>
        </list></t>
    </section>

    <section anchor="InteroperationGuide"
             title="Summary of Requirements for Interoperable Implementations">
      <t>This section summarizes basic interoperability and references
      normative text for RPL implementations operating in one of three major
      modes. Implementations are expected to support either no Downward
      routes, Non-Storing mode only, or Storing mode only. A fourth mode,
      operation as a leaf, is also possible.</t>

      <t>Implementations conforming to this specification may contain
      different subsets of capabilities as appropriate to the application
      scenario. It is important for the implementer to support a level of
      interoperability consistent with that required by the application
      scenario. To this end, further guidance may be provided beyond this
      specification (e.g., as applicability statements), and it is understood
      that in some cases such further guidance may override portions of this
      specification.</t>

      <section title="Common Requirements">
        <t>In a general case, the greatest level of interoperability may be
        achieved when all of the nodes in a RPL LLN are cooperating to use the
        same MOP, OF, metrics, and constraints, and are thus able to act as
        RPL routers. When a node is not capable of being a RPL router, it may be
        possible to interoperate in a more limited manner as a RPL leaf.</t>

        <t>All RPL implementations need to support the use of RPL Packet
        Information transported within data packets (<xref
        target="loopdetect"></xref>). One such mechanism is described in <xref
        target="RFC6553"></xref>.</t>

        <t>RPL implementations will need to support the use of Neighbor
        Unreachability Detection (NUD), or an equivalent mechanism, to
        maintain the reachability of neighboring RPL nodes (<xref
        target="parentset"></xref>). Alternate mechanisms may be optimized to
        the constrained capabilities of the implementation, such as hints from
        the link layer.</t>

        <t>This specification provides means to obtain a PIO and thus form an
        IPv6 address. When that mechanism is used, it may be necessary to
        perform address resolution and duplicate address detection through an
        external process, such as IPv6 ND <xref target="RFC4861"></xref> or
        6LoWPAN ND <xref target="6LOWPAN-ND"></xref>.</t>
      </section>

      <section title="Operation as a RPL Leaf Node (Only)">
        <t><?rfc subcompact="yes"?><list style="symbols">
            <t>An implementation of a leaf node (only) does not ever
            participate as a RPL router. Interoperable implementations of leaf
            nodes behave as summarized in <xref
            target="OperationAsALeaf"></xref>.</t>

            <t>Support of a particular MOP encoding is not required, although
            if the leaf node sends DAO messages to set up Downward routes, the
            leaf node should do so in a manner consistent with the mode of
            operation indicated by the MOP.</t>

            <t>Support of a particular OF is not required.</t>

            <t>In summary, a leaf node does not generally issue DIO
            messages, it may issue DAO and DIS messages. A leaf node accepts
            DIO messages though it generally ignores DAO and DIS messages.</t>
          </list><?rfc subcompact="no"?></t>
      </section>

      <section title="Operation as a RPL Router">
        <t>If further guidance is not available then a RPL router
        implementation MUST at least support the metric-less OF0 <xref
        target="RFC6552"></xref>.</t>

        <t>For consistent operation a RPL router implementation needs to
        support the MOP in use by the DODAG.</t>

        <t>All RPL routers will need to implement Trickle <xref
        target="RFC6206"></xref>.</t>

        <section title="Support for Upward Routes (Only)">
          <t>An implementation of a RPL router that supports only Upward
          routes supports the following: <?rfc subcompact="yes"?> <list
              style="symbols">
              <t>Upward routes (<xref target="UpwardRoutes"></xref>)</t>

              <t>MOP encoding 0 (<xref target="MOPRegistry"></xref>)</t>

              <t>In summary, DIO and DIS messages are issued, and DAO
              messages are not issued. DIO and DIS messages are accepted, and
              DAO messages are ignored.</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="Support for Upward Routes and Downward Routes in Non-Storing Mode">
          <t>An implementation of a RPL router that supports Upward routes and
          Downward routes in Non-Storing mode supports the following: <?rfc subcompact="yes"?>
          <list style="symbols">
              <t>Upward routes (<xref target="UpwardRoutes"></xref>)</t>

              <t>Downward routes (Non-Storing) (<xref
              target="DownwardRoutes"></xref>)</t>

              <t>MOP encoding 1 (<xref target="MOPRegistry"></xref>)</t>

              <t>Source-routed Downward traffic (<xref
              target="RFC6554"></xref>)</t>

              <t>In summary, DIO and DIS messages are issued, and DAO
              messages are issued to the DODAG root. DIO and DIS messages are
              accepted, and DAO messages are ignored by nodes other than DODAG
              roots. Multicast is not supported through the means described in
              this specification, though it may be supported through some
              alternate means.</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="Support for Upward Routes and Downward Routes in Storing Mode">
          <t>An implementation of a RPL router that supports Upward routes and
          Downward routes in Storing mode supports the following: <?rfc subcompact="yes"?>
          <list style="symbols">
              <t>Upward routes (<xref target="UpwardRoutes"></xref>)</t>

              <t>Downward routes (Storing) (<xref
              target="DownwardRoutes"></xref>)</t>

              <t>MOP encoding 2 (<xref target="MOPRegistry"></xref>)</t>

              <t>In summary, DIO, DIS, and DAO messages are issued. DIO,
              DIS, and DAO messages are accepted. Multicast is not supported
              through the means described in this specification, though it may
              be supported through some alternate means.</t>
            </list><?rfc subcompact="no"?></t>

          <section title="Optional Support for Basic Multicast Scheme">
            <t>A Storing mode implementation may be enhanced with basic
            multicast support through the following additions: <?rfc subcompact="yes"?>
            <list style="symbols">
                <t>Basic Multicast Support (<xref
                target="MulticastOperation"></xref>)</t>

                <t>MOP encoding 3 (<xref target="MOPRegistry"></xref>)</t>
              </list><?rfc subcompact="no"?></t>
          </section>
        </section>
      </section>

      <section title="Items for Future Specification">
        <t>A number of items are left to future specification, including but
        not limited to the following: <?rfc subcompact="yes"?> <list style="symbols">
            <t>How to attach a non-RPL node such as an IPv6 host, e.g., to
            consistently distribute at least PIO material to the attached
            node.</t>

            <t>How to obtain authentication material in support if
            authenticated mode is used (<xref
            target="KeyInstallation"></xref>).</t>

            <t>Details of operation over multiple simultaneous instances.</t>

            <t>Advanced configuration mechanisms, such as the provisioning of
            RPLInstanceIDs, parameterization of Objective Functions, and
            parameters to control security. (It is expected that such
            mechanisms might extend the DIO as a means to disseminate
            information across the DODAG).</t>
          </list><?rfc subcompact="no"?></t>
      </section>
    </section>

    <section title="RPL Constants and Variables">
      <t>The following is a summary of RPL constants and variables:</t>

      <t><list hangIndent="24" style="hanging">
          <t hangText="BASE_RANK:">This is the Rank for a virtual root that
          might be used to coordinate multiple roots. BASE_RANK has a value of
          0.</t>

          <t hangText="ROOT_RANK:">This is the Rank for a DODAG root. ROOT_RANK
          has a value of MinHopRankIncrease (as advertised by the DODAG root),
          such that DAGRank(ROOT_RANK) is 1.</t>

          <t hangText="INFINITE_RANK:">This is the constant maximum for the
          Rank. INFINITE_RANK has a value of 0xFFFF.</t>

          <t hangText="RPL_DEFAULT_INSTANCE:">This is the RPLInstanceID that is
          used by this protocol by a node without any overriding policy.
          RPL_DEFAULT_INSTANCE has a value of 0.</t>

          <t hangText="DEFAULT_PATH_CONTROL_SIZE:">This is the default value
          used to configure PCS in the DODAG Configuration option, which
          dictates the number of significant bits in the Path Control field of
          the Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a
          value of 0. This configures the simplest case limiting the fan-out
          to 1 and limiting a node to send a DAO message to only one
          parent.</t>

          <t hangText="DEFAULT_DIO_INTERVAL_MIN:">This is the default value
          used to configure Imin for the DIO Trickle timer.
          DEFAULT_DIO_INTERVAL_MIN has a value of 3. This configuration
          results in Imin of 8 ms.</t>

          <t hangText="DEFAULT_DIO_INTERVAL_DOUBLINGS:">This is the default
          value used to configure Imax for the DIO Trickle timer.
          DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This configuration
          results in a maximum interval of 2.3 hours.</t>

          <t hangText="DEFAULT_DIO_REDUNDANCY_CONSTANT:">This is the default
          value used to configure k for the DIO Trickle timer.
          DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This
          configuration is a conservative value for Trickle suppression
          mechanism.</t>

          <t hangText="DEFAULT_MIN_HOP_RANK_INCREASE:">This is the default
          value of MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a
          value of 256. This configuration results in an 8-bit wide integer
          part of Rank.</t>

          <t hangText="DEFAULT_DAO_DELAY:">This is the default value for the
          DelayDAO Timer. DEFAULT_DAO_DELAY has a value of 1 second. See <xref
          target="ScheduleDAO"></xref>.</t>

          <t hangText="DIO Timer:">One instance per DODAG of which a node is a
          member. Expiry triggers DIO message transmission. A Trickle timer
          with variable interval in [0,
          DIOIntervalMin..2^DIOIntervalDoublings]. See <xref
          target="TrickleParameters"></xref></t>

          <t hangText="DAG Version Increment Timer:">Up to one instance per
          DODAG of which the node is acting as DODAG root. 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 versus overhead).</t>

          <t hangText="DelayDAO Timer:">Up to one timer per DAO parent (the
          subset of DODAG parents chosen to receive destination
          advertisements) per DODAG. Expiry triggers sending of DAO message to
          the DAO parent. See <xref target="ScheduleDAO"></xref></t>

          <t hangText="RemoveTimer:">Up to one timer per DAO entry per neighbor
          (i.e., those neighbors that have given DAO messages to this node as a
          DODAG parent).  Expiry may trigger No-Path advertisements or
          immediately deallocate the DAO entry if there are no DAO
          parents.</t>
        </list></t>
    </section>

    <section anchor="Manageability" title="Manageability Considerations">
      <t>The aim of this section is to give consideration to the manageability
      of RPL, and how RPL will be operated in an LLN. The scope of this section
      is to consider the following aspects of manageability: configuration,
      monitoring, fault management, accounting, and performance of the
      protocol in light of the recommendations set forth in <xref
      target="RFC5706"></xref>.</t>

      <section title="Introduction">
        <t>Most of the existing IETF management standards are MIB modules
(data models based on the Structure of
        Management Information (SMI)) to
        monitor and manage networking devices.</t>

        <t>For a number of protocols, the IETF community has used the IETF
        Standard Management Framework, including the Simple Network Management
        Protocol <xref target="RFC3410"></xref>, the Structure of Management
        Information <xref target="RFC2578"></xref>, and MIB data models for
        managing new protocols.</t>

        <t>As pointed out in <xref target="RFC5706"></xref>, the common policy
        in terms of operation and management has been expanded to a policy
        that is more open to a set of tools and management protocols rather
        than strictly relying on a single protocol such as SNMP.</t>

        <t>In 2003, the Internet Architecture Board (IAB) held a workshop on
        Network Management <xref target="RFC3535"></xref> that discussed the
        strengths and weaknesses of some IETF network management protocols and
        compared them to operational needs, especially configuration.</t>

        <t>One issue discussed was the user-unfriendliness of the binary
        format of SNMP <xref target="RFC3410"></xref>. In the case of LLNs, it
        must be noted that at the time of writing, the CoRE working group is
        actively working on resource management of devices in LLNs. Still, it
        is felt that this section provides important guidance on how RPL
        should be deployed, operated, and managed.</t>

        <t>As stated in <xref target="RFC5706"></xref>:</t>
<t><list style="empty"><t> 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. </t></list></t>

<t>These aspects are discussed in detail in the following
        sections.</t>

        <t>RPL will be used on a variety of devices that may have resources
        such as memory varying from a few kilobytes to several hundreds of kilobytes
        and even megabytes. When memory is highly constrained, it may not be
        possible to satisfy all the requirements listed in this section. Still
        it is worth listing all of these in an exhaustive fashion, and
        implementers will then determine which of these requirements could be
        satisfied according to the available resources on the device.</t>
      </section>

      <section title="Configuration Management">
        <t>This section discusses the configuration management, listing the
        protocol parameters for which configuration management is
        relevant.</t>

        <t>Some of the RPL parameters are optional. The requirements for
        configuration are only applicable for the options that are used.</t>

        <section title="Initialization Mode">
          <t>"Architectural Principles of the Internet" <xref
          target="RFC1958"></xref>, Section 3.8, states: "Avoid options and
          parameters whenever possible. Any options and parameters should be
          configured or negotiated dynamically rather than manually".  This is
          especially true in LLNs where the number of devices may be large and
          manual configuration is infeasible. This has been taken into account
          in the design of RPL whereby the DODAG root provides a number of
          parameters to the devices joining the DODAG, thus avoiding
          cumbersome configuration on the routers and potential sources of
          misconfiguration (e.g., values of Trickle timers, etc.). Still, there
          are additional RPL parameters that a RPL implementation should allow
          to be configured, which are discussed in this section.</t>

          <section title="DIS Mode of Operation upon Boot-Up">
            <t>When a node is first powered up:<list style="numbers">
                <t>The node may decide to stay silent, waiting to receive DIO
                messages from DODAG of interest (advertising a supported OF
                and metrics/constraints) and not send any multicast DIO
                messages until it has joined a DODAG.</t>

                <t>The node may decide to send one or more DIS messages
                (optionally, requesting DIO for a specific DODAG) as an initial
                probe for nearby DODAGs, and in the absence of DIO messages in
                reply after some configurable period of time, the node may
                decide to root a floating DODAG and start sending multicast
                DIO messages.</t>
              </list></t>

            <t>A RPL implementation SHOULD allow configuring the preferred
            mode of operation listed above along with the required parameters
            (in the second mode: the number of DIS messages and related
            timer).</t>
          </section>
        </section>

        <section title="DIO and DAO Base Message and Options Configuration">
          <t>RPL specifies a number of protocol parameters considering the
          large spectrum of applications where it will be used. That said,
          particular attention has been given to limiting the number of these
          parameters that must be configured on each RPL router. Instead, a
          number of the default values can be used, and when required these
          parameters can be provided by the DODAG root thus allowing for
          dynamic parameter setting.</t>

          <t>A RPL implementation SHOULD allow configuring the following
          routing protocol parameters. As pointed out above, note that a large
          set of parameters is configured on the DODAG root.</t>
        </section>

        <section title="Protocol Parameters to Be Configured on Every Router in the LLN">
          <t>A RPL implementation MUST allow configuring the following RPL
          parameters:</t>

          <t><list style="symbols">


              <t>RPLInstanceID [DIO message, in DIO Base message]. Although
              the RPLInstanceID must be configured on the DODAG root, it must
              also be configured as a policy on every node in order to
              determine whether or not the node should join a particular
              DODAG. Note that a second RPLInstanceID can be configured on the
              node, should it become root of a floating DODAG.</t>

              <t>List of supported Objective Code Points (OCPs)</t>

              <t>List of supported metrics: <xref
              target="RFC6551"></xref> specifies a
              number of metrics and constraints used for the DODAG formation.
              Thus, a RPL implementation should allow configuring the list of
              metrics that a node can accept and understand. If a DIO is
              received with a metric and/or constraint that is not understood
              or supported, as specified in <xref
              target="OperationAsALeaf"></xref>, the node would join as a leaf
              node.</t>

              <t>Prefix Information, along with valid and preferred lifetime
              and the 'L' and 'A' flags. [DIO message, Prefix Information Option].
              A RPL implementation SHOULD allow configuring if the Prefix
              Information option must be carried with the DIO message to
              distribute the Prefix Information for autoconfiguration. In
              that case, the RPL implementation MUST allow the list of
              prefixes to be advertised in the PIO along
              with the corresponding flags.</t>

              <t>Solicited Information [DIS message, in Solicited Information
              option]. Note that a RPL implementation SHOULD allow
              configuring when such messages should be sent and under which
              circumstances, along with the value of the RPLInstance ID, 'V'/'I'/'D'
              flags.</t>

              <t>'K' flag: when a node should set the 'K' flag in a DAO
              message [DAO message, in DAO Base message].</t>

              <t>MOP (Mode of Operation) [DIO message, in DIO Base
              message].</t>

              <t>Route Information (and preference) [DIO message, in Route
              Information option]</t>
            </list></t>
        </section>

        <section title="Protocol Parameters to Be Configured on Every Non-DODAG-Root Router in the LLN">
          <t>A RPL implementation MUST allow configuring the Target prefix
          [DAO message, in RPL Target option].</t>

          <t>Furthermore, there are circumstances where a node may want to
          designate a Target to allow for specific processing of the Target
          (prioritization, etc.). 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).</t>

          <t>A node whose DODAG parent set is empty may become the DODAG root
          of a floating DODAG. It may also set its DAGPreference such that it
          is less preferred. Thus, a RPL implementation MUST allow configuring
          the set of actions that the node should initiate in this case:</t>

          <t><list style="symbols">
              <t>Start its own (floating) DODAG: the new DODAGID must be
              configured in addition to its DAGPreference.</t>

              <t>Poison the broken path (see procedure in <xref
              target="DAGDiscoveryRulesPoison"></xref>).</t>

              <t>Trigger a local repair.</t>
            </list></t>
        </section>

        <section title="Parameters to Be Configured on the DODAG Root">
          <t>In addition, several other parameters are configured only on the
          DODAG root and advertised in options carried in DIO messages.</t>

          <t>As specified in <xref target="DIOTransmission"></xref>, a RPL
          implementation makes use of Trickle timers to govern the sending of
          DIO messages. The operation of the Trickle algorithm is determined
          by a set of configurable parameters, which MUST be configurable and
          that are then advertised by the DODAG root along the DODAG in DIO
          messages.</t>

          <t><list style="symbols">
              <t>DIOIntervalDoublings [DIO message, in DODAG Configuration
              option]</t>

              <t>DIOIntervalMin [DIO message, in DODAG Configuration
              option]</t>

              <t>DIORedundancyConstant [DIO message, in DODAG Configuration
              option]</t>
            </list></t>

          <t>In addition, a RPL implementation SHOULD allow for configuring
          the following set of RPL parameters:</t>

          <t><list style="symbols">
              <t>Path Control Size [DIO message, in DODAG Configuration
              option]</t>

              <t>MinHopRankIncrease [DIO message, in DODAG Configuration
              option]</t>

              <t>The DODAGPreference field [DIO message, DIO Base object]</t>

              <t>DODAGID [DIO message, in DIO Base option] and [DAO message,
              when the 'D' flag of the DAO message is set]</t>
            </list></t>

          <t>DAG root behavior: in some cases, a node may not want to
          permanently act as a floating DODAG root if it cannot join a
          grounded DODAG. For example, a battery-operated node may not want to
          act as a floating DODAG root for a long period of time. Thus, a RPL
          implementation MAY support the ability to configure whether or not a
          node could act as a floating DODAG root for a configured period of
          time.</t>

          <t>DAG Version Number Increment: a RPL implementation may allow, by
          configuration at the DODAG root, refreshing the DODAG states by
          updating the DODAGVersionNumber. A RPL implementation SHOULD allow
          configuring whether or not periodic or event triggered mechanisms
          are used by the DODAG root to control DODAGVersionNumber change
          (which triggers a global repair as specified in <xref
          target="DODAGRepair"></xref>).</t>
        </section>

        <section title="Configuration of RPL Parameters Related to DAO-Based Mechanisms">
          <t>DAO messages are optional and used in DODAGs that require
          Downward routing operation. This section deals with the set of
          parameters related to DAO messages and provides recommendations on
          their configuration.</t>

          <t>As stated in <xref target="ScheduleDAO"></xref>, it is
          recommended to delay the sending of DAO message to DAO parents in
          order to maximize the chances to perform route aggregation. Upon
          receiving a DAO message, the node should thus start a DelayDAO
          timer. The default value is DEFAULT_DAO_DELAY. A RPL implementation
          MAY allow for configuring the DelayDAO timer.</t>

          <t>In a Storing mode of operation, a storing node may increment DTSN
          in order to reliably trigger a set of DAO updates from its immediate
          children, as part of routine routing table updates and maintenance.
          A RPL implementation MAY allow for configuring a set of rules
          specifying the triggers for DTSN increment (manual or
          event-based).</t>

          <t>When a DAO entry times out or is invalidated, a node SHOULD make
          a reasonable attempt to report a No-Path to each of the DAO parents.
          That number of attempts MAY be configurable.</t>

          <t>An implementation should support rate-limiting the sending of DAO
          messages. The related parameters MAY be configurable.</t>
        </section>

        <section title="Configuration of RPL Parameters Related to Security Mechanisms">
          <t>As described in <xref target="SecurityMechanisms"></xref>, 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.</t>

          <t>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:</t>

          <t><list style="symbols">
              <t>Security Modes accepted [Unsecured mode, Preinstalled mode,
              Authenticated mode]</t>

              <t>KIM values accepted [Secure RPL control messages, in Security
              section]</t>

              <t>Level values accepted [Secure RPL control messages, in
              Security section]</t>

              <t>Algorithm values accepted [Secure RPL control messages, in
              Security section]</t>

              <t>Key material in support of Authenticated or Preinstalled key
              modes.</t>
            </list></t>

          <t>In addition, a RPL implementation SHOULD allow for configuring a
          DODAG root with a subset of the following parameters:</t>

          <t><list style="symbols">
              <t>Level values advertised [Secure DIO message, in Security
              section]</t>

              <t>KIM value advertised [Secure DIO message, in Security
              section]</t>

              <t>Algorithm value advertised [Secure DIO message, in Security
              section]</t>
            </list></t>
        </section>

        <section title="Default Values">
          <t>This document specifies default values for the following set of
          RPL variables: <?rfc subcompact="yes"?><list>
              <t>DEFAULT_PATH_CONTROL_SIZE</t>

              <t>DEFAULT_DIO_INTERVAL_MIN</t>

              <t>DEFAULT_DIO_INTERVAL_DOUBLINGS</t>

              <t>DEFAULT_DIO_REDUNDANCY_CONSTANT</t>

              <t>DEFAULT_MIN_HOP_RANK_INCREASE</t>

              <t>DEFAULT_DAO_DELAY</t>
            </list><?rfc subcompact="no"?></t>

          <t>It is recommended to specify default values in protocols; that
          being said, as discussed in <xref target="RFC5706"></xref>, default
          values may make less and less sense. RPL is a routing protocol that
          is expected to be used in a number of contexts where network
          characteristics such as the number of nodes and link and node types
          are expected to vary significantly. Thus, these default values are
          likely to change with the context and as the technology evolves.
          Indeed, LLNs' related technology (e.g., hardware, link layers) have
          been evolving dramatically over the past few years and such
          technologies are expected to change and evolve considerably in the
          coming years.</t>

          <t>The proposed values are not based on extensive best current
          practices and are considered to be conservative.</t>
        </section>
      </section>

      <section title="Monitoring of RPL Operation">
        <t>Several RPL parameters should be monitored to verify the correct
        operation of the routing protocol and the network itself. This section
        lists the set of monitoring parameters of interest.</t>

        <section title="Monitoring a DODAG Parameters">
          <t>A RPL implementation SHOULD provide information about the
          following parameters:</t>

          <t><list style="symbols">
              <t>DODAG Version number [DIO message, in DIO Base message]</t>

              <t>Status of the 'G' flag [DIO message, in DIO Base message]</t>

              <t>Status of the MOP field [DIO message, in DIO Base
              message]</t>

              <t>Value of the DTSN [DIO message, in DIO Base message]</t>

              <t>Value of the Rank [DIO message, in DIO Base message]</t>

              <t>DAOSequence: Incremented at each unique DAO message, echoed
              in the DAO-ACK message [DAO and DAO-ACK messages]</t>

              <t>Route Information [DIO message, Route Information Option]
              (list of IPv6 prefixes per parent along with lifetime and
              preference]</t>

              <t>Trickle parameters: <list style="symbols">
                  <t>DIOIntervalDoublings [DIO message, in DODAG Configuration
                  option]</t>

                  <t>DIOIntervalMin [DIO message, in DODAG Configuration
                  option]</t>

                  <t>DIORedundancyConstant [DIO message, in DODAG
                  Configuration option]</t>
                </list></t>

              <t>Path Control Size [DIO message, in DODAG Configuration
              option]</t>

              <t>MinHopRankIncrease [DIO message, in DODAG Configuration
              option]</t>
            </list></t>

          <t>Values that may be monitored only on the DODAG root:</t>

          <t><list style="symbols">
              <t>Transit Information [DAO, Transit Information option]: A RPL
              implementation SHOULD allow configuring whether the set of
              received Transit Information options should be displayed on the
              DODAG root. In this case, the RPL database of received Transit
              Information should also contain the Path Sequence, Path
              Control, Path Lifetime, and Parent Address.</t>
            </list></t>
        </section>

        <section title="Monitoring a DODAG Inconsistencies and Loop Detection">
          <t>Detection of DODAG inconsistencies is particularly critical in
          RPL networks. Thus, it is recommended for a RPL implementation to
          provide appropriate monitoring tools. A RPL implementation SHOULD
          provide a counter reporting the number of a times the node has
          detected an inconsistency with respect to a DODAG parent, e.g., if
          the DODAGID has changed.</t>

          <t>When possible more granular information about inconsistency
          detection should be provided. A RPL implementation MAY provide
          counters reporting the number of following inconsistencies:</t>

          <t><list style="symbols">
              <t>Packets received with 'O' bit set (to Down) from a node with
              a higher Rank</t>

              <t>Packets received with 'O' bit cleared (to Up) from a node
              with a lower Rank</t>

              <t>Number of packets with the 'F' bit set</t>

              <t>Number of packets with the 'R' bit set</t>
            </list></t>
        </section>
      </section>

      <section title="Monitoring of the RPL Data Structures">
        <section title="Candidate Neighbor Data Structure">
          <t>A node in the candidate neighbor list is a node discovered by the
          same 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.</t>

          <t>A RPL implementation MAY provide a counter reporting the number
          of times a candidate neighbor has been ignored, should the number of
          candidate neighbors exceed the maximum authorized value.</t>
        </section>

        <section title="Destination-Oriented Directed Acyclic Graph (DODAG) Table">
          <t>For each DODAG, a RPL implementation is expected to keep track of
          the following DODAG table values:</t>

          <t><list style="symbols">
              <t>RPLInstanceID</t>

              <t>DODAGID</t>

              <t>DODAGVersionNumber</t>

              <t>Rank</t>

              <t>Objective Code Point</t>

              <t>A set of DODAG parents</t>

              <t>A set of prefixes offered Upward along the DODAG</t>

              <t>Trickle timers used to govern the sending of DIO messages for
              the DODAG</t>

              <t>List of DAO parents</t>

              <t>DTSN</t>

              <t>Node status (router versus leaf)</t>
            </list></t>

          <t>A RPL implementation SHOULD allow for monitoring the set of
          parameters listed above.</t>
        </section>

        <section title="Routing Table and DAO Routing Entries">
          <t>A RPL implementation maintains several information elements
          related to the DODAG and the DAO entries (for storing nodes). In the
          case of a non-storing node, a limited amount of information is
          maintained (the routing table is mostly reduced to a set of DODAG
          parents along with characteristics of the DODAG as mentioned above);
          whereas in the case of storing nodes, this information is augmented
          with routing entries.</t>

          <t>A RPL implementation SHOULD allow for the following parameters to
          be monitored:</t>

          <t><list style="symbols">
              <t>Next Hop (DODAG parent)</t>

              <t>Next Hop Interface</t>

              <t>Path metrics value for each DODAG parent</t>
            </list></t>

          <t>A DAO Routing Table entry conceptually contains the following
          elements (for storing nodes only):</t>

          <t><list style="symbols">
              <t>Advertising Neighbor Information</t>

              <t>IPv6 address</t>

              <t>Interface ID to which DAO parents has this entry been
              reported</t>

              <t>Retry counter</t>

              <t>Logical equivalent of DAO Content: <list style="symbols">
                  <t>DAO-Sequence</t>

                  <t>Path Sequence</t>

                  <t>DAO Lifetime</t>

                  <t>DAO Path Control</t>
                </list></t>

              <t>Destination Prefix (or address or Mcast Group)</t>
            </list></t>

          <t>A RPL implementation SHOULD provide information about the state
          of each DAO Routing Table entry states.</t>
        </section>
      </section>

      <section anchor="mgmtFault" title="Fault Management">
        <t>Fault management is a critical component used for troubleshooting,
        verification of the correct mode of operation of the protocol, and network
        design; also, it is a key component of network performance monitoring.
        A RPL implementation SHOULD allow the provision of the following information
        related to fault managements:</t>

        <t><list style="symbols">
            <t>Memory overflow along with the cause (e.g., routing tables
            overflow, etc.)</t>

            <t>Number of times a packet could not be sent to a DODAG parent
            flagged as valid</t>

            <t>Number of times a packet has been received for which the router
            did not have a corresponding RPLInstanceID</t>

            <t>Number of times a local repair procedure was triggered</t>

            <t>Number of times a global repair was triggered by the DODAG
            root</t>

            <t>Number of received malformed messages</t>

            <t>Number of seconds with packets to forward and no next hop
            (DODAG parent)</t>

            <t>Number of seconds without next hop (DODAG parent)</t>

            <t>Number of times a node has joined a DODAG as a leaf because it
            received a DIO with a metric/constraint that was not understood and it was
            configured to join as a leaf node in this case (see <xref
            target="mgmtPolicy"></xref>)</t>
          </list></t>

        <t>It is RECOMMENDED to report faults via at least error log messages.
        Other protocols may be used to report such faults.</t>
      </section>

      <section anchor="mgmtPolicy" title="Policy">
        <t>Policy rules can be used by a RPL implementation to determine
        whether or not the node is allowed to join a particular DODAG
        advertised by a neighbor by means of DIO messages.</t>

        <t>This document specifies operation within a single DODAG. A DODAG is
        characterized by the following tuple (RPLInstanceID, DODAGID).
        Furthermore, as pointed out above, DIO messages are used to advertise
        other DODAG characteristics such as the routing metrics and
        constraints used to build to the DODAG and the Objective Function in
        use (specified by OCP).</t>

        <t>The first policy rules consist of specifying the following
        conditions that a RPL node must satisfy to join a DODAG:</t>

        <t><list style="symbols">
            <t>RPLInstanceID</t>

            <t>List of supported routing metrics and constraints</t>

            <t>Objective Function (OCP values)</t>
          </list></t>

        <t>A RPL implementation MUST allow configuring these parameters and
        SHOULD specify whether the node must simply ignore the DIO if the
        advertised DODAG is not compliant with the local policy or whether the
        node should join as the leaf node if only the list of supported
        routing metrics and constraints, and the OF is not supported.
        Additionally, a RPL implementation SHOULD allow for the addition of the
        DODAGID as part of the policy.</t>

        <t>A RPL implementation SHOULD allow configuring the set of acceptable
        or preferred Objective Functions (OFs) referenced by their Objective
        Code Points (OCPs) for a node to join a DODAG, and what action should
        be taken if none of a node's candidate neighbors advertise one of the
        configured allowable Objective Functions, or if the advertised
        metrics/constraint is not understood/supported. Two actions can be
        taken in this case:</t>

        <t><list style="symbols">
            <t>The node joins the DODAG as a leaf node as specified in <xref
            target="OperationAsALeaf"></xref>.</t>

            <t>The node does not join the DODAG.</t>
          </list></t>

        <t>A node in an LLN may learn routing information from different
        routing protocols including RPL. In this case, it is desirable to
        control, via administrative preference, which route should be favored.
        An implementation SHOULD allow for the specification of an administrative
        preference for the routing protocol from which the route was
        learned.</t>

        <t>Internal Data Structures: some RPL implementations may limit the
        size of the candidate neighbor list in order to bound the memory
        usage; in which case, some otherwise viable candidate neighbors may not
        be considered and simply dropped from the candidate neighbor list.</t>

        <t>A RPL implementation MAY provide an indicator on the size of the
        candidate neighbor list.</t>
      </section>

      <section title="Fault Isolation">
        <t>It is RECOMMENDED to quarantine neighbors that start emitting
        malformed messages at unacceptable rates.</t>
      </section>

      <section title="Impact on Other Protocols">
        <t>RPL has very limited impact on other protocols. Where more than one
        routing protocol is required on a router, such as an LBR, it is expected
        for the device to support routing redistribution functions between the
        routing protocols to allow for reachability between the two routing
        domains. Such redistribution SHOULD be governed by the use of user
        configurable policy.</t>

        <t>With regard to the impact in terms of traffic on the network, RPL
        has been designed to limit the control traffic thanks to mechanisms
        such as Trickle timers (<xref target="DIOTransmission"></xref>). Thus,
        the impact of RPL on other protocols should be extremely limited.</t>
      </section>

      <section title="Performance Management">
        <t>Performance management is always an important aspect of a protocol,
        and RPL is not an exception. Several metrics of interest have been
        specified by the IP Performance Monitoring (IPPM) working group: that
        being said, they will be hardly applicable to LLN considering the cost
        of monitoring these metrics in terms of resources on the devices and
        required bandwidth. Still, RPL implementations MAY support some of
        these, and other parameters of interest are listed below:</t>

        <t><list style="symbols">
            <t>Number of repairs and time to repair in seconds (average,
            variance)</t>

            <t>Number of times and time period during which a devices could not
            forward a packet because of a lack of a reachable neighbor in its
            routing table</t>

            <t>Monitoring of resources consumption by RPL in terms of
            bandwidth and required memory</t>

            <t>Number of RPL control messages sent and received</t>
          </list></t>
      </section>

      <section title="Diagnostics">
        <t>There 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.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <section title="Overview">
        <t>From a security perspective, RPL networks are no different from any
        other network. They are vulnerable to passive eavesdropping attacks
        and, potentially, even active tampering when physical access to a wire
        is not required to participate in communications. The very nature of
        ad hoc networks and their cost objectives impose additional security
        constraints, which perhaps make these networks the most difficult
        environments to secure. Devices are low-cost and have limited
        capabilities in terms of computing power, available storage, and power
        drain; 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.</t>

        <t>The security mechanisms in this standard are based on symmetric-key
        and public-key cryptography and use keys that are to be provided by
        higher-layer processes. The establishment and maintenance of these
        keys are out of scope for this specification. The mechanisms assume a
        secure implementation of cryptographic operations and secure and
        authentic storage of keying material.</t>

        <t>The security mechanisms specified provide particular combinations
        of the following security services:</t>

        <t><list hangIndent="24" style="hanging">
            <t hangText="Data confidentiality:">Assurance that transmitted
            information is only disclosed to parties for which it is
            intended.</t>

            <t hangText="Data authenticity:">Assurance of the source of
            transmitted information (and, hereby, that information was not
            modified in transit).</t>

            <t hangText="Replay protection:">Assurance that a duplicate of
            transmitted information is detected.</t>

            <t hangText="Timeliness (delay protection):">Assurance that
            transmitted information was received in a timely manner.</t>
          </list></t>

        <t>The actual protection provided can be adapted on a per-packet basis
        and allows for varying levels of data authenticity (to minimize
        security overhead in transmitted packets where required) and for
        optional data confidentiality. When nontrivial protection is required,
        replay protection is always provided.</t>

        <t>Replay protection is provided via the use of a non-repeating value
        (CCM nonce) in the packet protection process and storage of some
        status information (originating device and the CCM nonce counter last
        received from that device), which allows detection of whether this
        particular CCM nonce value was used previously by the originating
        device. In addition, so-called delay protection is provided amongst
        those devices that have a loosely synchronized clock on board. The
        acceptable time delay can be adapted on a per-packet basis and allows
        for varying latencies (to facilitate longer latencies in packets
        transmitted over a multi-hop communication path).</t>

        <t>Cryptographic protection may use a key shared between two peer
        devices (link key) or a key shared among a group of devices (group
        key), thus allowing some flexibility and application-specific
        trade-offs between key storage and key maintenance costs versus the
        cryptographic protection provided. If a group key is used for
        peer-to-peer communication, protection is provided only against
        outsider devices and not against potential malicious devices in the
        key-sharing group.</t>

        <t>Data authenticity may be provided using symmetric-key-based or
        public-key-based techniques. With public-key-based techniques (via
        signatures), one corroborates evidence as to the unique originator of
        transmitted information, whereas with symmetric-key-based techniques,
        data authenticity is only provided relative to devices in a
        key-sharing group. Thus, public-key-based authentication may be useful
        in scenarios that require a more fine-grained authentication than can
        be provided with symmetric-key-based authentication techniques alone,
        such as with group communications (broadcast, multicast) or in
        scenarios that require non-repudiation.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section title="RPL Control Message">
        <t>The RPL control message is an ICMP information message type that is
        to be used carry DODAG Information Objects, DODAG Information
        Solicitations, and Destination Advertisement Objects in support of RPL
        operation.</t>

        <t>IANA has defined an ICMPv6 Type Number Registry. The type
        value for the RPL control message is 155.</t>
      </section>

      <section anchor="RPLCtrlCodeReg"
               title="New Registry for RPL Control Codes">
        <t>IANA has created a registry, RPL Control Codes, for the
        Code field of the ICMPv6 RPL control message.</t>

        <t>New codes may be allocated only by an IETF Review. Each code is
        tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Code</t>

            <t>Description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following codes are currently defined:</t>

<?rfc compact="no"?>
        <texttable title="RPL Control Codes">
          <ttcol align="center">Code</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0x00</c>

          <c>DODAG Information Solicitation</c>

          <c>This document</c>

          <c>0x01</c>

          <c>DODAG Information Object</c>

          <c>This document</c>

          <c>0x02</c>

          <c>Destination Advertisement Object</c>

          <c>This document</c>

          <c>0x03</c>

          <c>Destination Advertisement Object Acknowledgment</c>

          <c>This document</c>

          <c>0x80</c>

          <c>Secure DODAG Information Solicitation</c>

          <c>This document</c>

          <c>0x81</c>

          <c>Secure DODAG Information Object</c>

          <c>This document</c>

          <c>0x82</c>

          <c>Secure Destination Advertisement Object</c>

          <c>This document</c>

          <c>0x83</c>

          <c>Secure Destination Advertisement Object Acknowledgment</c>

          <c>This document</c>

          <c>0x8A</c>

          <c>Consistency Check</c>

          <c>This document</c>
        </texttable>
<?rfc compact="yes"?>

      </section>

      <section anchor="MOPRegistry"
               title="New Registry for the Mode of Operation (MOP)">
        <t>IANA has created a registry for the 3-bit Mode of
        Operation (MOP), which is contained in the DIO Base.</t>

        <t>New values may be allocated only by an IETF Review. Each value
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Mode of Operation Value</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>Four values are currently defined:</t>

<?rfc compact="no"?>
        <texttable title="DIO Mode of Operation">
          <ttcol align="center">MOP value</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>No Downward routes maintained by RPL</c>

          <c>This document</c>

          <c>1</c>

          <c>Non-Storing Mode of Operation</c>

          <c>This document</c>

          <c>2</c>

          <c>Storing Mode of Operation with no multicast support</c>

          <c>This document</c>

          <c>3</c>

          <c>Storing Mode of Operation with multicast support</c>

          <c>This document</c>
        </texttable>
<?rfc compact="yes"?>

        <t>The rest of the range, decimal 4 to 7, is currently unassigned.</t>
      </section>

      <section anchor="RPLCtrlMsgOptionsReg"
               title="RPL Control Message Options">
        <t>IANA has created a registry for the RPL Control Message
        Options.</t>

        <t>New values may be allocated only by an IETF Review. Each value
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Value</t>

            <t>Meaning</t>

            <t>Defining RFC</t>
          </list></t>

<?rfc compact="no"?>
        <texttable title="RPL Control Message Options">
          <ttcol align="center">Value</ttcol>

          <ttcol align="left">Meaning</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0x00</c>

          <c>Pad1</c>

          <c>This document</c>

          <c>0x01</c>

          <c>PadN</c>

          <c>This document</c>

          <c>0x02</c>

          <c>DAG Metric Container</c>

          <c>This Document</c>

          <c>0x03</c>

          <c>Routing Information</c>

          <c>This Document</c>

          <c>0x04</c>

          <c>DODAG Configuration</c>

          <c>This Document</c>

          <c>0x05</c>

          <c>RPL Target</c>

          <c>This Document</c>

          <c>0x06</c>

          <c>Transit Information</c>

          <c>This Document</c>

          <c>0x07</c>

          <c>Solicited Information</c>

          <c>This Document</c>

          <c>0x08</c>

          <c>Prefix Information</c>

          <c>This Document</c>

          <c>0x09</c>

          <c>Target Descriptor</c>

          <c>This Document</c>
        </texttable>
<?rfc compact="yes"?>
      </section>

      <section anchor="OCPReg" title="Objective Code Point (OCP) Registry">
        <t>IANA has created a registry to manage the codespace of
        the Objective Code Point (OCP) field.</t>

        <t>No OCPs are defined in this specification.</t>

        <t>New codes may be allocated only by an IETF Review. Each code 
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Code</t>

            <t>Description</t>

            <t>Defining RFC</t>
          </list></t>
      </section>

      <section anchor="secsecalgoreg"
               title="New Registry for the Security Section Algorithm">
        <t>IANA has created a registry for the values of the 8-bit
        Algorithm field in the Security section.</t>

        <t>New values may be allocated only by an IETF Review. Each value
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Value</t>

            <t>Encryption/MAC</t>

            <t>Signature</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following value is currently defined:</t>

        <texttable title="Security Section Algorithm">
          <ttcol align="center">Value</ttcol>

          <ttcol align="left">Encryption/MAC</ttcol>

          <ttcol align="left">Signature</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>CCM with AES-128</c>

          <c>RSA with SHA-256</c>

          <c>This document</c>
        </texttable>
      </section>

      <section anchor="SecSecflggreg"
               title="New Registry for the Security Section Flags">
        <t>IANA has created a registry for the 8-bit Security
        Section Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>No bit is currently defined for the Security Section Flags field.</t>
      </section>

      <section anchor="SecSeckimlevelflggreg"
               title="New Registry for Per-KIM Security Levels">
        <t>IANA has created one registry for the 3-bit Security
        Level (LVL) field per allocated KIM value.</t>

        <t>For a given KIM value, new levels may be allocated only by an IETF
        Review. Each level is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Level</t>

            <t>KIM value</t>

            <t>Description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following levels per KIM value are currently defined:</t>

<?rfc compact="no"?>
        <texttable title="Per-KIM Security Levels">
          <ttcol align="center">Level</ttcol>

          <ttcol align="center">KIM value</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>0</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>1</c>

          <c>0</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>2</c>

          <c>0</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>3</c>

          <c>0</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>0</c>

          <c>1</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>1</c>

          <c>1</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>2</c>

          <c>1</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>3</c>

          <c>1</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>0</c>

          <c>2</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>1</c>

          <c>2</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>2</c>

          <c>2</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>3</c>

          <c>2</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>0</c>

          <c>3</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>1</c>

          <c>3</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>2</c>

          <c>3</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>

          <c>3</c>

          <c>3</c>

          <c>See <xref target="LVLEncoding"></xref></c>

          <c>This document</c>
        </texttable>
<?rfc compact="yes"?>

      </section>

      <section anchor="DISflggreg"
               title="New Registry for DODAG Informational Solicitation (DIS) Flags">
        <t>IANA has created a registry for the DIS (DODAG
        Informational Solicitation) Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>No bit is currently defined for the DIS (DODAG Informational
        Solicitation) Flags field.</t>
      </section>

      <section anchor="DIOflggreg"
               title="New Registry for the DODAG Information Object (DIO) Flags">
        <t>IANA has created a registry for the 8-bit DODAG
        Information Object (DIO) Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>No bit is currently defined for the DIS (DODAG Informational
        Solicitation) Flags.</t>
      </section>

      <section anchor="DAOflggreg"
               title="New Registry for the Destination Advertisement Object (DAO) Flags">
        <t>IANA has created a registry for the 8-bit Destination
        Advertisement Object (DAO) Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following bits are currently defined:</t>

<?rfc compact="no"?>
        <texttable title="DAO Base Flags">
          <ttcol align="center">Bit number</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>DAO-ACK request (K)</c>

          <c>This document</c>

          <c>1</c>

          <c>DODAGID field is present (D)</c>

          <c>This document</c>
        </texttable>
<?rfc compact="yes"?>

      </section>

      <section anchor="DAOackflggreg"
               title="New Registry for the Destination Advertisement Object (DAO) Acknowledgement Flags">
        <t>IANA has created a registry for the 8-bit Destination
        Advertisement Object (DAO) Acknowledgement Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following bit is currently defined:</t>

        <texttable title="DAO-ACK Base Flags">
          <ttcol align="center">Bit number</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>DODAGID field is present (D)</c>

          <c>This document</c>
        </texttable>
      </section>

      <section anchor="CCflggreg"
               title="New Registry for the Consistency Check (CC) Flags">
        <t>IANA has created a registry for the 8-bit Consistency
        Check (CC) Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following bit is currently defined:</t>

        <texttable title="Consistency Check Base Flags">
          <ttcol align="center">Bit number</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>CC Response (R)</c>

          <c>This document</c>
        </texttable>
      </section>

      <section anchor="DODAGCflggreg"
               title="New Registry for the DODAG Configuration Option Flags">
        <t>IANA has created a registry for the 8-bit DODAG
        Configuration Option Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following bits are currently defined:</t>

        <texttable title="DODAG Configuration Option Flags">
          <ttcol align="center">Bit number</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>4</c>

          <c>Authentication Enabled (A)</c>

          <c>This document</c>

          <c>5-7</c>

          <c>Path Control Size (PCS)</c>

          <c>This document</c>
        </texttable>
      </section>

      <section anchor="targetflggreg"
               title="New Registry for the RPL Target Option Flags">
        <t>IANA has created a registry for the 8-bit RPL Target
        Option Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>No bit is currently defined for the RPL Target Option Flags.</t>
      </section>

      <section anchor="TIOflggreg"
               title="New Registry for the Transit Information Option Flags">
        <t>IANA has created a registry for the 8-bit Transit
        Information Option (TIO) Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following bits are currently defined:</t>

        <texttable title="Transit Information Option Flags">
          <ttcol align="center">Bit number</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>External (E)</c>

          <c>This document</c>
        </texttable>
      </section>

      <section anchor="SIOflggreg"
               title="New Registry for the Solicited Information Option Flags">
        <t>IANA has created a registry for the 8-bit Solicited
        Information Option (SIO) Flags field.</t>

        <t>New bit numbers may be allocated only by an IETF Review. Each bit
        is tracked with the following qualities:</t>

        <t><list style="symbols">
            <t>Bit number (counting from bit 0 as the most significant
            bit)</t>

            <t>Capability description</t>

            <t>Defining RFC</t>
          </list></t>

        <t>The following bits are currently defined:</t>

<?rfc compact="no"?>
        <texttable title="Solicited Information Option Flags">
          <ttcol align="center">Bit number</ttcol>

          <ttcol align="left">Description</ttcol>

          <ttcol align="left">Reference</ttcol>

          <c>0</c>

          <c>Version Predicate match (V)</c>

          <c>This document</c>

          <c>1</c>

          <c>InstanceID Predicate match (I)</c>

          <c>This document</c>

          <c>2</c>

          <c>DODAGID Predicate match (D)</c>

          <c>This document</c>
        </texttable>
<?rfc compact="yes"?>

      </section>

      <section anchor="ICMPv6ErrSrcRte"
               title="ICMPv6: Error in Source Routing Header">
        <t>In some cases RPL will return an ICMPv6 error message when a
        message cannot be delivered as specified by its source routing header.
        This ICMPv6 error message is "Error in Source Routing Header".</t>

        <t>IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6
        Message Types. ICMPv6 Message Type 1 describes "Destination
        Unreachable" codes. The "Error in Source Routing Header" code is
        has been allocated from the ICMPv6 Code Fields Registry for
        ICMPv6 Message Type 1, with a code value of 7.</t>
      </section>

      <section anchor="Multicastgroup"
               title="Link-Local Scope Multicast Address">
        <t>The rules for assigning new IPv6 multicast addresses are defined in
        <xref target="RFC3307"></xref>. This specification requires the
        allocation of a new permanent multicast address with a link-local
        scope for RPL nodes called all-RPL-nodes, with a value of
        ff02::1a.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge the review, feedback, and
      comments from 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.</t>

      <t>The authors would like to acknowledge the guidance and input provided
      by the ROLL Chairs, David Culler and JP.&nbsp;Vasseur, and the Area Director,
      Adrian Farrel.</t>

      <t>The authors would like to acknowledge prior contributions of Robert
      Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
      Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
      Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Jim
      Bound, Yanick Pouffary, Henning Rogge, and Arsalan Tavakoli, who have
      provided useful design considerations to RPL.</t>

      <t>RPL Security Design, found in <xref
      target="SecurityMechanisms"></xref>, <xref target="Security"></xref>,
      and elsewhere throughout the document, is primarily the contribution of
      the Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
      Levis, Kris Pister, Rene Struik, and Adrian Farrel.</t>

      <t>Thanks also to Jari Arkko and Ralph Droms for their attentive
      reviews, especially with respect to interoperability considerations and 
      integration with other IETF specifications.</t>
    </section>

    <section title="Contributors">
      <figure>
        <artwork><![CDATA[
Stephen Dawson-Haggerty
UC Berkeley
Soda Hall
Berkeley, CA  94720
USA

EMail: stevedh@cs.berkeley.edu


    ]]></artwork>
      </figure>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2460"?>

      <?rfc include="reference.RFC.3447"?>

      <?rfc include="reference.RFC.6275"?>

      <?rfc include="reference.RFC.4191"?>

      <?rfc include="reference.RFC.4302"?>

      <?rfc include="reference.RFC.4443"?>

      <?rfc include="reference.RFC.4861"?>

      <?rfc include="reference.RFC.4862"?>

<!--      <?rfc include='reference.I-D.ietf-roll-routing-metrics.xml'?>  -->
<reference anchor='RFC6551'>
<front>
<title>Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks</title>

<author initials='JP' surname='Vasseur' fullname='JP. Vasseur' role='editor'>
    <organization />
</author>

<author initials='M' surname='Kim' fullname='Mijeom Kim' role='editor'>
    <organization />
</author>

<author initials='K' surname='Pister' fullname='Kris Pister'>
    <organization />
</author>

<author initials='N' surname='Dejean' fullname='Nicolas Dejean'>
    <organization />
</author>

<author initials='D' surname='Barthel' fullname='Dominique Barthel'>
    <organization />
</author>

<date month='March' year='2012' />

<abstract><t>Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints.  By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol.</t></abstract>

</front>

<seriesInfo name='RFC' value='6551' />

</reference>


<!--      <?rfc include='reference.I-D.ietf-roll-of0.xml'?>  -->
<reference anchor='RFC6552'>
<front>
<title>Objective Function Zero for the Routing Protocol for Low-Power and Lossy
Networks (RPL)</title>

<author initials='P' surname='Thubert' fullname='Pascal Thubert' role="editor">
    <organization />
</author>

<date month='March'  year='2012' />

<abstract><t>The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs).  An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm.  This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension</t></abstract>

</front>

<seriesInfo name='RFC' value='6552' />

</reference>


<?rfc include='reference.RFC.6206'?>

 <!--     <?rfc include="reference.I-D.ietf-6man-rpl-option.xml"?>  -->
<reference anchor='RFC6553'>
<front>
<title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams</title>

<author initials='J' surname='Hui' fullname='Jonathan Hui'>
    <organization />
</author>

<author initials='JP' surname='Vasseur' fullname='JP. Vasseur'>
    <organization />
</author>

<date month='March' year='2012' />

<abstract><t>The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams.  This document describes the RPL Option for use among RPL routers.</t></abstract>

</front>

<seriesInfo name='RFC' value='6553' />

</reference>


 <!--     <?rfc include="reference.I-D.ietf-6man-rpl-routing-header.xml"?>  -->
<reference anchor='RFC6554'>
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>

<author initials='J' surname='Hui' fullname='Jonathan Hui'>
    <organization />
</author>

<author initials='JP' surname='Vasseur' fullname='JP. Vasseur'>
    <organization />
</author>

<author initials='D' surname='Culler' fullname='David Culler'>
    <organization />
</author>

<author initials='V' surname='Manral' fullname='Vishwas Manral'>
    <organization />
</author>

<date month='March' year='2012' />

<abstract><t>In Low power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining at most a few routes.  In some configurations, it is necessary to use these memory constrained routers to deliver datagrams to nodes within the LLN.  The Routing for Low Power and Lossy Networks (RPL) protocol can be used in some deployments to store most, if not all, routes on one (e.g. the Directed Acyclic Graph (DAG) root) or few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory constrained routers.  This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL Instance.</t></abstract>

</front>

<seriesInfo name='RFC' value='6554' />

</reference>


    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5867'?>

      <?rfc include='reference.RFC.5673'?>

      <?rfc include="reference.RFC.5548"?>

      <?rfc include="reference.RFC.5826"?>

 <!--     <?rfc include='reference.I-D.ietf-roll-terminology.xml'?> ID exists-->
<reference anchor='ROLL-TERMS'>
<front>
<title>Terminology in Low power And Lossy Networks</title>

<author initials='J' surname='Vasseur' fullname='JP. Vasseur'>
    <organization />
</author>

<date month='September' day='14' year='2011' />

<abstract><t>The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN).  A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g.  Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration.</t></abstract>

</front>

<seriesInfo name='Work in' value='Progress' />

</reference>


      <?rfc include="reference.RFC.3819"?>

      <?rfc include="reference.RFC.4101"?>

      <?rfc include="reference.RFC.4915"?>

      <?rfc include="reference.RFC.5120"?>

      <?rfc include="reference.RFC.1982"?>

      <?rfc include='reference.RFC.5184'?>

      <?rfc include='reference.RFC.5706'?>

      <?rfc include='reference.RFC.5881'?>

      <?rfc include='reference.RFC.3410'?>

      <?rfc include='reference.RFC.3610'?>

      <?rfc include='reference.RFC.2578'?>

      <?rfc include='reference.RFC.3535'?>

      <?rfc include='reference.RFC.1958'?>

      <?rfc include="reference.RFC.3307"?>

 <!--     <?rfc include="reference.I-D.ietf-manet-nhdp.xml"?> now RFC 6130-->

      <?rfc include='reference.RFC.6130'?>

<!--      <?rfc include='reference.I-D.ietf-6lowpan-nd.xml'?> Exists-->


<reference anchor='6LOWPAN-ND'>
<front>
<title>Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby' role='editor'>
    <organization />
</author>

<author initials='S' surname='Chakrabarti' fullname='Samita Chakrabarti'>
    <organization />
</author>

<author initials='E' surname='Nordmark' fullname='Erik Nordmark'>
    <organization />
</author>

<date month='October' day='24' year='2011' />

<abstract><t>The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4.  This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation.  In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links.  IPv6 Neighbor Discovery was not designed for non-transitive wireless links.  The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network.  This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks.  The document, thus updates RFC 4944 to specify the use of the optimizations defined here.</t></abstract>

</front>

<seriesInfo name='Work in' value='Progress' />

</reference>



      <reference anchor="Perlman83">
                 
        <front>
          <title abbrev="Perlman83">Fault-Tolerant Broadcast of Routing
          Information</title>

          <author fullname="Radia Perlman" initials="R." surname="Perlman">
            <organization>Digital Equipment Corp.</organization>
          </author>

          <date month="December" year="1983" />
        </front>

        <seriesInfo name="North-Holland Computer Networks, Vol.7:" value="p. 395-405" />

        <format target="http://www.cs.illinois.edu/~pbg/courses/cs598fa09/readings/p83.pdf"
                type="HTML" />
      </reference>

      <reference anchor="FIPS180"
                 target="http://www.nist.gov/itl/upload/fips180-3_final.pdf">
        <front>
          <title abbrev="FIPS Pub 180-3">FIPS Pub 180-3, Secure Hash Standard
          (SHS)</title>

          <author fullname="National Institute of Standards and Technology"
                  initials=""
                  surname="National Institute of Standards and Technology"></author>

          <date month="February" year="2008" />
        </front>

        <seriesInfo name="US Department of Commerce" value="" />

        <format target="http://www.nist.gov/itl/upload/fips180-3_final.pdf"
                type="HTML" />
      </reference>
    </references>

    <section anchor="Examples" title="Example Operation">
      <t>This appendix provides some examples to illustrate the dissemination
      of addressing information and prefixes with RPL. The examples depict
      information being distributed with PIOs and RIOs 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.</t>

      <t>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.</t>

      <section anchor="Case1"
               title="Example Operation in Storing Mode with Node-Owned Prefixes">
        <t><xref target="FigureCase1"></xref> 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. &nbsp;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.</t>

        <figure anchor="FigureCase1"
                title="Storing Mode with Node-Owned Prefixes">
          <artwork><![CDATA[
                                                                     
                                                                     
                           +-------------+                           
                           |    Root     |                           
                           |             |                           
                           |   Node A    |                           
                           |             |                           
                           |    A::A     |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                                  |                                  
                           +------+------+                           
                           |    A::B     |                           
                           |             |                           
                           |   Node B    |                           
                           |             |                           
                           |    B::B     |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                   .--------------+--------------.                   
                  /                               \                  
                 /                                 \                 
         +------+------+                     +------+------+         
         |    B::C     |                     |    B::D     |         
         |             |                     |             |         
         |   Node C    |                     |   Node D    |         
         |             |                     |             |         
         |    C::C     |                     |    D::D     |         
         +-------------+                     +-------------+         
                                                                     
]]></artwork>
        </figure>

        <section anchor="Case1DIO" title="DIO Messages and PIO">
          <t>Node A, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Set</t>

              <t hangText="    'R' flag:">Clear</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Set</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">B::B</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Set</t>

              <t hangText="    'R' flag:">Clear</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">C::</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Set</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">D::D</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="DAO Messages">
          <t>Node B will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target B::/64</t>

              <t hangText="    o">Target C::/64</t>

              <t hangText="    o">Target D::/64</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will send DAO messages to Node B with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target C::/64</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will send DAO messages to Node B with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target D::/64</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="Routing Information Base">
          <t>Node A will conceptually collect the following information into
          its Routing Information Base (RIB): <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">A::/64 connected</t>

              <t hangText="    o">B::/64 via B's link local</t>

              <t hangText="    o">C::/64 via B's link local</t>

              <t hangText="    o">D::/64 via B's link local</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via A's link local</t>

              <t hangText="    o">B::/64 connected</t>

              <t hangText="    o">C::/64 via C's link local</t>

              <t hangText="    o">D::/64 via D's link local</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">C::/64 connected</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">D::/64 connected</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section anchor="Case2"
               title="Example Operation in Storing Mode with Subnet-Wide Prefix">
        <t><xref target="FigureCase2"></xref> illustrates the logical
        addressing architecture of a simple RPL network operating in Storing
        mode. In this example, the root Node A sources a prefix that 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.</t>

        <figure anchor="FigureCase2"
                title="Storing Mode with Subnet-Wide Prefix">
          <artwork><![CDATA[
                                                                     
                                                                     
                           +-------------+                           
                           |    Root     |                           
                           |             |                           
                           |   Node A    |                           
                           |    A::A     |                           
                           |             |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                                  |                                  
                           +------+------+                           
                           |             |                           
                           |   Node B    |                           
                           |    A::B     |                           
                           |             |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                   .--------------+--------------.                   
                  /                               \                  
                 /                                 \                 
         +------+------+                     +------+------+         
         |             |                     |             |         
         |   Node C    |                     |   Node D    |         
         |    A::C     |                     |    A::D     |         
         |             |                     |             |         
         +-------------+                     +-------------+         
                                                                     
                                                                     
]]></artwork>
        </figure>

        <section title="DIO Messages and PIO">
          <t>Node A, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Clear</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::B</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Clear</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::D</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="DAO Messages">
          <t>Node B will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target A::B/128</t>

              <t hangText="    o">Target A::C/128</t>

              <t hangText="    o">Target A::D/128</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will send DAO messages to Node B with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target A::C/128</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will send DAO messages to Node B with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target A::D/128</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="Routing Information Base">
          <t>Node A will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">A::A/128 connected</t>

              <t hangText="    o">A::B/128 via B's link local</t>

              <t hangText="    o">A::C/128 via B's link local</t>

              <t hangText="    o">A::D/128 via B's link local</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via A's link local</t>

              <t hangText="    o">A::B/128 connected</t>

              <t hangText="    o">A::C/128 via C's link local</t>

              <t hangText="    o">A::D/128 via D's link local</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">A::C/128 connected</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">A::D/128 connected</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section anchor="Case3"
               title="Example Operation in Non-Storing Mode with Node-Owned Prefixes">
        <t><xref target="FigureCase3"></xref> 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. &nbsp;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.</t>

        <figure anchor="FigureCase3"
                title="Non-Storing Mode with Node-Owned Prefixes">
          <artwork><![CDATA[
                                                                     
                                                                     
                           +-------------+                           
                           |    Root     |                           
                           |             |                           
                           |   Node A    |                           
                           |             |                           
                           |    A::A     |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                                  |                                  
                           +------+------+                           
                           |    A::B     |                           
                           |             |                           
                           |   Node B    |                           
                           |             |                           
                           |    B::B     |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                   .--------------+--------------.                   
                  /                               \                  
                 /                                 \                 
         +------+------+                     +------+------+         
         |    B::C     |                     |    B::D     |         
         |             |                     |             |         
         |   Node C    |                     |   Node D    |         
         |             |                     |             |         
         |    C::C     |                     |    D::D     |         
         +-------------+                     +-------------+         
                                                                     
                                                                     
]]></artwork>
        </figure>

        <section anchor="Case3DIO" title="DIO Messages and PIO">
          <t>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 (<xref
          target="Case1DIO"></xref>).</t>
        </section>

        <section title="DAO Messages">
          <t>Node B will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target B::/64, Transit A::B</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target C::/64, Transit B::C</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target D::/64, Transit B::D</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="Routing Information Base">
          <t>Node 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: <?rfc subcompact="yes"?><list
              style="hanging">
              <t hangText="    o">A::/64 connected</t>

              <t hangText="    o">B::/64 via A::B</t>

              <t hangText="    o">C::/64 via B::C</t>

              <t hangText="    o">D::/64 via B::D</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via A's link local</t>

              <t hangText="    o">B::/64 connected</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">C::/64 connected</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">D::/64 connected</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section anchor="Case4"
               title="Example Operation in Non-Storing Mode with Subnet-Wide Prefix">
        <t><xref target="FigureCase4"></xref> 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
        that 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
        publish their address within the Prefix field of the PIO, in order
        to inform their children which address to use in the transit
        option.</t>

        <figure anchor="FigureCase4"
                title="Non-Storing Mode with Subnet-Wide Prefix">
          <artwork><![CDATA[
                                                                     
                                                                     
                           +-------------+                           
                           |    Root     |                           
                           |             |                           
                           |   Node A    |                           
                           |    A::A     |                           
                           |             |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                                  |                                  
                           +------+------+                           
                           |             |                           
                           |   Node B    |                           
                           |    A::B     |                           
                           |             |                           
                           +------+------+                           
                                  |                                  
                                  |                                  
                   .--------------+--------------.                   
                  /                               \                  
                 /                                 \                 
         +------+------+                     +------+------+         
         |             |                     |             |         
         |   Node C    |                     |   Node D    |         
         |    A::C     |                     |    A::D     |         
         |             |                     |             |         
         +-------------+                     +-------------+         
                                                                     
                                                                     
]]></artwork>
        </figure>

        <section title="DIO Messages and PIO">
          <t>Node A, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::A</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::B</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::C</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D, for example, will send DIO messages with a PIO as
          follows: <?rfc subcompact="yes"?><list hangIndent="20"
              style="hanging">
              <t hangText="    'A' flag:">Set</t>

              <t hangText="    'L' flag:">Clear</t>

              <t hangText="    'R' flag:">Set</t>

              <t hangText="    Prefix Length:">64</t>

              <t hangText="    Prefix:">A::D</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="DAO Messages">
          <t>Node B will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target A::B/128, Transit A::A</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target A::C/128, Transit A::B</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will send DAO messages to Node A with the following
          information: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">Target A::D/128, Transit A::B</t>
            </list><?rfc subcompact="no"?></t>
        </section>

        <section title="Routing Information Base">
          <t>Node 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: <?rfc subcompact="yes"?><list
              style="hanging">
              <t hangText="    o">A::A/128 connected</t>

              <t hangText="    o">A::B/128 via A::A</t>

              <t hangText="    o">A::C/128 via A::B</t>

              <t hangText="    o">A::D/128 via A::B</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node B will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via A's link local</t>

              <t hangText="    o">A::B/128 connected</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node C will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">A::C/128 connected</t>
            </list><?rfc subcompact="no"?></t>

          <t>Node D will conceptually collect the following information into
          its RIB: <?rfc subcompact="yes"?><list style="hanging">
              <t hangText="    o">::/0 via B's link local</t>

              <t hangText="    o">A::D/128 connected</t>
            </list><?rfc subcompact="no"?></t>
        </section>
      </section>

      <section title="Example with External Prefixes">
        <t>Consider the simple network illustrated in <xref
        target="NetExample1"></xref>. In this example, there are a group of
        routers participating in a RPL network: a DODAG root, Nodes A, Y, and
        Z. &nbsp;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.</t>

        <figure anchor="NetExample1" title="Simple Network Example">
          <artwork><![CDATA[
                                                                     
                       RPL Network        +-------------------+      
                        RPL::/64          |                   |      
                                          |     External      |      
           [RPL::Root]    (Root)----------+      Prefix       |      
                            |             |    EXT_1::/64     |      
                            |             |                   |      
                            |             +-------------------+      
              [RPL::A]     (A)                                       
                            :                                        
                            :                                        
                            :                                        
              [RPL::Y]     (Y)                                       
                            |             +-------------------+      
                            |             |                   |      
                            |             |     External      |      
              [RPL::Z]     (Z)------------+      Prefix       |      
                            :             |    EXT_2::/64     |      
                            :             |                   |      
                            :             +-------------------+      
                                                                     
]]></artwork>
        </figure>

        <t>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.</t>

        <t>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.</t>

        <t>Similarly, Node Z has connectivity to an external prefix
        EXT_2::/64. Node Z also has a sub-DODAG underneath of it.</t>

        <t><list style="numbers">
            <t>The DODAG root adds a RIO to its DIO messages. The RIO contains
            the external prefix EXT_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 EXT_1::/64 is disseminated
            down the DODAG.</t>

            <t>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.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>