Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6550

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

Pages: 157
Proposed Standard
Updated by:  90089010
Part 5 of 6 – Pages 90 to 126
First   Prev   Next

Top   ToC   RFC6550 - Page 90   prevText

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   ToC   RFC6550 - 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

   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   ToC   RFC6550 - 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

   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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

   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   ToC   RFC6550 - 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
Top   ToC   RFC6550 - 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 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

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

   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

   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   ToC   RFC6550 - 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

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   ToC   RFC6550 - 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 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. 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   ToC   RFC6550 - 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

   This process is controlled by the Rank-Error bit associated with the
   packet.  When an inconsistency is detected on a packet, if the Rank-
   Error bit was not set, then the Rank-Error bit is set.  If it was set
   the packet MUST be discarded and the Trickle timer MUST be reset. DAO Inconsistency 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

   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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

   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

      *  Some OFs may include a test to compare the Ranks that would
         result if the node joined either router.
Top   ToC   RFC6550 - 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

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

      *  Candidate neighbors of a lesser Rank than the node are

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   ToC   RFC6550 - Page 109
      a RPL option for redistribution as an IPv6 ND option, any such
      padding octets should be restored.  This procedure must be

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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

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. 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

   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

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   ToC   RFC6550 - 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   ToC   RFC6550 - 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. 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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

Top   ToC   RFC6550 - Page 120

   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   ToC   RFC6550 - Page 121
      *  DIOIntervalMin [DIO message, in DODAG Configuration option]

      *  DIORedundancyConstant [DIO message, in DODAG Configuration

   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   ToC   RFC6550 - 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   ToC   RFC6550 - Page 123
   A RPL implementation SHOULD allow for the following parameters to be

   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   ToC   RFC6550 - 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

   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   ToC   RFC6550 - 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   ToC   RFC6550 - 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 Section