--- 1/draft-ietf-roll-rpl-15.txt 2010-12-09 11:13:41.000000000 +0100 +++ 2/draft-ietf-roll-rpl-16.txt 2010-12-09 11:13:41.000000000 +0100 @@ -1,35 +1,35 @@ ROLL T. Winter, Ed. Internet-Draft Intended status: Standards Track P. Thubert, Ed. -Expires: May 10, 2011 Cisco Systems +Expires: June 11, 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 - November 6, 2010 + December 8, 2010 RPL: IPv6 Routing Protocol for Low power and Lossy Networks - draft-ietf-roll-rpl-15 + draft-ietf-roll-rpl-16 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,222 +51,244 @@ 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 May 10, 2011. + This Internet-Draft will expire on June 11, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.1. Design Principles . . . . . . . . . . . . . . . . . . . 7 - 1.2. Expectations of Link Layer Type . . . . . . . . . . . . 9 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 - 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 13 - 3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 13 - 3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 14 - 3.2. Upward Routes and DODAG Construction . . . . . . . . . . 16 - 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 16 - 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 16 - 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 17 - 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 17 - 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 17 - 3.2.6. Administrative Preference . . . . . . . . . . . . . . 18 - 3.2.7. Datapath Validation and Loop Detection . . . . . . . 18 - 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 18 - 3.3. Downward Routes and Destination Advertisement . . . . . 19 - 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 19 - 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 19 - 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 20 - 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 21 - 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 22 - 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 23 - 3.7.1. Greediness and Instability . . . . . . . . . . . . . 23 - 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 25 - 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 26 - 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 27 - 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 27 - 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 27 - 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 27 - 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 28 - 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 28 - 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 30 - 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 32 - 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 37 - 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 37 - 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 37 - 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 37 - 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 37 - 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 38 - 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 40 - 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 40 - 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 40 - 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 40 - 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 42 - 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 42 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 + 1.1. Design Principles . . . . . . . . . . . . . . . . . . . 8 + 1.2. Expectations of Link Layer Type . . . . . . . . . . . . 10 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 14 + 3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 14 + 3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 15 + 3.2. Upward Routes and DODAG Construction . . . . . . . . . . 17 + 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 17 + 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 17 + 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 18 + 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 18 + 3.2.6. Administrative Preference . . . . . . . . . . . . . . 19 + 3.2.7. Datapath Validation and Loop Detection . . . . . . . 19 + 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 19 + 3.3. Downward Routes and Destination Advertisement . . . . . 20 + 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 20 + 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 20 + 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 21 + 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 22 + 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 23 + 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 24 + 3.7.1. Greediness and Instability . . . . . . . . . . . . . 24 + 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 26 + 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 27 + 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 28 + 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 28 + 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 28 + 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 28 + 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 29 + 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 29 + 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 31 + 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 33 + 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 38 + 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 38 + 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 38 + 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 38 + 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 38 + 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 39 + 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 41 + 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 41 + 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 41 + 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 41 + 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 43 + 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 43 6.5. Destination Advertisement Object Acknowledgement - (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 42 - 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 42 - 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 44 - 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 44 - 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 44 - 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 44 - 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 45 - 6.7. RPL Control Message Options . . . . . . . . . . . . . . 45 - 6.7.1. RPL Control Message Option Generic Format . . . . . . 45 - 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 46 - 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 47 - 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 47 - 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 48 - 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 50 - 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 52 - 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 53 - 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 56 - 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 58 - 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 60 - 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 62 - 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 62 - 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 63 - 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 65 - 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 65 - 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 66 - 8.2.1. Neighbors and Parents within a DODAG Version . . . . 66 - 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 67 - 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 72 - 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 72 - 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 73 - 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 73 - 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 74 - 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 75 - 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 76 - 9.1. Destination Advertisement Parents . . . . . . . . . . . 76 - 9.2. Downward Route Discovery and Maintenance . . . . . . . . 77 - 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 78 - 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 78 - 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 79 - 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 79 - 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 81 - 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 81 - 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 82 - 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 83 - 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 84 - 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 85 - 9.10. Multicast Destination Advertisement Messages . . . . . . 87 - 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 88 - 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 88 - 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 89 - 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 90 - 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 90 - 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 91 - 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 92 - 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 93 - 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 94 - 10.8. Coverage of Integrity and Confidentiality . . . . . . . 95 - 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 95 - 10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 95 - 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 96 - 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 98 - 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 98 - 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 99 - 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 100 - 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 100 - 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 103 - 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 105 - 14. Guidelines for Objective Functions . . . . . . . . . . . . . 106 - 14.1. Objective Function Behavior . . . . . . . . . . . . . . 106 - 15. Suggestions for Interoperation with Neighbor Discovery . . . 108 - 16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 109 - 17. Manageability Considerations . . . . . . . . . . . . . . . . 111 - 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 111 - 17.2. Configuration Management . . . . . . . . . . . . . . . . 112 - 17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 112 - 17.2.2. DIO and DAO Base Message and Options Configuration . 113 + (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 43 + 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 43 + 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 45 + 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 45 + 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 45 + 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 45 + 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 46 + 6.7. RPL Control Message Options . . . . . . . . . . . . . . 46 + 6.7.1. RPL Control Message Option Generic Format . . . . . . 46 + 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 47 + 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 48 + 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 48 + 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 49 + 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 51 + 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 53 + 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 54 + 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 57 + 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 59 + 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 61 + 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 63 + 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 63 + 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 64 + 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 66 + 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 66 + 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 67 + 8.2.1. Neighbors and Parents within a DODAG Version . . . . 67 + 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 68 + 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 73 + 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 73 + 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 74 + 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 74 + 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 75 + 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 76 + 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 77 + 9.1. Destination Advertisement Parents . . . . . . . . . . . 77 + 9.2. Downward Route Discovery and Maintenance . . . . . . . . 78 + 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 79 + 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 79 + 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 80 + 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 80 + 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 82 + 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 83 + 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 84 + 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 85 + 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 85 + 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 87 + 9.10. Multicast Destination Advertisement Messages . . . . . . 89 + 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 90 + 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90 + 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91 + 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92 + 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92 + 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93 + 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94 + 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95 + 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 96 + 10.8. Coverage of Integrity and Confidentiality . . . . . . . 97 + 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 97 + 10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 97 + 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 98 + 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 100 + 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 100 + 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 101 + 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 102 + 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 102 + 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 105 + 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 107 + 14. Guidelines for Objective Functions . . . . . . . . . . . . . 108 + 14.1. Objective Function Behavior . . . . . . . . . . . . . . 108 + 15. Suggestions for Interoperation with Neighbor Discovery . . . 110 + 16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 111 + 17. Manageability Considerations . . . . . . . . . . . . . . . . 113 + 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 113 + 17.2. Configuration Management . . . . . . . . . . . . . . . . 114 + 17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 114 + 17.2.2. DIO and DAO Base Message and Options Configuration . 115 17.2.3. Protocol Parameters to be configured on every - router in the LLN . . . . . . . . . . . . . . . . . . 113 + router in the LLN . . . . . . . . . . . . . . . . . . 115 17.2.4. Protocol Parameters to be configured on every - non-DODAG-root router in the LLN . . . . . . . . . . 114 - 17.2.5. Parameters to be configured on the DODAG root . . . . 114 + non-DODAG-root router in the LLN . . . . . . . . . . 116 + 17.2.5. Parameters to be configured on the DODAG root . . . . 116 17.2.6. Configuration of RPL Parameters related to - DAO-based mechanisms . . . . . . . . . . . . . . . . 115 + DAO-based mechanisms . . . . . . . . . . . . . . . . 117 17.2.7. Configuration of RPL Parameters related to - Security mechanisms . . . . . . . . . . . . . . . . . 116 - 17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 117 - 17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 117 - 17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 117 + Security mechanisms . . . . . . . . . . . . . . . . . 118 + 17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 119 + 17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 119 + 17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 119 17.3.2. Monitoring a DODAG inconsistencies and loop - detection . . . . . . . . . . . . . . . . . . . . . . 118 - 17.4. Monitoring of the RPL data structures . . . . . . . . . 119 - 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 119 + detection . . . . . . . . . . . . . . . . . . . . . . 120 + 17.4. Monitoring of the RPL data structures . . . . . . . . . 121 + 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 121 17.4.2. Destination Oriented Directed Acyclic Graph (DAG) - Table . . . . . . . . . . . . . . . . . . . . . . . . 119 - 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 120 - 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 121 - 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 121 - 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 122 - 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 123 - 17.9. Performance Management . . . . . . . . . . . . . . . . . 123 - 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 123 - 18. Security Considerations . . . . . . . . . . . . . . . . . . . 124 - 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 124 - 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126 - 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 126 - 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 126 - 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 127 - 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 128 - 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 128 - 19.6. New Registry for the Security Section Algorithm . . . . 129 - 19.7. New Registry for the Security Section Flags . . . . . . 129 - 19.8. New Registry for Per-KIM Security Levels . . . . . . . . 130 + Table . . . . . . . . . . . . . . . . . . . . . . . . 121 + 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 122 + 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 123 + 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 123 + 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 124 + 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 125 + 17.9. Performance Management . . . . . . . . . . . . . . . . . 125 + 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 125 + 18. Security Considerations . . . . . . . . . . . . . . . . . . . 126 + 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 126 + 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128 + 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 128 + 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 128 + 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 129 + 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 130 + 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 130 + 19.6. New Registry for the Security Section Algorithm . . . . 131 + 19.7. New Registry for the Security Section Flags . . . . . . 131 + 19.8. New Registry for Per-KIM Security Levels . . . . . . . . 132 19.9. New Registry for the DIS (DODAG Informational - Solicitation) Flags . . . . . . . . . . . . . . . . . . 131 + Solicitation) Flags . . . . . . . . . . . . . . . . . . 133 19.10. New Registry for the DODAG Information Object (DIO) - Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132 + Flags . . . . . . . . . . . . . . . . . . . . . . . . . 134 19.11. New Registry for the Destination Advertisement Object - (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 132 + (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 134 19.12. New Registry for the Destination Advertisement Object - (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 133 - 19.13. New Registry for the Consistency Check (CC) Flags . . . 133 - 19.14. New Registry for the DODAG Configuration Option Flags . 134 - 19.15. New Registry for the RPL Target Option Flags . . . . . . 134 - 19.16. New Registry for the Transit Information Option Flags . 134 + (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 135 + 19.13. New Registry for the Consistency Check (CC) Flags . . . 135 + 19.14. New Registry for the DODAG Configuration Option Flags . 136 + 19.15. New Registry for the RPL Target Option Flags . . . . . . 136 + 19.16. New Registry for the Transit Information Option Flags . 137 19.17. New Registry for the Solicited Information Option - Flags . . . . . . . . . . . . . . . . . . . . . . . . . 135 - 19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 136 - 19.19. Link-Local Scope multicast address . . . . . . . . . . . 136 - 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 137 - 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 138 - 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 139 - 22.1. Normative References . . . . . . . . . . . . . . . . . . 139 - 22.2. Informative References . . . . . . . . . . . . . . . . . 140 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 + Flags . . . . . . . . . . . . . . . . . . . . . . . . . 137 + 19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 138 + 19.19. Link-Local Scope multicast address . . . . . . . . . . . 138 + 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139 + 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 140 + 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 141 + 22.1. Normative References . . . . . . . . . . . . . . . . . . 141 + 22.2. Informative References . . . . . . . . . . . . . . . . . 142 + Appendix A. Example Operation . . . . . . . . . . . . . . . . . 145 + A.1. Example with External Prefixes . . . . . . . . . . . . . 145 + A.2. Example Operation in Storing Mode With Node-owned + Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 147 + A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 148 + A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 148 + A.2.3. Routing Information Base . . . . . . . . . . . . . . 149 + A.3. Example Operation in Storing Mode With Subnet-wide + Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 149 + A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 150 + A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 151 + A.3.3. Routing Information Base . . . . . . . . . . . . . . 151 + A.4. Example Operation in Non-Storing Mode With Node-owned + Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 152 + A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 153 + A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 153 + A.4.3. Routing Information Base . . . . . . . . . . . . . . 154 + A.5. Example Operation in Non-Storing Mode With + Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 154 + A.5.1. DIO messages and PIO . . . . . . . . . . . . . . . . 155 + A.5.2. DAO messages . . . . . . . . . . . . . . . . . . . . 156 + A.5.3. Routing Information Base . . . . . . . . . . . . . . 156 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158 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- @@ -328,34 +350,42 @@ Packet Information to support additional features. RPL provides a mechanism to disseminate information over the dynamically-formed network topology. The dissemination enables minimal configuration in the nodes, allowing nodes to operate mostly autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to optimize the dissemination as described in Section 8.3. In some applications, RPL assembles topologies of routers that own independent prefixes. Those prefixes may or may not be aggregatable - depending on the origin of the routers. RPL also introduces the - capability to bind a subnet together and route within that subnet. - In that case, the source of the dissemination is authoritative for - the information about the subnet that RPL disseminates. + depending on the origin of the routers. A prefix that is owned by a + router is advertised as on-link. - When operating within a subnet, RPL may in particular disseminate - Neighbor Discovery information such as the [RFC4861] Prefix - Information Option (PIO) and the [RFC4191] Route Information Option - (RIO). ND information that is disseminated by RPL conserves its - original semantics. It is not to be confused with routing - advertisements and it is not to be directly redistributed in another - routing protocol. However, a RPL router may trivially reform the - original ND option, use the option as if received in an ND Router - Advertisements and expose it in its own RAs. + RPL also introduces the capability to bind a subnet together with a + common prefix and to route within that subnet. A source can inject + information about the subnet to be disseminated by RPL, and that + source is authoritative for that subnet. Because many LLN links have + non-transitive properties, a common prefix that RPL disseminates over + the subnet must not be advertised as on-link. + + RPL may in particular disseminate IPv6 Neighbor Discovery (ND) + information such as the [RFC4861] Prefix Information Option (PIO) and + the [RFC4191] Route Information Option (RIO). ND information that is + disseminated by RPL conserves all its original semantics for router + to host, with limited extensions for router to router, though it is + not to be confused with routing advertisements and it is never to be + directly redistributed in another routing protocol. A RPL node often + combines host and router behaviors. As a host, it will process the + options as specified in [RFC4191], [RFC4861], [RFC4862] and + [RFC3775]. As a router, the RPL node may advertise the information + from the options as required for the specific link, for instance in a + ND RA message, though the exact operation is out of scope. 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 @@ -707,22 +737,28 @@ In the second, called "pre-installed," nodes joining a RPL Instance have pre-installed keys that enable them to process and generate secured RPL messages. The third mode is called "authenticated." In authenticated mode, nodes have pre-installed keys as in pre-installed mode, but the pre- installed key may only be used to join a RPL Instance as a leaf. Joining an authenticated RPL Instance as a router requires obtaining a key from an authentication authority. The process by which this - key is obtained is out of scope for this specification (to be defined - in future companion specifications). + key is obtained is out of scope for this specification. Note that + this specification alone does not provide sufficient detail for a RPL + implementation to securely operate in authenticated mode. For a RPL + implementation to operate securely in authenticated mode it is + necessary for a future companion specification to detail the + mechanisms by which a node obtains/requests the authentication + material (e.g. key, certificate), and to determine from where that + material should be obtained. See also Section 10.3. 3.2.4. Grounded and Floating DODAGs DODAGs can be grounded or floating: the DODAG root advertises which is the case. A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal. A floating DODAG is not expected to satisfy the goal and in most cases only provides routes to nodes within the DODAG. Floating DODAGs may be used, for example, to preserve inner connectivity during repair. @@ -965,21 +1001,21 @@ even a composite metric, that will satisfy all use cases. In addition, RPL supports constrained-based routing where constraints may be applied to both link and nodes. If a link or a node does not satisfy a required constraint, it is 'pruned' from the candidate neighbor set, thus leading to a constrained shortest path. An Objective Function specifies the objectives used to compute the (constrained) path. Furthermore, nodes are configured to support a set of metrics and constraints, and select their parents in the DODAG - according the the metrics and constraints advertised in the DIO + according to the metrics and constraints advertised in the DIO messages. Upstream and Downstream metrics may be merged or advertised separately depending on the OF and the metrics. When they are advertised separately, it may happen that the set of DIO parents is different from the set of DAO parents (a DAO parent is a node to which unicast DAO messages are sent). Yet, all are DODAG parents with regards to the rules for Rank computation. The Objective Function is decoupled from the routing metrics and constraints used by RPL. Indeed, whereas the OF dictates rules such as DODAG parents selection, load balancing and so on, the set of @@ -992,22 +1028,22 @@ Example 1: Shortest path: path offering the shortest end-to-end delay. Example 2: Shortest Constrained path: the path that does not traverse any battery-operated node and that optimizes the path reliability. 3.7. Loop Avoidance - RPL avoids creating loops when undergoing topology changes and - includes rank-based datapath validation mechanisms for detecting + RPL tries to avoid creating loops when undergoing topology changes + and includes rank-based datapath validation mechanisms for detecting loops when they do occur (see Section 11 for more details). In practice, this means that RPL guarantees neither loop free path selection nor tight delay convergence times, but can detect and repair a loop as soon as it is used. RPL uses this loop detection to ensure that packets make forward progress within the DODAG Version and trigger repairs when necessary. 3.7.1. Greediness and Instability A node is greedy if it attempts to move deeper (increase Rank) in the @@ -1386,25 +1423,34 @@ |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Key Identifier . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Security Section - Message authentication codes (MACs) and signatures cover the entire - unsecured ICMPv6 RPL message, yielding a secured ICMPv6 RPL message - with the inclusion of the cryptographic fields (MAC, signature, - etc.). Encryption starts after the Security section. Use of the - Security section is further detailed in Section 18 and Section 10. + Message authentication codes (MACs) and signatures provide + authentication over the entire unsecured ICMPv6 RPL control message, + including the Security section with all fields defined, but with the + ICMPv6 checksum temporarily set to zero. Encryption provides + confidentiality of the secured RPL ICMPv6 message starting at the + first byte after the Security section and continuing to the last byte + of the packet. The security transformation yields a secured ICMPv6 + RPL message with the inclusion of the cryptographic fields (MAC, + signature, etc.). In other words, the security transformation itself + (e.g. the Signature and/or Algorithm in use) will detail how to + incorporate the cryptographic fields into the secured packet. The + Security section itself does not explicitly carry those cryptographic + fields. Use of the Security section is further detailed in + Section 18 and Section 10. 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. Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Security Algorithm (Algorithm): The Security Algorithm field @@ -1500,21 +1546,23 @@ +-------+--------------------+------+ +---------------------+ | KIM=3 | +-------+---------------+-----+ | LVL | Attributes | Sig | | | | Len | +-------+---------------+-----+ | 0 | Sign-3072 | 384 | | 1 | ENC-Sign-3072 | 384 | - | 2-7 | Unassigned | N/A | + | 2 | Sign-2048 | 256 | + | 3 | ENC-Sign-2048 | 256 | + | 4-7 | Unassigned | N/A | +-------+---------------+-----+ Figure 11: 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. @@ -2381,21 +2429,21 @@ initialized to zero by the sender and MUST be ignored by the receiver. Path Control: 8-bit bitfield. The Path Control field limits the number of DAO-Parents to which a DAO message advertising connectivity to a specific destination may be sent, as well as providing some indication of relative preference. The limit provides some bound on overall DAO message fan-out in the LLN. The assignment and ordering of the bits in the path control also serves to communicate preference. Not all of these bits - may be enabled as according the the PCS in the DODAG + may be enabled as according to the PCS in the DODAG Configuration. The Path Control field is divided into four subfields which contain two bits each: PC1, PC2, PC3, and PC4, as illustrated in Figure 27. The subfields are ordered by preference, with PC1 being the most preferred and PC4 being the least preferred. Within a subfield there is no order of preference. By grouping the parents (as in ECMP) and ordering them, the parents may be associated with specific bits in the Path Control field in a way that communicates preference. 0 1 2 3 4 5 6 7 @@ -2505,34 +2553,32 @@ DODAGID: 128-bit unsigned integer containing the DODAGID that is being solicited when valid. Unassigned bits of the Solicited Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 6.7.10. Prefix Information The Prefix Information option MAY be present in DIO messages, and - carries the equivalent information for the purpose of configuring RPL - routers as the IPv6 ND Prefix Information option defined in - [RFC4861]. In particular, a RPL router may use this option to - autoconfigure an address from a parent prefix as specified in - [RFC4862] and advertise its own address as specified in [RFC3775]. - The root of a DODAG is authoritative for setting that information and - the information is unchanged as propagated down the DODAG but for the - suffix of the address of the parent that can be included in the - prefix. A RPL router may trivially transform a RPL PIO that it - advertises in PIO messages back into a ND option to place in RAs so a - node attached to the RPL router can also use it for all ND purposes - including address autoconfiguration. The format of the option is - modified slightly (Type, Length, Prefix) in order to be carried as a - RPL option as follows: + carries the information that is specified for the IPv6 ND Prefix + Information Option in [RFC4861], [RFC4862] and [RFC3775] for use by + RPL nodes and IPv6 hosts. In particular, a RPL node may use this + option for the purpose of State-Less Address Auto-Configuration + (SLAAC) from a prefix advertised by a parent as specified in + [RFC4862], and advertise its own address as specified in [RFC3775]. + The root of a DODAG is authoritative for setting that information. + The information is propagated down the DODAG unchanged, with the + exception that a RPL router may update (extend) the prefix by + appending it's own suffix. The format of the option is modified + (Type, Length, Prefix) in order to be carried as a RPL option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -2566,27 +2612,35 @@ The prefix length field provides necessary information for on- link determination (when combined with the L flag in the prefix information option). It also assists with address autoconfiguration as specified in [RFC4862], for which there may be more restrictions on the prefix length. L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not - set a host MUST NOT conclude that an address derived from the - prefix is off-link. That is, it MUST NOT update a previous - indication that the address is on-link. + set a RPL node MUST NOT conclude that an address derived from + the prefix is off-link. That is, it MUST NOT update a previous + indication that the address is on-link. A RPL node acting as a + router MUST NOT propagate a PIO with the L flag set. A RPL + node acting as a router MAY propagate a PIO with the L flag not + set. A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address - configuration as specified in [RFC4862]. + configuration as specified in [RFC4862]. When both protocols + (ND RAs and RPL DIOs) are used to carry PIOs on the same link, + it is possible to use either one for SLAAC by a RPL node. It + is also possible to make either protocol ineligible for SLAAC + operation by forcing the A flag to 0 for PIOs carried in that + protocol. R 1-bit Router address flag. When set, indicates that the Prefix field contains a complete IPv6 address assigned to the sending router that can be used as parent in a target option. The indicated prefix is the first Prefix Length bits of the Prefix field. The router IPv6 address has the same scope and conforms to the same lifetime values as the advertised prefix. This use of the Prefix field is compatible with its use in advertising the prefix itself, since Prefix Advertisement uses only the leading bits. Interpretation of this flag bit is thus @@ -2753,21 +2807,21 @@ 1. If (256 + B - A) is less than or equal to SEQUENCE_WINDOW, then B is greater than A, A is less than B, and the two are not equal. 2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A is greater than B, B is less than A, and the two are not equal. For example, if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is - greater than 16. As another example, if A is 250 and B is 5, + greater than 5. As another example, if A is 250 and B is 5, then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW (16), thus 250 is less than 5. 2. In the case where both sequence counters to be compared are less than or equal to 127, and in the case where both sequence counters to be compared are greater than or equal to 128: 1. If the absolute magnitude of difference between the two sequence counters is less than or equal to @@ -3494,43 +3548,81 @@ information for a specific Target, and that has prior information for that Target, MUST use the Path Sequence number in the Transit Information option associated with that Target in order to determine whether or not the DAO message contains updated information as per Section 7. 6. If a node receives a DAO message that does not follow the above rules, it MUST discard the DAO message without further processing. - In non-storing mode additional rules apply to ensure the continuity - of end-to-end source route path: + In non-storing mode, the root builds a strict source routing header, + hop-by-hop, by recursively looking up one-hop information that ties a + target (address or prefix) and a transit address together. In some + cases, when a child address is derived from a prefix that is owned + and advertised by a parent, that parent-child relationship may be + inferred by the root for the purpose of constructing the source + routing header. In all other cases it is necessary to inform the + root of the transit-target relationship from a reachable target, so + as to later enable the recursive construction of the routing header. + An address that is advertised as target in a DAO message MUST be + collocated in the same router, or reachable onlink by the router that + owns the address that is indicated in the associated transit + information. The following additional rules apply to ensure the + continuity of the end-to-end source route path: - 1. The address used as transit parent by the children MUST be taken - from a PIO with the 'R' flag set from that parent but is not - necessarily on link for the children. + 1. The address of a parent used in the transit option MUST be taken + from a PIO from that parent with the 'R' flag set. The 'R' flag + in a PIO indicates that the prefix field actually contains the + full parent address but the child SHOULD NOT assume that the + parent address is onlink. - 2. The router that advertises an address as parent in a PIO MUST - also advertise that address as target in a DAO message. + 2. A PIO with a 'A' flag set indicates that the RPL child node may + use the prefix to autoconfigure an address. A parent that + advertises a prefix in a PIO with the 'A' flag set MUST ensure + that the address or the whole prefix in the PIO is reachable from + the root by advertising it as a DAO target. If the parent sets + also the 'L' flag indicating that the prefix is onlink, then it + MUST advertise the whole prefix as target in a DAO message. - 3. An address that is advertised as target in a DAO MUST be - collocated or reachable onlink by the parent that is indicated in - the associated transit information. + 3. An address that is advertised as target in a DAO message MUST be + collocated in the same router or reachable onlink by the router + that owns the address that is indicated in the associated transit + information. - 4. A router might have targets that are not known to be onlink for a - parent, either because they are addresses located on an alternate - interface or because they belong to nodes that are external to - RPL, for instance connected hosts. In order to inject such a - target in the RPL network, the router MUST advertise itself as - the Parent Address in the Transit Information option for that - target, using an address that is onlink for that nodes DAO - parent. If the target belongs to an external node then the - router MUST set the External 'E' flag in the transit information. + 4. In order to enable an optimum compression of the routing header, + the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag + set and the 'L' flag cleared, and the child SHOULD prefer to use + as transit the address of the parent that is found in the PIO + that is used to autoconfigure the address that is advertised as + target in the DAO message. + + 5. A router might have targets that are not known to be on-link for + a parent, either because they are addresses located on an + alternate interface or because they belong to nodes that are + external to RPL, for instance connected hosts. In order to + inject such a target in the RPL network, the router MUST + advertise itself as the Parent Address in the Transit Information + option for that target, using an address that is on-link for that + nodes DAO parent. If the target belongs to an external node then + the router MUST set the External 'E' flag in the transit + information. + + A child node that has autoconfigured an address from a parent PIO + with the 'L' flag set does not need to advertise that address as a + DAO target since the parent insures that the whole prefix is already + reachable from the root. But if the 'L' flag is not set then it is + necessary in non-storing mode for the child node to inform the root + of the parent-child relationship, using a reachable address of the + parent, so as to enable the recursive construction of the routing + header. This is done by associating an address of the parent as + transit with the address of the child as target in a DAO message. 9.5. DAO Transmission Scheduling Because DAOs flow upwards, receiving a unicast DAO can trigger sending a unicast DAO to a DAO parent. 1. On receiving a unicast DAO message with updated information, such as containing a Transit Information option with a new Path Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO message immediately. It SHOULD delay sending the DAO message in @@ -3898,21 +3990,21 @@ To join a RPL Instance, a node must have a pre-installed 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 this specification, RPL supports only symmetric algorithms: authenticated mode is included for the benefit of potential future - cryptographic primitives. + 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 pre-installed 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 @@ -3979,21 +4071,23 @@ 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. + 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 MUST have @@ -4064,23 +4158,23 @@ 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 Nonce to secure the - outgoing packet MUST be an increment of the last Counter transmitted - to the particular destination address. + 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 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 Time 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 @@ -4267,39 +4361,48 @@ 10.9.2. Signatures If the Key Identification Mode (KIM) mode 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]. It uses as public key the pair (n,e), where n is a 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). 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]. + [RFC3447]. It uses as public key 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 CCM mode with M=0, this + specification explicitly allows CCM mode with M=0 when used in + conjunction with a signature as in this case, because the signature + provides sufficient protection. 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 six-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 which 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 @@ -5769,20 +5872,24 @@ | | | | | | 1 | 2 | See Figure 11 | This document | | | | | | | 2 | 2 | See Figure 11 | This document | | | | | | | 3 | 2 | See Figure 11 | This document | | | | | | | 0 | 3 | See Figure 11 | This document | | | | | | | 1 | 3 | See Figure 11 | This document | + | | | | | + | 2 | 3 | See Figure 11 | This document | + | | | | | + | 3 | 3 | See Figure 11 | This document | +-------+-----------+---------------+---------------+ Per-KIM Security Levels 19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags IANA is requested to create a registry for the DIS (DODAG Informational Solicitation) Flag Field. New bit numbers may be allocated only by an IETF Review. Each bit @@ -6050,30 +6157,30 @@ draft-ietf-6man-rpl-option-01 (work in progress), October 2010. [I-D.ietf-6man-rpl-routing-header] 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. + Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", - draft-ietf-roll-routing-metrics-11 (work in progress), - October 2010. + draft-ietf-roll-routing-metrics-13 (work in progress), + December 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. + "The Trickle Algorithm", draft-ietf-roll-trickle-06 (work + in progress), December 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. @@ -6105,21 +6212,21 @@ Commerce , February 2008, . [I-D.ietf-manet-nhdp] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-14 (work in progress), July 2010. [I-D.ietf-roll-of0] Thubert, P., "RPL Objective Function 0", - draft-ietf-roll-of0-03 (work in progress), July 2010. + draft-ietf-roll-of0-04 (work in progress), December 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. [Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", North-Holland Computer Networks 7: 395-405, 1983,