RFC 6550
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
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.
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
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.
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.
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.
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
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.
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.
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.
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:
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].
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.
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.
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.
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.
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.
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,
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.
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
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].
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)
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.
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.
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].
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.
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
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].
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:
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.
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
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]
* 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
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.
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
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
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.
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 received18.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)
