--- 1/draft-ietf-roll-rpl-13.txt 2010-10-26 01:16:43.000000000 +0200 +++ 2/draft-ietf-roll-rpl-14.txt 2010-10-26 01:16:43.000000000 +0200 @@ -1,35 +1,35 @@ ROLL T. Winter, Ed. Internet-Draft Intended status: Standards Track P. Thubert, Ed. -Expires: April 25, 2011 Cisco Systems +Expires: April 28, 2011 Cisco Systems A. Brandt Sigma Designs T. Clausen LIX, Ecole Polytechnique J. Hui Arch Rock Corporation R. Kelsey Ember Corporation P. Levis Stanford University K. Pister Dust Networks R. Struik JP. Vasseur Cisco Systems - October 22, 2010 + October 25, 2010 RPL: IPv6 Routing Protocol for Low power and Lossy Networks - draft-ietf-roll-rpl-13 + draft-ietf-roll-rpl-14 Abstract Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices @@ -51,21 +51,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 25, 2011. + This Internet-Draft will expire on April 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -97,28 +97,28 @@ 3.4. Downward Routes and Destination Advertisement . . . . . 17 3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 18 3.6. Rank Properties . . . . . . . . . . . . . . . . . . . . 18 3.6.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 19 3.6.2. Rank Relationships . . . . . . . . . . . . . . . . . 20 3.7. Routing Metrics and Constraints Used By RPL . . . . . . 20 3.8. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 22 3.8.1. Greediness and Instability . . . . . . . . . . . . . 22 3.8.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 24 3.8.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 24 - 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 25 - 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 25 - 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 25 - 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 25 - 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 26 - 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 26 - 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 28 - 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 30 + 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 26 + 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 26 + 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 26 + 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 26 + 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 27 + 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 29 + 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 31 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 35 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 35 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 35 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 35 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 36 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 36 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 38 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 38 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 38 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 38 @@ -135,21 +135,21 @@ 6.7. RPL Control Message Options . . . . . . . . . . . . . . 43 6.7.1. RPL Control Message Option Generic Format . . . . . . 43 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 44 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 45 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 45 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 46 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 48 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 49 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 51 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 54 - 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 56 + 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 55 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 58 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 60 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 60 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 61 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 63 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 63 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 63 8.2.1. Neighbors and Parents within a DODAG Version . . . . 63 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 64 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 69 @@ -217,60 +217,58 @@ 17.3.2. Monitoring a DODAG inconsistencies and loop detection . . . . . . . . . . . . . . . . . . . . . . 115 17.4. Monitoring of the RPL data structures . . . . . . . . . 116 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 116 17.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table . . . . . . . . . . . . . . . . . . . . . . . . 116 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118 - 17.7. Liveness Detection and Monitoring . . . . . . . . . . . 119 - 17.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 120 - 17.9. Impact on Other Protocols . . . . . . . . . . . . . . . 120 - 17.10. Performance Management . . . . . . . . . . . . . . . . . 120 - 17.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 121 - 18. Security Considerations . . . . . . . . . . . . . . . . . . . 122 - 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 122 - 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 - 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 124 - 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 124 - 19.3. New Registry for the Mode of Operation (MOP) DIO - Control Field . . . . . . . . . . . . . . . . . . . . . 125 - 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 126 - 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 126 - 19.6. New Registry for the Security Section Algorithm . . . . 127 - 19.7. New Registry for the Security Section Flags . . . . . . 127 - 19.8. New Registry for the Key Identification Mode . . . . . . 128 - 19.9. New Registry for the KIM levels . . . . . . . . . . . . 128 + 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 119 + 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 120 + 17.9. Performance Management . . . . . . . . . . . . . . . . . 120 + 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 120 + 18. Security Considerations . . . . . . . . . . . . . . . . . . . 121 + 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 121 + 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 + 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 123 + 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 123 + 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 124 + 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 125 + 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 125 + 19.6. New Registry for the Security Section Algorithm . . . . 126 + 19.7. New Registry for the Security Section Flags . . . . . . 126 + 19.8. New Registry for the Key Identification Mode . . . . . . 127 + 19.9. New Registry for the KIM levels . . . . . . . . . . . . 127 19.10. New Registry for the DIS (DODAG Informational - Solicitation) Flags . . . . . . . . . . . . . . . . . . 129 + Solicitation) Flags . . . . . . . . . . . . . . . . . . 128 19.11. New Registry for the DODAG Information Object (DIO) - Flags . . . . . . . . . . . . . . . . . . . . . . . . . 130 + Flags . . . . . . . . . . . . . . . . . . . . . . . . . 129 19.12. New Registry for the Destination Advertisement Object - (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 130 + (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 129 19.13. New Registry for the Destination Advertisement Object - (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 131 - 19.14. New Registry for the Consistency Check (CC) Flags . . . 131 - 19.15. New Registry for the DODAG Configuration Option Flags . 132 - 19.16. New Registry for the RPL Target Option Flags . . . . . . 132 - 19.17. New Registry for the Transit Information Option Flags . 133 + (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 130 + 19.14. New Registry for the Consistency Check (CC) Flags . . . 130 + 19.15. New Registry for the DODAG Configuration Option Flags . 131 + 19.16. New Registry for the RPL Target Option Flags . . . . . . 131 + 19.17. New Registry for the Transit Information Option Flags . 132 19.18. New Registry for the Solicited Information Option - Flags . . . . . . . . . . . . . . . . . . . . . . . . . 133 - 19.19. ICMPv6: Error in Source Routing Header . . . . . . . . . 134 - 19.20. Link-Local Scope multicast address . . . . . . . . . . . 134 - 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 135 - 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 136 - 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 - 22.1. Normative References . . . . . . . . . . . . . . . . . . 137 - 22.2. Informative References . . . . . . . . . . . . . . . . . 138 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 + Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132 + 19.19. ICMPv6: Error in Source Routing Header . . . . . . . . . 133 + 19.20. Link-Local Scope multicast address . . . . . . . . . . . 133 + 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 134 + 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 135 + 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 136 + 22.1. Normative References . . . . . . . . . . . . . . . . . . 136 + 22.2. Informative References . . . . . . . . . . . . . . . . . 137 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 1. Introduction Low power and Lossy Networks (LLNs) consist of largely of constrained nodes (with limited processing power, memory, and sometimes energy when they are battery operated or energy scavenging). These routers are interconnected by lossy links, typically supporting only low data rates, that are usually unstable with relatively low packet delivery rates. Another characteristic of such networks is that the traffic patterns are not simply point-to-point, but in many cases point-to- @@ -299,20 +297,37 @@ In order to be useful in a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objective. Examples of such objectives include minimizing energy, minimizing latency, or satisfying constraints. This document describes the mode of operation of RPL. Other companion documents specify routing objective functions. A RPL implementation, in support of a particular LLN application, will include the necessary objective function(s) as required by the application. + RPL operations require bidirectional links. RPL expects an external + mechanism to verify link properties and neighbor reachability. + Neighbor Unreachability Detection (NUD) is an example such a + mechanism, but alternates are possible, such as L2 triggers. + + RPL provides a mechanism to disseminate information, in particular a + prefix shared within a subnet. When this is used, one or more + routers own a prefix and are authoritative for generating its + advertisements. Other routers propagate the prefix information + without changing the prefix or the associated control information. + This capability of announcing the subnet prefix is not to be confused + with route advertisements, and this mechanism does not by any means + constrain RPL operations to within a subnet. Routers that own + prefixes can also benefit from RPL to form a larger routed structures + whereby each router announces its prefixes to its peers in the + network. + A set of companion documents to this specification will provide further guidance in the form of applicability statements specifying a set of operating points appropriate to the Building Automation, Home Automation, Industrial, and Urban application scenarios. 1.2. Expectations of Link Layer Type In compliance with the layered architecture of IP, RPL does not rely on any particular features of a specific link layer technology. RPL is designed to be able to operate over a variety of different link @@ -343,30 +358,33 @@ DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition all DAGs must have at least one DAG root and all paths terminate at a DAG root. Destination Oriented DAG (DODAG): A DAG rooted at a single destination, i.e. at a single DAG root (the DODAG root) with no outgoing edges. - DODAG root: A DODAG root is the DAG root of a DODAG. + DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root + may act as a border router for the DODAG, and in particular it + may aggregate routes in the DODAG, and may redistribute DODAG + routes into other routing protocols. Virtual DODAG root: A Virtual DODAG root is the result of two or - more RPL routers, most typically LBRs, coordinating to - synchronize DODAG state and act in concert as if they are a - single DODAG root (with multiple interfaces), with respect to - the LLN. The coordination most likely occurs between powered - devices over a reliable transit link, and the details of that - scheme are out of scope for this specification (to be defined - in future companion specifications). + more RPL routers, for instance 6LoWPAN Border Routers (6LBRs), + coordinating to synchronize DODAG state and act in concert as + if they are a single DODAG root (with multiple interfaces), + with respect to the LLN. The coordination most likely occurs + between powered devices over a reliable transit link, and the + details of that scheme are out of scope for this specification + (to be defined in future companion specifications). Up: Up refers to the direction from leaf nodes towards DODAG roots, following DODAG edges. This follows the common terminology used in graphs and depth-first-search, where vertices further from the root are "deeper," or "down," and vertices closer to the root are "shallower," or "up". Down: Down refers to the direction from DODAG roots towards leaf nodes, in the reverse direction of DODAG edges. This follows the common terminology used in graphs and depth-first-search, @@ -673,25 +691,29 @@ 3.3.6. Administrative Preference An implementation/deployment may specify that some DODAG roots should be used over others through an administrative preference. Administrative preference offers a way to control traffic and engineer DODAG formation in order to better support application requirements or needs. 3.3.7. Datapath Validation and Loop Detection - RPL carries routing information in a RPL Option contained in an IPv6 - Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-option]. Such - routing information is used, for example, for loop detection within a - DODAG as discussed in Section 11.2 and may be extended in future - specifications for additional features. + RPL often needs to carry control information in data packets. This + information is used to validate the routing states as discussed in + Section 11.2. The only exception is when strict source routing is + used for packets going downward in non-storing mode (detailed further + in Section 9), which by nature prevents endless loops and alleviates + the need for the control information. + + RPL control information may be extended to add additional features in + future companion specifications. The low-power and lossy nature of LLNs motivates RPL's use of on- demand loop detection using data packets. Because data traffic can be infrequent, maintaining a routing topology that is constantly up to date with the physical topology can waste energy. Typical LLNs exhibit variations in physical connectivity that are transient and innocuous to traffic, but that would be costly to track closely from the control plane. Transient and infrequent changes in connectivity need not be addressed by RPL until there is data to send. This aspect of RPL's design draws from existing, highly used LLN protocols @@ -1328,36 +1349,32 @@ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Security Section Message authentication codes (MACs) and signatures cover the entire ICMPv6 RPL message, while encryption starts after the Security section. Use of the Security section is further detailed in Section 18 and Section 10. - Security Control Field: The Security Control Field has one flag and - three fields: - - Counter is Time (T): If the Counter is Time flag is set then - the Counter field is a timestamp. If the flag is cleared - then the Counter is an incrementing counter. - Section 10.5 describes the details of the 'T' flag and - Counter field. + Counter is Time (T): If the Counter is Time flag is set then the + Counter field is a timestamp. If the flag is cleared then the + Counter is an incrementing counter. Section 10.5 describes the + details of the 'T' flag and Counter field. Security Level (Level): The Security Level field indicates the - provided packet protection. This value can be adapted on - a per-packet basis and allows for varying levels of data - authenticity and, optionally, for data confidentiality. - The KIM field indicates whether signatures are used and - the meaning of the Level field. The Security Level is - set to one of the values in the tables below: + provided packet protection. This value can be adapted on a + per-packet basis and allows for varying levels of data + authenticity and, optionally, for data confidentiality. The + KIM field indicates whether signatures are used and the meaning + of the Level field. The Security Level is set to one of the + values in the tables below: +---------------------------+ | KIM=0,1,2 | +-------+--------------------+------+ | LVL | Attributes | MAC | | | | Len | +-------+--------------------+------+ | 0 | MAC-32 | 4 | | 1 | ENC-MAC-32 | 4 | | 2 | MAC-64 | 8 | @@ -1371,48 +1388,46 @@ | LVL | Attributes | Sig | | | | Len | +-------+---------------+-----+ | 0 | Sign-3072 | 384 | | 1 | ENC-Sign-3072 | 384 | | 2-127 | Unassigned | N/A | +-------+---------------+-----+ Figure 9: Security Level (LVL) Encoding - The MAC attribute indicates that the message has a - Message Authentication Code of the specified length. The - ENC attribute indicates that the message is encrypted. - The Sign attribute indicates that the message has a - signature of the specified length. + The MAC attribute indicates that the message has a Message + Authentication Code of the specified length. The ENC attribute + indicates that the message is encrypted. The Sign attribute + indicates that the message has a signature of the specified + length. Security Algorithm (Algorithm): The Security Algorithm field - specifies the encryption, MAC, and signature scheme the - network uses. Supported values of this field are as - follows: + specifies the encryption, MAC, and signature scheme the network + uses. Supported values of this field are as follows: +-----------+-------------------+------------------------+ | Algorithm | Encryption/MAC | Signature | +-----------+-------------------+------------------------+ | 0 | CCM with AES-128 | RSA with SHA2 | | 1-255 | Unassigned | Unassigned | +-------+-------------------+----------------------------+ Figure 10: Security Algorithm (Algorithm) Encoding Section 10.9 describes the algorithms in greater detail. - Key Identifier Mode (KIM): The Key Identifier Mode field - indicates whether the key used for packet protection is - determined implicitly or explicitly and indicates the - particular representation of the Key Identifier field. - The Key Identifier Mode is set one of the values from the - table below: + Key Identifier Mode (KIM): The Key Identifier Mode field indicates + whether the key used for packet protection is determined + implicitly or explicitly and indicates the particular + representation of the Key Identifier field. The Key Identifier + Mode is set one of the values from the table below: +------+-----+-----------------------------+------------+ | Mode | KIM | Meaning | Key | | | | | Identifier | | | | | Length | | | | | (octets) | +------+-----+-----------------------------+------------+ | 0 | 00 | Group key used. | 1 | | | | Key determined by Key Index | | | | | field. | | @@ -1437,29 +1452,27 @@ | 3 | 11 | Node's signature key used. | 0/9 | | | | If packet is encrypted, | | | | it uses a group key, Key | | | | | Index and Key Source | | | | | specify key. | | | | | | | | | | Key Source may be present. | | | | | Key Index may be present. | | +------+-----+-----------------------------+------------+ - Figure 11: Key Identifier Mode (KIM) - Encoding + Figure 11: Key Identifier Mode (KIM) Encoding - In Mode 3 (KIM=11), the presence or absence of the Key - Source and Key Identifier depends on the Security Level - (LVL) described below. If the Security Level indicates - there is encryption, then the fields are present; if it - indicates there is no encryption, then the fields are not - present. + In Mode 3 (KIM=11), the presence or absence of the Key Source + and Key Identifier depends on the Security Level (LVL) + described below. If the Security Level indicates there is + encryption, then the fields are present; if it indicates there + is no encryption, then the fields are not present. Reserved: 5-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Counter: The Counter field indicates the non-repeating 4-octet value (nonce) used with the cryptographic mechanism that implements @@ -1567,59 +1581,55 @@ + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 14: The DIO Base Object - Control Field: The DAG Control Field has three flags and two fields: - - Grounded (G): The Grounded (G) flag indicates whether the - DODAG advertised can satisfy the application-defined - goal. If the flag is set, the DODAG is grounded. If the - flag is cleared, the DODAG is floating. + Grounded (G): The Grounded (G) flag indicates whether the DODAG + advertised can satisfy the application-defined goal. If the + flag is set, the DODAG is grounded. If the flag is cleared, + the DODAG is floating. Mode of Operation (MOP): The Mode of Operation (MOP) field identifies the mode of operation of the RPL Instance as - administratively provisioned at and distributed by the - DODAG Root. All nodes who join the DODAG must be able to - honor the MOP in order to fully participate as a router, - or else they must only join as a leaf. MOP is encoded as - in the figure below: + administratively provisioned at and distributed by the DODAG + Root. All nodes who join the DODAG must be able to honor the + MOP in order to fully participate as a router, or else they + must only join as a leaf. MOP is encoded as in the figure + below: +-----+-------------------------------------------------+ | MOP | Meaning | +-----+-------------------------------------------------+ | 0 | No downward routes maintained by RPL | | 1 | Non storing mode | | 2 | Storing without multicast support | | 3 | Storing with multicast support | | | | | | All other values are unassigned | +-----+-------------------------------------------------+ - A value of 0 indicates that destination advertisement - messages are disabled and the DODAG maintains only upward - routes + A value of 0 indicates that destination advertisement messages + are disabled and the DODAG maintains only upward routes Figure 15: Mode of Operation (MOP) Encoding - DODAGPreference (Prf): A 3-bit unsigned integer that defines - how preferable the root of this DODAG is compared to - other DODAG roots within the instance. DAGPreference - ranges from 0x00 (least preferred) to 0x07 (most - preferred). The default is 0 (least preferred). - Section 8.2 describes how DAGPreference affects DIO - processing. + DODAGPreference (Prf): A 3-bit unsigned integer that defines how + preferable the root of this DODAG is compared to other DODAG + roots within the instance. DAGPreference ranges from 0x00 + (least preferred) to 0x07 (most preferred). The default is 0 + (least preferred). Section 8.2 describes how DAGPreference + affects DIO processing. Version Number: 8-bit unsigned integer set by the DODAG root to the DODAGVersionNumber. Section 8.2 describes the rules for DODAG Version numbers and how they affect DIO processing. Rank: 16-bit unsigned integer indicating the DODAG rank of the node sending the DIO message. Section 8.2 describes how Rank is set and how it affects DIO processing. RPLInstanceID: 8-bit field set by the DODAG root that indicates @@ -1786,21 +1796,22 @@ DAOSequence: Incremented at each DAO message from a node, and echoed in the DAO-ACK by the recipient. The DAOSequence is used to correlate a DAO message and a DAO ACK message and is not to be confused with the Transit Information option Path Sequence that is associated to a given target Down the DODAG. Status: Indicates the completion. Status 0 is unqualified acceptance, 1 to 127 are unassigned and undetermined, and 128 and greater are rejection codes used to indicate that the node - should select an alternate parent. + should select an alternate parent. This specification does not + define any rejection codes. DODAGID (optional): 128-bit unsigned integer set by a DODAG root which uniquely identifies a DODAG. This field is only present when the 'D' flag is set. This field is typically only present when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use this field need not be present. Unassigned bits of the DAO-ACK Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. @@ -1928,22 +1939,22 @@ messages, and its format is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0 | +-+-+-+-+-+-+-+-+ Figure 20: Format of the Pad 1 Option - The Pad1 option is used to insert one or two octets of padding into - the message to enable options alignment. If more than one octet of + The Pad1 option is used to insert a single octet of padding into the + message to enable options alignment. If more than one octet of padding is required, the PadN option should be used rather than multiple Pad1 options. NOTE! the format of the Pad1 option is a special case - it has neither Option Length nor Option Data fields. 6.7.3. PadN The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is as follows: @@ -1955,22 +1966,25 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 21: Format of the Pad N Option The PadN option is used to insert two or more octets of padding into the message to enable options alignment. PadN Option data MUST be ignored by the receiver. Option Type: 0x01 (to be confirmed by IANA) - Option Length: For N (N > 1) octets of padding, the Option Length - field contains the value N-2. + Option Length: For N octets of padding, where 2 <= N <= 7, the + Option Length field contains the value N-2. An Option Length + of 0 indicates a total padding of 2 octets. An Option Length + of 5 indicates a total padding of 7 octets, which is the + maximum padding size allowed with the PadN option. Option Data: For N (N > 1) octets of padding, the Option Data consists of N-2 zero-valued octets. 6.7.4. Metric Container The Metric Container option MAY be present in DIO or DAO messages, and its format is as follows: 0 1 2 @@ -2386,56 +2399,54 @@ Figure 28: Format of the Solicited Information Option The Solicited Information option is used for a node to request DIO messages from a subset of neighboring nodes. The Solicited Information option may specify a number of predicate criteria to be matched by a receiving node. This is used by the requester to limit the number of replies from "non-interesting" nodes. These predicates affect whether a node resets its DIO trickle timer, as described in Section 8.3. + The Solicited Information option contains flags that indicate which + predicates a node should check when deciding whether to reset its + Trickle timer. A node resets its Trickle timer when all predicates + are true. If a flag is set, then the RPL node MUST check the + associated predicate. If a flag is cleared, then the RPL node MUST + NOT check the associated predicate. (If a flag is cleared, the RPL + node assumes that the associated predicate is true). + Option Type: 0x07 (to be confirmed by IANA) Option Length: 19 - Control Field: The control field contains flags that indicate which - predicates a node should check when deciding whether to reset - its Trickle timer. A node resets its Trickle timer when all - predicates are true. If a flag is set, then the RPL node MUST - check the associated predicate. If a flag is cleared, then the - RPL node MUST NOT check the associated predicate and assume the - predicate is true. The Solicited Information option Control - Field has three flags: - V: The V flag is the Version predicate. The Version - predicate is true if the receiver's DODAGVersionNumber - matches the requested Version Number. If the V flag is - cleared then the Version field is not valid and the - Version field MUST be set to zero on transmission and - ignored upon receipt. + V: The V flag is the Version predicate. The Version predicate is + true if the receiver's DODAGVersionNumber matches the requested + Version Number. If the V flag is cleared then the Version + field is not valid and the Version field MUST be set to zero on + transmission and ignored upon receipt. I: The I flag is the InstanceID predicate. The InstanceID - predicate is true when the RPL node's current - RPLInstanceID matches the requested RPLInstanceID. If - the I flag is cleared then the RPLInstanceID field is not - valid and the RPLInstanceID field MUST be set to zero on - transmission and ignored upon receipt. + predicate is true when the RPL node's current RPLInstanceID + matches the requested RPLInstanceID. If the I flag is cleared + then the RPLInstanceID field is not valid and the RPLInstanceID + field MUST be set to zero on transmission and ignored upon + receipt. - D: The D flag is the DODAGID predicate. The DODAGID - predicate is true if the RPL node's parent set has the - same DODAGID as the DODAGID field. If the D flag is - cleared then the DODAGID field is not valid and the - DODAGID field MUST be set to zero on transmission and - ignored upon receipt. + D: The D flag is the DODAGID predicate. The DODAGID predicate is + true if the RPL node's parent set has the same DODAGID as the + DODAGID field. If the D flag is cleared then the DODAGID field + is not valid and the DODAGID field MUST be set to zero on + transmission and ignored upon receipt. - Flags: 5-bit unused field reserved for flags. The field MUST - be initialized to zero by the sender and MUST be ignored - by the receiver. + Flags: 5-bit unused field reserved for flags. The field MUST be + initialized to zero by the sender and MUST be ignored by the + receiver. Version Number: 8-bit unsigned integer containing the value of DODAGVersionNumber that is being solicited when valid. RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID that is being solicited when valid. DODAGID: 128-bit unsigned integer containing the DODAGID that is being solicited when valid. @@ -2963,21 +2973,21 @@ announce themselves. Similarly, when a node jumps into a new DODAG it needs to construct a new DODAG parent set for this new DODAG. If a node needs to move Down a DODAG that it is attached to, increasing its Rank, then it MAY poison its routes and delay before moving as described in Section 8.2.2.5. A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions, but if the node has been a prior member of the DODAG Version then it must continue to observe - the rule that it may not advertise an effective rank higher than + the rule that it may not advertise a rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. This rule must be observed so as not to create a loophole that would allow the node to effectively increment its rank all the way to INFINITE_RANK, which may have impact on other nodes and create a resource-wasting count-to-infinity scenario. 8.2.2.5. Poisoning 1. A node poisons routes by advertising a Rank of INFINITE_RANK. @@ -3238,21 +3248,23 @@ 1. All nodes who join a DODAG MUST abide by the MOP setting from the root. Nodes that do not have the capability to fully participate as a router, e.g. that does not match the advertised MOP, MAY join the DODAG as a leaf. 2. If the MOP is 0, indicating no downward routing, nodes MUST NOT transmit DAO messages, and MAY ignore DAO messages. 3. In non-storing mode, the DODAG Root SHOULD store source routing - table entries for destinations learned from DAOs. + table entries for destinations learned from DAOs. If the Root + fails to store some information, then some destination may be + unreachable. 4. In storing mode, all non-root, non-leaf nodes MUST store routing table entries for destinations learned from DAOs. A DODAG can have one of several possible modes of operation, as defined by the MOP field. Either it does not support downward routes, it supports downward routes through source routing from DODAG Roots, or it supports downward routes through in-network routing tables. @@ -3491,26 +3503,22 @@ In non-storing mode, RPL routes messages downward using IP source routing. The following rule applies to nodes that are in non-storing mode. Storing mode has a separate set of rules, described in Section 9.8. 1. The Parent Address field of a Transit Information Option MUST contain one or more addresses. All of these addresses MUST be addresses of DAO parents of the sender. - 2. On receiving a unicast DAO, a node MUST propagate the updated - downward route information upwards. The node MAY use any parent - in the parent set. The downward route information in the DAO - message MAY be aggregated with other DAOs before being propagated - upwards, which MAY entail to delay the propagation as described - below. + 2. DAOs are sent directly to the root along a default route + installed as part of the parent selection. 3. When a node removes a node from its DAO parent set, it MAY generate a new DAO message with an updated Transit Information option. In non-storing mode, a node uses DAOs to report its DAO parents to the DODAG Root. The DODAG Root can piece together a downward route to a node by using DAO parent sets from each node in the route. The Path Sequence information may be used to detect stale DAO information. The purpose of this per-hop route calculation is to @@ -3563,26 +3571,27 @@ it has received to produce a set of RPL Target options and their associated Transmit Information options. Because this information is stored within each node's routing tables, in storing mode DAOs are communicated directly to DAO parents, who store this information. 9.9. Path Control A DAO message from a node contains one or more Target Options. Each - Target Option specifies either the node's prefix, a prefix of - addresses reachable outside the LLN, or a destination in the node's - sub-DODAG. The Path Control field of the Transit Information option - allows nodes to request or allow for multiple downward routes. A - node constructs the Path Control field of a Transit Information - option as follows: + Target Option specifies either a prefix advertised by the node, a + prefix of addresses reachable outside the LLN, the address of + destination in the node's sub-DODAG, or a multicast group that a node + in the sub-DODAG is listening to. The Path Control field of the + Transit Information option allows nodes to request or allow for + multiple downward routes. A node constructs the Path Control field + of a Transit Information option as follows: 1. The bit width of the path control field MUST be equal to the value (PCS + 1), where PCS is specified in the control field of the DODAG Configuration Option. Bits greater than or equal to the value (PCS + 1) MUST be cleared on transmission and MUST be ignored on reception. Bits below that value are considered "active" bits. 2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group @@ -4006,29 +4015,30 @@ 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 does not meet locally - maintained security policies, a node MAY discard the packet without - further processing. 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). + security for the message type and originator is unknown or does not + meet locally maintained security policies, a node MUST discard the + packet without further processing, MAY raise a management alert, and + MUST NOT send any messages in response. These policies can include + security levels, keys used, source identifiers, or the lack of + timestamp-based counters (as indicated by the 'T' flag). The + configuration of the security policy database for incoming packet + processing is out of scope for this specification (it may, for + example, be defined through DIO Configuration or through out-of-band + administrative router configuration). Where the message security level (LVL) indicates an encrypted RPL message, the node uses the key information identified through the KIM field as well as the Nonce as input to the message payload decryption processing. The Nonce shall be derived from the message Counter field and other received and locally maintained information (see 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. @@ -4262,31 +4272,26 @@ 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 information that contained within the data packet using the RPL Option [I-D.ietf-6man-rpl-option]) in an IPv6 Hop-by-Hop Option header. The RPL Option contains RPL Packet - Information (Figure 32) and [I-D.ietf-6man-rpl-option] defines the - details of how that RPL Packet Information is carried within the RPL - Option. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Information as defined below, and [I-D.ietf-6man-rpl-option] defines + the details of how that RPL Packet Information is carried within the + RPL Option. Future companion specifications may detail alternate + ways to carry this information. - Figure 32: RPL Packet Information + 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 @@ -4315,28 +4320,28 @@ 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. A RPL router that forwards a packet in the RPL network MUST check if the packet includes an IPv6 Hop-by-Hop RPL Option, and that the RPL - Option contains RPL Packet Information (Figure 32). If not, then the - RPL router MUST insert a RPL Option with RPL Packet Information as - specified in [I-D.ietf-6man-rpl-option]. 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. + Option contains RPL Packet Information (Section 11.2). If not, then + the RPL router MUST insert a RPL Option with RPL Packet Information + as specified in [I-D.ietf-6man-rpl-option]. If the router is an + ingress router that injects the packet into the RPL network, the + router MUST set the RPLInstanceID field in the RPL Packet + Information. The details of how that router determines the mapping + to a RPLInstanceID are out of scope for this specification and left + to future specification. A router that forwards a packet to outside the RPL network MUST remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. When a router receives a packet that specifies a given RPLInstanceID and the node can forward the packet along the DODAG associated to that instance, then the router MUST do so and leave the RPLInstanceID value unchanged. If any node can not forward a packet along the DODAG associated to @@ -4503,31 +4508,29 @@ or other protocols such as BFD ([RFC5880]) and MANET Neighborhood Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]). Unfortunately, such an approach is not desirable in constrained environments such as LLN and would lead to excessive control traffic in light of the data traffic with a negative impact on both link loads and nodes resources. Overhead to maintain the routing adjacency should be minimized. Furthermore, it is not always possible to rely on the link or transport layer to provide information of the associated link state. The network layer needs to fall back on its own mechanism. - Thus RPL makes use of a different approach consisting of probing the - neighbor using a Neighbor Solicitation message (see [RFC4861]). The - reception of a Neighbor Advertisement (NA) message with the - "Solicited Flag" set is used to verify the validity of the routing - adjacency. Such mechanism MAY be used prior to sending a data - packet. This allows for detecting whether or not the routing - adjacency is still valid, and should it not be the case, select - another feasible successor to forward the packet. Under specific - circumstances and according to the network resources, a RPL - implementation MAY decide to augment this mechanism with Keep-Alive - messages. + By contrast with several other routing protocols, RPL does not define + any 'keep-alive' mechanisms to detect routing adjacency failure: this + is in most cases, because such a mechanism may be too expensive in + terms of bandwidth and even more importantly energy (a battery + operated device could not afford to send periodic Keep alive). Still + RPL requires mechanisms to detect that a neighbor is no longer + reachable: this can be performed by using mechanisms such as Neighbor + Unreachability Detection as defined in [RFC4861] or even some form of + Keep-alive that are outside of this document. 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 @@ -5282,52 +5285,40 @@ 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. -17.7. Liveness Detection and Monitoring - - By contrast with several other routing protocols, RPL does not define - any 'keep-alive' mechanisms to detect routing adjacency failure: this - is in most cases, because such a mechanism may be too expensive in - terms of bandwidth and even more importantly energy (a battery - operated device could not afford to send periodic Keep alive). Still - RPL requires mechanisms to detect that a neighbor is no longer - reachable: this can be performed by using mechanisms such as NUD - (Neighbor Unreachability Detection) or even some form of Keep-alive - that are outside of this document. - -17.8. Fault Isolation +17.7. Fault Isolation It is RECOMMENDED to quarantine neighbors that start emitting malformed messages at unacceptable rates. -17.9. Impact on Other Protocols +17.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 a LBR, it is expected for the device to support routing redistribution functions between the routing protocols to allow for reachability between the two routing domains. Such redistribution SHOULD be governed by the use of user configurable policy. With regards to the impact in terms of traffic on the network, RPL has been designed to limit the control traffic thanks to mechanisms such as Trickle timers (Section 8.3). Thus the impact of RPL on other protocols should be extremely limited. -17.10. Performance Management +17.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 implementation MAY support some of these, and other parameters of interest are listed below: o Number of repairs and time to repair in seconds (average, @@ -5335,21 +5326,21 @@ o Number of times and duration during which a devices could not forward a packet because of a lack of 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 -17.11. Diagnostics +17.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. 18. Security Considerations 18.1. Overview @@ -5457,21 +5448,21 @@ New codes may be allocated only by an IETF Review. Each code should be tracked with the following qualities: o Code o Description o Defining RFC - Three codes are currently defined: + The following codes are currently defined: +------+----------------------------------------------+-------------+ | Code | Description | Reference | +------+----------------------------------------------+-------------+ | 0x00 | DODAG Information Solicitation | This | | | | document | | | | | | 0x01 | DODAG Information Object | This | | | | document | | | | | @@ -5484,29 +5475,31 @@ | 0x80 | Secure DODAG Information Solicitation | This | | | | document | | | | | | 0x81 | Secure DODAG Information Object | This | | | | document | | 0x82 | Secure Destination Advertisement Object | This | | | | document | | | | | | 0x83 | Secure Destination Advertisement Object | This | | | Acknowledgment | document | + | | | | + | 0x8A | Consistency Check | This | + | | | document | +------+----------------------------------------------+-------------+ RPL Control Codes -19.3. New Registry for the Mode of Operation (MOP) DIO Control Field +19.3. New Registry for the Mode of Operation (MOP) IANA is requested to create a registry for the 3-bit Mode of - Operation (MOP) DIO Control Field, which is contained in the DIO - Base. + Operation (MOP), which is contained in the DIO Base. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Mode of Operation Value o Capability description o Defining RFC @@ -5974,34 +5967,34 @@ Email: stevedh@cs.berkeley.edu 22. References 22.1. Normative References [I-D.ietf-6man-rpl-option] Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Information in Data-Plane Datagrams", - draft-ietf-6man-rpl-option-00 (work in progress), - July 2010. + draft-ietf-6man-rpl-option-01 (work in progress), + October 2010. [I-D.ietf-6man-rpl-routing-header] - Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing - Header for Source Routes with RPL", - draft-ietf-6man-rpl-routing-header-00 (work in progress), - July 2010. + Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 + Routing Header for Source Routes with RPL", + draft-ietf-6man-rpl-routing-header-01 (work in progress), + October 2010. [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Networks, D., Dejean, N., and D. Barthel, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", - draft-ietf-roll-routing-metrics-10 (work in progress), + draft-ietf-roll-routing-metrics-11 (work in progress), October 2010. [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-04 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.