tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6550

 
 
 

RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

Part 5 of 6, p. 90 to 126
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 90 
10.  Security Mechanisms

   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.

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

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

10.1.  Security Overview

   RPL supports three security modes:

   o  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.

   o  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.

Top      Up      ToC       Page 91 
   o  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 Section 10.3.

   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.

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

   All secured RPL messages have either a 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.

10.2.  Joining a Secure Network

   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 Section 8, secure
   DIO and DIS messages have these rules:

   1.  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).

   2.  When a node resets its Trickle timer in response to a secure DIS
       (Section 8.3), the next DIO it transmits MUST be a secure DIO
       with the same security configuration as the secure DIS.  If a

Top      Up      ToC       Page 92 
       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.

   3.  When a node sends a DIO in response to a unicast secure DIS
       (Section 8.3), the DIO MUST be a secure DIO.

   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.

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

   1.  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.

   2.  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.

   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.

10.3.  Installing Keys

   Authenticated mode requires a would-be router to dynamically install
   new keys once they have joined a network as a host.  Having joined as
   a host, the node uses standard IP messaging to communicate with an
   authorization server, which can provide new keys.

   The protocol to obtain such keys is out of scope for this
   specification and to be elaborated in future specifications.  That
   elaboration is required for RPL to securely operate in authenticated
   mode.

Top      Up      ToC       Page 93 
10.4.  Consistency Checks

   RPL nodes send Consistency Check (CC) messages to protect against
   replay attacks and synchronize counters.

   1.  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.

   2.  If a node receives a multicast CC message, it MUST discard the
       message with no further processing.

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

10.5.  Counters

   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:

   1.  The timestamp MUST be at least six octets long.

   2.  The timestamp MUST be in 1024 Hz (binary millisecond)
       granularity.

   3.  The timestamp start time MUST be January 1, 1970, 12:00:00AM UTC.

   4.  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 > T < S, then the counter is
       invalid and a node MUST NOT generate a packet.  Otherwise, the
       counter value is equal to T-S.

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

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

Top      Up      ToC       Page 94 
   7.  If a node does not have a local timestamp that satisfies the
       above requirements, it MUST ignore the 'T' flag.

   If a node supports such timestamps and it receives a message with the
   'T' flag set, it MAY apply the temporal check on the received message
   described in Section 10.7.1.  If a node receives a message without
   the 'T' flag set, it MUST NOT apply this temporal check.  A node's
   security policy MAY, for application reasons, include rejecting all
   messages without the 'T' flag set.

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

10.6.  Transmission of Outgoing Packets

   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.

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

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

   The counter value used in constructing the AES-128 CCM nonce
   (Figure 31) to secure the outgoing packet MUST be an increment of the
   last counter transmitted to the particular destination address.

   Where security policy specifies the application of delay protection,
   the Timestamp counter used in constructing the CCM nonce to secure
   the outgoing packet MUST be incremented according to the rules in
   Section 10.5.  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.

Top      Up      ToC       Page 95 
   The cryptographic algorithm used in securing the outgoing packet
   shall be specified by the node's security policy database and MUST be
   indicated in the value of the Sec field set within the outgoing
   message.

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

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

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

10.7.  Reception of Incoming Packets

   This section describes the reception and processing of a secured RPL
   packet.  Given an incoming secured RPL packet, where the Security
   subfield bit of the RPL Message Code field is set, this section
   describes how RPL generates an unencrypted variant of the packet and
   validates its integrity.

   The receiver uses the RPL security control fields to determine the
   necessary packet security processing.  If the described level of
   security for the message type and originator is unknown or does not
   meet locally maintained security policies, a node MUST discard the
   packet without further processing, MAY raise a management alert, and
   MUST NOT send any messages in response.  These policies can include
   security levels, keys used, source identifiers, or the lack of
   timestamp-based counters (as indicated by the 'T' flag).  The
   configuration of the security policy database for incoming packet
   processing is out of scope for this specification (it may, for
   example, be defined through DIO Configuration or through out-of-band
   administrative router configuration).

   Where the message Security Level (LVL) indicates an encrypted RPL
   message, the node uses the key information identified through the KIM
   field as well as the CCM nonce as input to the message payload
   decryption processing.  The CCM nonce shall be derived from the

Top      Up      ToC       Page 96 
   message Counter field and other received and locally maintained
   information (see Section 10.9.1).  The plaintext message contents
   shall be obtained by invoking the inverse cryptographic mode of
   operation specified by the Sec field of the received packet.

   The receiver shall use the 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.

   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 Section 6.6) to the message source.  The Consistency Check
   response message shall be protected with the current full outgoing
   counter maintained for the particular node address.  That outgoing
   counter will be included within the security section of the message
   while the incoming counter will be included within the Consistency
   Check message payload.

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

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

   Once a message has been decrypted, where applicable, and has
   successfully passed its integrity check, replay 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.

Top      Up      ToC       Page 97 
   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.

10.7.1.  Timestamp Key Checks

   If the 'T' flag of a message is set and a node has a local timestamp
   that follows the requirements in Section 10.5, 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.

10.8.  Coverage of Integrity and Confidentiality

   For a RPL ICMPv6 message, the entire packet is within the scope of
   RPL security.

   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 [RFC4302] (IPsec Authenticated Header).  MAC and signature
   calculations are performed before any compression that lower layers
   may apply.

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

   For example, a node sending a message with LVL=1, KIM=0, and
   Algorithm=0 uses the CCM algorithm [RFC3610] 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 Section 10.9.1; 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.

Top      Up      ToC       Page 98 
10.9.  Cryptographic Mode of Operation

   The cryptographic mode of operation described in this specification
   (Algorithm = 0) is based on CCM and the block-cipher AES-128
   [RFC3610].  This mode of operation is widely supported by existing
   implementations.  CCM mode requires a nonce (CCM nonce).

10.9.1.  CCM Nonce

   A RPL node constructs a CCM nonce as follows:

        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 |
       +-+-+-+-+-+-+-+-+

                           Figure 31: CCM Nonce

   Source Identifier: 8 bytes.  Source Identifier is set to the logical
         identifier of the originator of the protected packet.

   Counter: 4 bytes.  Counter is set to the (uncompressed) value of the
         corresponding field in the Security option of the RPL control
         message.

   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.

   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.

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

   All fields of the CCM nonce are represented in most significant octet
   and most significant bit first order.

Top      Up      ToC       Page 99 
10.9.2.  Signatures

   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.
   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
   [RFC3447].  As public key, it uses the pair (n,e), where n is a
   2048-bit or 3072-bit RSA modulus and where e=2^{16}+1.  It uses CCM
   mode [RFC3610] as the encryption scheme with M=0 (as a stream-
   cipher).  Note that although [RFC3610] 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 [RFC3610], 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 [FIPS180].  It uses the message encoding rules of Section 8.1
   of [RFC3447].

   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.

   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.

   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.

11.  Packet Forwarding and Loop Avoidance/Detection

11.1.  Suggestions for Packet Forwarding

   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.

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

Top      Up      ToC       Page 100 
   1.  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.

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

   3.  If the packet header specifies a source route by including an RH4
       header as specified in [RFC6554], 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 Section 20.18).

   4.  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.

   5.  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.

   6.  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.

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

   8.  Finally, the packet is dropped.  ICMP Destination Unreachable MAY
       be invoked (an inconsistency is detected).

   Hop Limit MUST be decremented when forwarding per [RFC2460].

Top      Up      ToC       Page 101 
   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.

11.2.  Loop Avoidance and Detection

   RPL loop avoidance mechanisms are kept simple and designed to
   minimize churn and states.  Loops may form for a number of reasons,
   e.g., control packet loss.  RPL includes a reactive loop detection
   technique that protects from meltdown and triggers repair of broken
   paths.

   RPL loop detection uses RPL Packet Information that is transported
   within the data packets, relying on an external mechanism such as
   [RFC6553] that places in the RPL Packet Information in an IPv6 Hop-
   by-Hop option header.

   The content of RPL Packet Information is defined as follows:

   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.

   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.

   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.

   RPLInstanceID: 8-bit field indicating the DODAG instance along which
         the packet is sent.

   SenderRank: 16-bit field set to zero by the source and to
         DAGRank(rank) by a router that forwards inside the RPL network.

Top      Up      ToC       Page 102 
11.2.1.  Source Node Operation

   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.

11.2.2.  Router Operation

11.2.2.1.  Instance Forwarding

   The RPLInstanceID is associated by the source with the packet.  This
   RPLInstanceID MUST match the RPL Instance onto which the packet is
   placed by any node, be it a host or router.  The RPLInstanceID is
   part of the RPL Packet Information.

   A RPL router that forwards a packet in the RPL network MUST check if
   the packet includes the RPL Packet Information.  If not, then the RPL
   router MUST insert 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.

   A router that forwards a packet outside the RPL network MUST remove
   the RPL Packet Information.

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

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

11.2.2.2.  DAG Inconsistency Loop Detection

   The DODAG is inconsistent if the direction of a packet does not match
   the Rank relationship.  A receiver detects an inconsistency if it
   receives a packet with either:

      the 'O' bit set (to Down) from a node of a higher Rank.

      the 'O' bit cleared (for Up) from a node of a lower Rank.

Top      Up      ToC       Page 103 
   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.

   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.

   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.

11.2.2.3.  DAO Inconsistency Detection and Recovery

   DAO inconsistency loop recovery is a mechanism that applies to
   Storing mode of operation only.

   In Non-Storing mode, the packets are source routed to the
   destination, and DAO inconsistencies are not corrected locally.
   Instead, an ICMP error with a new code "Error in Source Routing
   Header" is sent back to the root.  The "Error in Source Routing
   Header" message has the same format as the "Destination Unreachable
   Message", as specified in [RFC4443].  The portion of the invoking
   packet that is sent back in the ICMP message should record at least
   up to the routing header, and the routing header should be consumed
   by this node so that the destination in the IPv6 header is the next
   hop that this node could not reach.

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

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

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

12.  Multicast Operation

   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.

   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.

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

   The multicast operation is controlled by the MOP field in the DIO.

   o  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.

Top      Up      ToC       Page 105 
   o  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).

   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.

   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.

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

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

13.  Maintenance of Routing Adjacency

   The selection of successors, along the default paths Up along the
   DODAG, or along the paths learned from destination advertisements
   Down along the DODAG, leads to the formation of routing adjacencies
   that require maintenance.

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

Top      Up      ToC       Page 106 
   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.

   Example reactive mechanisms that can be used include:

      The Neighbor Unreachability Detection [RFC4861] mechanism.

      Layer 2 triggers [RFC5184] derived from events such as association
      states and L2 acknowledgements.

14.  Guidelines for Objective Functions

   An Objective Function (OF), in conjunction with routing metrics and
   constraints, allows for the selection of a DODAG to join, and a
   number of peers in that DODAG as parents.  The OF is used to compute
   an ordered list of parents.  The OF is also responsible to compute
   the Rank of the device within the DODAG Version.

   The Objective Function is indicated in the DIO message using an
   Objective Code Point (OCP), and it indicates the method that must be
   used to construct the DODAG.  The Objective Code Points are specified
   in [RFC6552] and related companion specifications.

14.1.  Objective Function Behavior

   Most Objective Functions are expected to follow the same abstract
   behavior at a node:

   o  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.

   o  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,

Top      Up      ToC       Page 107 
      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.

   o  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.

   o  An OF computes Rank of a node for comparison by adding to the Rank
      of the candidate a value representing the relative locations of
      the node and the candidate in the DODAG Version.

      *  The increase in Rank must be at least MinHopRankIncrease.

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

      *  Candidate neighbors that would cause the Rank of the node to
         increase are not considered for parent selection.

   o  Candidate neighbors that advertise an OF incompatible with the set
      of OFs specified by the policy functions are ignored.

   o  As it scans all the candidate neighbors, the OF keeps the current
      best parent and compares its capabilities with the current
      candidate neighbor.  The OF defines a number of tests that are
      critical to reach the objective.  A test between the routers
      determines an order relation.

      *  If the routers are equal for that relation, then the next test
         is attempted between the routers,

      *  Else the best of the two routers becomes the current best
         parent, and the scan continues with the next candidate
         neighbor.

      *  Some OFs may include a test to compare the Ranks that would
         result if the node joined either router.

Top      Up      ToC       Page 108 
   o  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.

   o  Other rounds of scans might be necessary to elect alternate
      parents.  In the next rounds:

      *  Candidate neighbors that are not in the same DODAG are ignored.

      *  Candidate neighbors that are of greater Rank than the node are
         ignored.

      *  Candidate neighbors of an equal Rank to the node are ignored
         for parent selection.

      *  Candidate neighbors of a lesser Rank than the node are
         preferred.

15.  Suggestions for Interoperation with Neighbor Discovery

   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.

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

   In general, the following guidelines apply:

   o  RPL Type codes must be allocated from the RPL Control Message
      Options registry.

   o  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.

   o  RPL options are generally not required to be aligned to 8-octet
      boundaries.

   o  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

Top      Up      ToC       Page 109 
      a RPL option for redistribution as an IPv6 ND option, any such
      padding octets should be restored.  This procedure must be
      unambiguous.

16.  Summary of Requirements for Interoperable Implementations

   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.

   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.

16.1.  Common Requirements

   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.

   All RPL implementations need to support the use of RPL Packet
   Information transported within data packets (Section 11.2).  One such
   mechanism is described in [RFC6553].

   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 (Section 8.2.1).
   Alternate mechanisms may be optimized to the constrained capabilities
   of the implementation, such as hints from the link layer.

   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 [RFC4861] or 6LoWPAN ND
   [6LOWPAN-ND].

Top      Up      ToC       Page 110 
16.2.  Operation as a RPL Leaf Node (Only)

   o  An implementation of a leaf node (only) does not ever participate
      as a RPL router.  Interoperable implementations of leaf nodes
      behave as summarized in Section 8.5.

   o  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.

   o  Support of a particular OF is not required.

   o  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.

16.3.  Operation as a RPL Router

   If further guidance is not available then a RPL router implementation
   MUST at least support the metric-less OF0 [RFC6552].

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

   All RPL routers will need to implement Trickle [RFC6206].

16.3.1.  Support for Upward Routes (Only)

   An implementation of a RPL router that supports only Upward routes
   supports the following:

   o  Upward routes (Section 8)

   o  MOP encoding 0 (Section 20.3)

   o  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.

16.3.2.  Support for Upward Routes and Downward Routes in Non-Storing
         Mode

   An implementation of a RPL router that supports Upward routes and
   Downward routes in Non-Storing mode supports the following:

   o  Upward routes (Section 8)

Top      Up      ToC       Page 111 
   o  Downward routes (Non-Storing) (Section 9)

   o  MOP encoding 1 (Section 20.3)

   o  Source-routed Downward traffic ([RFC6554])

   o  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.

16.3.3.  Support for Upward Routes and Downward Routes in Storing Mode

   An implementation of a RPL router that supports Upward routes and
   Downward routes in Storing mode supports the following:

   o  Upward routes (Section 8)

   o  Downward routes (Storing) (Section 9)

   o  MOP encoding 2 (Section 20.3)

   o  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.

16.3.3.1.  Optional Support for Basic Multicast Scheme

   A Storing mode implementation may be enhanced with basic multicast
   support through the following additions:

   o  Basic Multicast Support (Section 12)

   o  MOP encoding 3 (Section 20.3)

16.4.  Items for Future Specification

   A number of items are left to future specification, including but not
   limited to the following:

   o  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.

Top      Up      ToC       Page 112 
   o  How to obtain authentication material in support if authenticated
      mode is used (Section 10.3).

   o  Details of operation over multiple simultaneous instances.

   o  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).

17.  RPL Constants and Variables

   The following is a summary of RPL constants and variables:

   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.

   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.

   INFINITE_RANK: This is the constant maximum for the Rank.
         INFINITE_RANK has a value of 0xFFFF.

   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.

   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.

   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.

   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.

Top      Up      ToC       Page 113 
   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.

   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.

   DEFAULT_DAO_DELAY: This is the default value for the DelayDAO Timer.
         DEFAULT_DAO_DELAY has a value of 1 second.  See Section 9.5.

   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 Section 8.3.1

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

   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 Section 9.5

   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.

18.  Manageability Considerations

   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 [RFC5706].

Top      Up      ToC       Page 114 
18.1.  Introduction

   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.

   For a number of protocols, the IETF community has used the IETF
   Standard Management Framework, including the Simple Network
   Management Protocol [RFC3410], the Structure of Management
   Information [RFC2578], and MIB data models for managing new
   protocols.

   As pointed out in [RFC5706], the common policy in terms of operation
   and management has been expanded to a policy that is more open to a
   set of tools and management protocols rather than strictly relying on
   a single protocol such as SNMP.

   In 2003, the Internet Architecture Board (IAB) held a workshop on
   Network Management [RFC3535] that discussed the strengths and
   weaknesses of some IETF network management protocols and compared
   them to operational needs, especially configuration.

   One issue discussed was the user-unfriendliness of the binary format
   of SNMP [RFC3410].  In the case of LLNs, it must be noted that at the
   time of writing, the CoRE working group is actively working on
   resource management of devices in LLNs.  Still, it is felt that this
   section provides important guidance on how RPL should be deployed,
   operated, and managed.

   As stated in [RFC5706]:

      A management information model should include a discussion of what
      is manageable, which aspects of the protocol need to be
      configured, what types of operations are allowed, what protocol-
      specific events might occur, which events can be counted, and for
      which events an operator should be notified.

   These aspects are discussed in detail in the following sections.

   RPL will be used on a variety of devices that may have resources such
   as memory varying from a few 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.

Top      Up      ToC       Page 115 
18.2.  Configuration Management

   This section discusses the configuration management, listing the
   protocol parameters for which configuration management is relevant.

   Some of the RPL parameters are optional.  The requirements for
   configuration are only applicable for the options that are used.

18.2.1.  Initialization Mode

   "Architectural Principles of the Internet" [RFC1958], 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.

18.2.1.1.  DIS Mode of Operation upon Boot-Up

   When a node is first powered up:

   1.  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.

   2.  The node may decide to send one or more DIS messages (optionally,
       requesting DIO for a specific DODAG) as an initial probe for
       nearby DODAGs, and in the absence of DIO messages in reply after
       some configurable period of time, the node may decide to root a
       floating DODAG and start sending multicast DIO messages.

   A RPL implementation SHOULD allow configuring the preferred mode of
   operation listed above along with the required parameters (in the
   second mode: the number of DIS messages and related timer).

18.2.2.  DIO and DAO Base Message and Options Configuration

   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

Top      Up      ToC       Page 116 
   number of the default values can be used, and when required these
   parameters can be provided by the DODAG root thus allowing for
   dynamic parameter setting.

   A RPL implementation SHOULD allow configuring the following routing
   protocol parameters.  As pointed out above, note that a large set of
   parameters is configured on the DODAG root.

18.2.3.  Protocol Parameters to Be Configured on Every Router in the LLN

   A RPL implementation MUST allow configuring the following RPL
   parameters:

   o  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.

   o  List of supported Objective Code Points (OCPs)

   o  List of supported metrics: [RFC6551] 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 Section 8.5, the node would join as a leaf node.

   o  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.

   o  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.

   o  'K' flag: when a node should set the 'K' flag in a DAO message
      [DAO message, in DAO Base message].

   o  MOP (Mode of Operation) [DIO message, in DIO Base message].

Top      Up      ToC       Page 117 
   o  Route Information (and preference) [DIO message, in Route
      Information option]

18.2.4.  Protocol Parameters to Be Configured on Every Non-DODAG-Root
         Router in the LLN

   A RPL implementation MUST allow configuring the Target prefix [DAO
   message, in RPL Target option].

   Furthermore, there are circumstances where a node may want to
   designate a Target to allow for specific processing of the Target
   (prioritization, 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).

   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:

   o  Start its own (floating) DODAG: the new DODAGID must be configured
      in addition to its DAGPreference.

   o  Poison the broken path (see procedure in Section 8.2.2.5).

   o  Trigger a local repair.

18.2.5.  Parameters to Be Configured on the DODAG Root

   In addition, several other parameters are configured only on the
   DODAG root and advertised in options carried in DIO messages.

   As specified in Section 8.3, 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.

   o  DIOIntervalDoublings [DIO message, in DODAG Configuration option]

   o  DIOIntervalMin [DIO message, in DODAG Configuration option]

   o  DIORedundancyConstant [DIO message, in DODAG Configuration option]

   In addition, a RPL implementation SHOULD allow for configuring the
   following set of RPL parameters:

Top      Up      ToC       Page 118 
   o  Path Control Size [DIO message, in DODAG Configuration option]

   o  MinHopRankIncrease [DIO message, in DODAG Configuration option]

   o  The DODAGPreference field [DIO message, DIO Base object]

   o  DODAGID [DIO message, in DIO Base option] and [DAO message, when
      the 'D' flag of the DAO message is set]

   DAG root behavior: in some cases, a node may not want to permanently
   act as a floating DODAG root if it cannot join a grounded DODAG.  For
   example, a battery-operated node may not want to act as a floating
   DODAG root for a long period of time.  Thus, a RPL implementation MAY
   support the ability to configure whether or not a node could act as a
   floating DODAG root for a configured period of time.

   DAG Version Number Increment: a RPL implementation may allow, by
   configuration at the DODAG root, 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 Section 3.2.2).

18.2.6.  Configuration of RPL Parameters Related to DAO-Based Mechanisms

   DAO messages are optional and used in DODAGs that require Downward
   routing operation.  This section deals with the set of parameters
   related to DAO messages and provides recommendations on their
   configuration.

   As stated in Section 9.5, it is recommended to delay the sending of
   DAO message to DAO parents in order to maximize the chances to
   perform route aggregation.  Upon receiving a DAO message, the node
   should thus start a DelayDAO timer.  The default value is
   DEFAULT_DAO_DELAY.  A RPL implementation MAY allow for configuring
   the DelayDAO timer.

   In a Storing mode of operation, a storing node may increment DTSN in
   order to reliably trigger a set of DAO updates from its immediate
   children, as part of routine routing table updates and maintenance.
   A RPL implementation MAY allow for configuring a set of rules
   specifying the triggers for DTSN increment (manual or event-based).

   When a DAO entry times out or is invalidated, a node SHOULD make a
   reasonable attempt to report a No-Path to each of the DAO parents.
   That number of attempts MAY be configurable.

Top      Up      ToC       Page 119 
   An implementation should support rate-limiting the sending of DAO
   messages.  The related parameters MAY be configurable.

18.2.7.  Configuration of RPL Parameters Related to Security Mechanisms

   As described in Section 10, the security features described in this
   document are optional to implement and a given implementation may
   support a subset (including the empty set) of the described security
   features.

   To this end, an implementation supporting described security features
   may conceptually implement a security policy database.  In support of
   the security mechanisms, a RPL implementation SHOULD allow for
   configuring a subset of the following parameters:

   o  Security Modes accepted [Unsecured mode, Preinstalled mode,
      Authenticated mode]

   o  KIM values accepted [Secure RPL control messages, in Security
      section]

   o  Level values accepted [Secure RPL control messages, in Security
      section]

   o  Algorithm values accepted [Secure RPL control messages, in
      Security section]

   o  Key material in support of Authenticated or Preinstalled key
      modes.

   In addition, a RPL implementation SHOULD allow for configuring a
   DODAG root with a subset of the following parameters:

   o  Level values advertised [Secure DIO message, in Security section]

   o  KIM value advertised [Secure DIO message, in Security section]

   o  Algorithm value advertised [Secure DIO message, in Security
      section]

18.2.8.  Default Values

   This document specifies default values for the following set of RPL
   variables:
      DEFAULT_PATH_CONTROL_SIZE
      DEFAULT_DIO_INTERVAL_MIN
      DEFAULT_DIO_INTERVAL_DOUBLINGS
      DEFAULT_DIO_REDUNDANCY_CONSTANT

Top      Up      ToC       Page 120 
      DEFAULT_MIN_HOP_RANK_INCREASE
      DEFAULT_DAO_DELAY

   It is recommended to specify default values in protocols; that being
   said, as discussed in [RFC5706], 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.

   The proposed values are not based on extensive best current practices
   and are considered to be conservative.

18.3.  Monitoring of RPL Operation

   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.

18.3.1.  Monitoring a DODAG Parameters

   A RPL implementation SHOULD provide information about the following
   parameters:

   o  DODAG Version number [DIO message, in DIO Base message]

   o  Status of the 'G' flag [DIO message, in DIO Base message]

   o  Status of the MOP field [DIO message, in DIO Base message]

   o  Value of the DTSN [DIO message, in DIO Base message]

   o  Value of the Rank [DIO message, in DIO Base message]

   o  DAOSequence: Incremented at each unique DAO message, echoed in the
      DAO-ACK message [DAO and DAO-ACK messages]

   o  Route Information [DIO message, Route Information Option] (list of
      IPv6 prefixes per parent along with lifetime and preference]

   o  Trickle parameters:

      *  DIOIntervalDoublings [DIO message, in DODAG Configuration
         option]

Top      Up      ToC       Page 121 
      *  DIOIntervalMin [DIO message, in DODAG Configuration option]

      *  DIORedundancyConstant [DIO message, in DODAG Configuration
         option]

   o  Path Control Size [DIO message, in DODAG Configuration option]

   o  MinHopRankIncrease [DIO message, in DODAG Configuration option]

   Values that may be monitored only on the DODAG root:

   o  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.

18.3.2.  Monitoring a DODAG Inconsistencies and Loop Detection

   Detection of DODAG inconsistencies is particularly critical in RPL
   networks.  Thus, it is recommended for a RPL implementation to
   provide appropriate monitoring tools.  A RPL implementation SHOULD
   provide a counter reporting the number of a times the node has
   detected an inconsistency with respect to a DODAG parent, e.g., if
   the DODAGID has changed.

   When possible more granular information about inconsistency detection
   should be provided.  A RPL implementation MAY provide counters
   reporting the number of following inconsistencies:

   o  Packets received with 'O' bit set (to Down) from a node with a
      higher Rank

   o  Packets received with 'O' bit cleared (to Up) from a node with a
      lower Rank

   o  Number of packets with the 'F' bit set

   o  Number of packets with the 'R' bit set

18.4.  Monitoring of the RPL Data Structures

18.4.1.  Candidate Neighbor Data Structure

   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

Top      Up      ToC       Page 122 
   to allow for the candidate neighbor list to be monitored with some
   metric reflecting local confidence (the degree of stability of the
   neighbors) as measured by some metrics.

   A RPL implementation MAY provide a counter reporting the number of
   times a candidate neighbor has been ignored, should the number of
   candidate neighbors exceed the maximum authorized value.

18.4.2.  Destination-Oriented Directed Acyclic Graph (DODAG) Table

   For each DODAG, a RPL implementation is expected to keep track of the
   following DODAG table values:

   o  RPLInstanceID

   o  DODAGID

   o  DODAGVersionNumber

   o  Rank

   o  Objective Code Point

   o  A set of DODAG parents

   o  A set of prefixes offered Upward along the DODAG

   o  Trickle timers used to govern the sending of DIO messages for the
      DODAG

   o  List of DAO parents

   o  DTSN

   o  Node status (router versus leaf)

   A RPL implementation SHOULD allow for monitoring the set of
   parameters listed above.

18.4.3.  Routing Table and DAO Routing Entries

   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.

Top      Up      ToC       Page 123 
   A RPL implementation SHOULD allow for the following parameters to be
   monitored:

   o  Next Hop (DODAG parent)

   o  Next Hop Interface

   o  Path metrics value for each DODAG parent

   A DAO Routing Table entry conceptually contains the following
   elements (for storing nodes only):

   o  Advertising Neighbor Information

   o  IPv6 address

   o  Interface ID to which DAO parents has this entry been reported

   o  Retry counter

   o  Logical equivalent of DAO Content:

      *  DAO-Sequence

      *  Path Sequence

      *  DAO Lifetime

      *  DAO Path Control

   o  Destination Prefix (or address or Mcast Group)

   A RPL implementation SHOULD provide information about the state of
   each DAO Routing Table entry states.

18.5.  Fault Management

   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:

   o  Memory overflow along with the cause (e.g., routing tables
      overflow, etc.)

   o  Number of times a packet could not be sent to a DODAG parent
      flagged as valid

Top      Up      ToC       Page 124 
   o  Number of times a packet has been received for which the router
      did not have a corresponding RPLInstanceID

   o  Number of times a local repair procedure was triggered

   o  Number of times a global repair was triggered by the DODAG root

   o  Number of received malformed messages

   o  Number of seconds with packets to forward and no next hop (DODAG
      parent)

   o  Number of seconds without next hop (DODAG parent)

   o  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
      Section 18.6)

   It is RECOMMENDED to report faults via at least error log messages.
   Other protocols may be used to report such faults.

18.6.  Policy

   Policy rules can be used by a RPL implementation to determine whether
   or not the node is allowed to join a particular DODAG advertised by a
   neighbor by means of DIO messages.

   This document specifies operation within a single DODAG.  A DODAG is
   characterized by the following tuple (RPLInstanceID, DODAGID).
   Furthermore, as pointed out above, DIO messages are used to advertise
   other DODAG characteristics such as the routing metrics and
   constraints used to build to the DODAG and the Objective Function in
   use (specified by OCP).

   The first policy rules consist of specifying the following conditions
   that a RPL node must satisfy to join a DODAG:

   o  RPLInstanceID

   o  List of supported routing metrics and constraints

   o  Objective Function (OCP values)

   A RPL implementation MUST allow configuring these parameters and
   SHOULD specify whether the node must simply ignore the DIO if the
   advertised DODAG is not compliant with the local policy or whether
   the node should join as the leaf node if only the list of supported

Top      Up      ToC       Page 125 
   routing metrics and constraints, and the OF is not supported.
   Additionally, a RPL implementation SHOULD allow for the addition of
   the DODAGID as part of the policy.

   A RPL implementation SHOULD allow configuring the set of acceptable
   or preferred Objective Functions (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:

   o  The node joins the DODAG as a leaf node as specified in
      Section 8.5.

   o  The node does not join the DODAG.

   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.

   Internal Data Structures: some RPL implementations may limit the size
   of the candidate neighbor list in order to bound the memory usage; in
   which case, some otherwise viable candidate neighbors may not be
   considered and simply dropped from the candidate neighbor list.

   A RPL implementation MAY provide an indicator on the size of the
   candidate neighbor list.

18.7.  Fault Isolation

   It is RECOMMENDED to quarantine neighbors that start emitting
   malformed messages at unacceptable rates.

18.8.  Impact on Other Protocols

   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.

Top      Up      ToC       Page 126 
   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 (Section 8.3).  Thus, the impact of RPL on other
   protocols should be extremely limited.

18.9.  Performance Management

   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:

   o  Number of repairs and time to repair in seconds (average,
      variance)

   o  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

   o  Monitoring of resources consumption by RPL in terms of bandwidth
      and required memory

   o  Number of RPL control messages sent and received

18.10.  Diagnostics

   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.



(page 126 continued on part 6)

Next RFC Part