draft-ietf-roll-rpl-18.txt   draft-ietf-roll-rpl-19.txt 
ROLL T. Winter, Ed. ROLL T. Winter, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: August 8, 2011 Cisco Systems Expires: September 14, 2011 Cisco Systems
A. Brandt A. Brandt
Sigma Designs Sigma Designs
T. Clausen T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
J. Hui J. Hui
Arch Rock Corporation Arch Rock Corporation
R. Kelsey R. Kelsey
Ember Corporation Ember Corporation
P. Levis P. Levis
Stanford University Stanford University
K. Pister K. Pister
Dust Networks Dust Networks
R. Struik R. Struik
JP. Vasseur JP. Vasseur
Cisco Systems Cisco Systems
February 4, 2011 March 13, 2011
RPL: IPv6 Routing Protocol for Low power and Lossy Networks RPL: IPv6 Routing Protocol for Low power and Lossy Networks
draft-ietf-roll-rpl-18 draft-ietf-roll-rpl-19
Abstract Abstract
Low power and Lossy Networks (LLNs) are a class of network in which Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by energy (battery power). Their interconnects are characterized by
high loss rates, low data rates, and instability. LLNs are comprised high loss rates, low data rates, and instability. LLNs are comprised
of anything from a few dozen and up to thousands of routers. of anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices Supported traffic flows include point-to-point (between devices
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 13 skipping to change at page 4, line 13
6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 41 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 41
6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 43 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 43
6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 43 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 43
6.5. Destination Advertisement Object Acknowledgement 6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 43 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 43
6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 43 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 43
6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 45 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 45
6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 45 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 45
6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 45 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 45
6.6.1. Format of the CC Base Object . . . . . . . . . . . . 45 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 45
6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 46 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 47
6.7. RPL Control Message Options . . . . . . . . . . . . . . 46 6.7. RPL Control Message Options . . . . . . . . . . . . . . 47
6.7.1. RPL Control Message Option Generic Format . . . . . . 46 6.7.1. RPL Control Message Option Generic Format . . . . . . 47
6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 47 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 48
6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 48 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 48
6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 48 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 49
6.7.5. Route Information . . . . . . . . . . . . . . . . . . 49 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 50
6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 51 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 51
6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 53 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 53
6.7.8. Transit Information . . . . . . . . . . . . . . . . . 54 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 55
6.7.9. Solicited Information . . . . . . . . . . . . . . . . 57 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 58
6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 59 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 59
6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 61 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 62
7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 63 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 63 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 64
7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 64 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 65
8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 66 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 66 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 67
8.2. Upward Route Discovery and Maintenance . . . . . . . . . 67 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 68
8.2.1. Neighbors and Parents within a DODAG Version . . . . 67 8.2.1. Neighbors and Parents within a DODAG Version . . . . 68
8.2.2. Neighbors and Parents across DODAG Versions . . . . . 68 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 69
8.2.3. DIO Message Communication . . . . . . . . . . . . . . 73 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 74
8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 73 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 74
8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 74 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 75
8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 74 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 75
8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 75 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 76
8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 76 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 77
9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 77 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 78
9.1. Destination Advertisement Parents . . . . . . . . . . . 77 9.1. Destination Advertisement Parents . . . . . . . . . . . 78
9.2. Downward Route Discovery and Maintenance . . . . . . . . 78 9.2. Downward Route Discovery and Maintenance . . . . . . . . 79
9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 79 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 80
9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 79 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 80
9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 80 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 81
9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 80 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 81
9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 83 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 84
9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 83 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 84
9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 84 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 85
9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 85 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 86
9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 86 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 87
9.9.1. Path Control Example . . . . . . . . . . . . . . . . 87 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 88
9.10. Multicast Destination Advertisement Messages . . . . . . 89 9.10. Multicast Destination Advertisement Messages . . . . . . 90
10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 90 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 91
10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 91
10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 92
10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 93
10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 93
10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 94
10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 95
10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 96
10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 96 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 97
10.8. Coverage of Integrity and Confidentiality . . . . . . . 97 10.8. Coverage of Integrity and Confidentiality . . . . . . . 98
10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 97 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 98
10.9.1. CCM Nonce . . . . . . . . . . . . . . . . . . . . . . 97 10.9.1. CCM Nonce . . . . . . . . . . . . . . . . . . . . . . 98
10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 98 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 99
11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 100 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 101
11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 100 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 101
11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 101 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 102
11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 102 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 103
11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 102 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 103
12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 105 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 106
13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 107 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 108
14. Guidelines for Objective Functions . . . . . . . . . . . . . 108 14. Guidelines for Objective Functions . . . . . . . . . . . . . 109
14.1. Objective Function Behavior . . . . . . . . . . . . . . 108 14.1. Objective Function Behavior . . . . . . . . . . . . . . 109
15. Suggestions for Interoperation with Neighbor Discovery . . . 110 15. Suggestions for Interoperation with Neighbor Discovery . . . 111
16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 111 16. Summary of Requirements for Interoperable Implementations . . 112
17. Manageability Considerations . . . . . . . . . . . . . . . . 113 16.1. Common Requirements . . . . . . . . . . . . . . . . . . 112
17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 113 16.2. Operation as a RPL Leaf Node (only) . . . . . . . . . . 112
17.2. Configuration Management . . . . . . . . . . . . . . . . 114 16.3. Operation as a RPL Router . . . . . . . . . . . . . . . 113
17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 114 16.3.1. Support for Upward Routes only . . . . . . . . . . . 113
17.2.2. DIO and DAO Base Message and Options Configuration . 115 16.3.2. Support for Upward Routes and Downward Routes in
17.2.3. Protocol Parameters to be configured on every Non-Storing mode . . . . . . . . . . . . . . . . . . 113
router in the LLN . . . . . . . . . . . . . . . . . . 115 16.3.3. Support for Upward Routes and Downward Routes in
17.2.4. Protocol Parameters to be configured on every Storing mode . . . . . . . . . . . . . . . . . . . . 114
non-DODAG-root router in the LLN . . . . . . . . . . 116 16.4. Items for Future Specification . . . . . . . . . . . . . 114
17.2.5. Parameters to be configured on the DODAG root . . . . 116 17. RPL Constants and Variables . . . . . . . . . . . . . . . . . 115
17.2.6. Configuration of RPL Parameters related to 18. Manageability Considerations . . . . . . . . . . . . . . . . 117
DAO-based mechanisms . . . . . . . . . . . . . . . . 117 18.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 117
17.2.7. Configuration of RPL Parameters related to 18.2. Configuration Management . . . . . . . . . . . . . . . . 118
Security mechanisms . . . . . . . . . . . . . . . . . 118 18.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 118
17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 119 18.2.2. DIO and DAO Base Message and Options Configuration . 119
17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 119 18.2.3. Protocol Parameters to be configured on every
17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 119 router in the LLN . . . . . . . . . . . . . . . . . . 119
17.3.2. Monitoring a DODAG inconsistencies and loop 18.2.4. Protocol Parameters to be configured on every
detection . . . . . . . . . . . . . . . . . . . . . . 120 non-DODAG-root router in the LLN . . . . . . . . . . 120
17.4. Monitoring of the RPL data structures . . . . . . . . . 121 18.2.5. Parameters to be configured on the DODAG root . . . . 120
17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 121 18.2.6. Configuration of RPL Parameters related to
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) DAO-based mechanisms . . . . . . . . . . . . . . . . 121
Table . . . . . . . . . . . . . . . . . . . . . . . . 121
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 122 18.2.7. Configuration of RPL Parameters related to
17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 123 Security mechanisms . . . . . . . . . . . . . . . . . 122
17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 123 18.2.8. Default Values . . . . . . . . . . . . . . . . . . . 123
17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 124 18.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 123
17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 125 18.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 123
17.9. Performance Management . . . . . . . . . . . . . . . . . 125 18.3.2. Monitoring a DODAG inconsistencies and loop
17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 125 detection . . . . . . . . . . . . . . . . . . . . . . 124
18. Security Considerations . . . . . . . . . . . . . . . . . . . 126 18.4. Monitoring of the RPL data structures . . . . . . . . . 125
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 126 18.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 125
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128 18.4.2. Destination Oriented Directed Acyclic Graph (DAG)
19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 128 Table . . . . . . . . . . . . . . . . . . . . . . . . 125
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 128 18.4.3. Routing Table and DAO Routing Entries . . . . . . . . 126
19.3. New Registry for the Mode of Operation (MOP) . . . . . . 129 18.5. Fault Management . . . . . . . . . . . . . . . . . . . . 127
19.4. RPL Control Message Option . . . . . . . . . . . . . . . 130 18.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 127
19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 130 18.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 128
19.6. New Registry for the Security Section Algorithm . . . . 131 18.8. Impact on Other Protocols . . . . . . . . . . . . . . . 129
19.7. New Registry for the Security Section Flags . . . . . . 131 18.9. Performance Management . . . . . . . . . . . . . . . . . 129
19.8. New Registry for Per-KIM Security Levels . . . . . . . . 132 18.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 129
19.9. New Registry for the DIS (DODAG Informational 19. Security Considerations . . . . . . . . . . . . . . . . . . . 130
Solicitation) Flags . . . . . . . . . . . . . . . . . . 133 19.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 130
19.10. New Registry for the DODAG Information Object (DIO) 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 132
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 134 20.1. RPL Control Message . . . . . . . . . . . . . . . . . . 132
19.11. New Registry for the Destination Advertisement Object 20.2. New Registry for RPL Control Codes . . . . . . . . . . . 132
(DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 134 20.3. New Registry for the Mode of Operation (MOP) . . . . . . 133
19.12. New Registry for the Destination Advertisement Object 20.4. RPL Control Message Option . . . . . . . . . . . . . . . 134
(DAO) Acknowledgement Flags . . . . . . . . . . . . . . 135 20.5. Objective Code Point (OCP) Registry . . . . . . . . . . 134
19.13. New Registry for the Consistency Check (CC) Flags . . . 135 20.6. New Registry for the Security Section Algorithm . . . . 135
19.14. New Registry for the DODAG Configuration Option Flags . 136 20.7. New Registry for the Security Section Flags . . . . . . 135
19.15. New Registry for the RPL Target Option Flags . . . . . . 136 20.8. New Registry for Per-KIM Security Levels . . . . . . . . 136
19.16. New Registry for the Transit Information Option Flags . 137 20.9. New Registry for the DIS (DODAG Informational
19.17. New Registry for the Solicited Information Option Solicitation) Flags . . . . . . . . . . . . . . . . . . 137
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 137 20.10. New Registry for the DODAG Information Object (DIO)
19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 138 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 138
19.19. Link-Local Scope multicast address . . . . . . . . . . . 138 20.11. New Registry for the Destination Advertisement Object
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 138
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 140 20.12. New Registry for the Destination Advertisement Object
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 141 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 139
22.1. Normative References . . . . . . . . . . . . . . . . . . 141 20.13. New Registry for the Consistency Check (CC) Flags . . . 139
22.2. Informative References . . . . . . . . . . . . . . . . . 142 20.14. New Registry for the DODAG Configuration Option Flags . 140
Appendix A. Example Operation . . . . . . . . . . . . . . . . . 145 20.15. New Registry for the RPL Target Option Flags . . . . . . 140
20.16. New Registry for the Transit Information Option Flags . 141
20.17. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 141
20.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 142
20.19. Link-Local Scope multicast address . . . . . . . . . . . 142
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 143
22. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 144
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 145
23.1. Normative References . . . . . . . . . . . . . . . . . . 145
23.2. Informative References . . . . . . . . . . . . . . . . . 146
Appendix A. Example Operation . . . . . . . . . . . . . . . . . 149
A.1. Example Operation in Storing Mode With Node-owned A.1. Example Operation in Storing Mode With Node-owned
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 145 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 149
A.1.1. DIO messages and PIO . . . . . . . . . . . . . . . . 146 A.1.1. DIO messages and PIO . . . . . . . . . . . . . . . . 150
A.1.2. DAO messages . . . . . . . . . . . . . . . . . . . . 147 A.1.2. DAO messages . . . . . . . . . . . . . . . . . . . . 151
A.1.3. Routing Information Base . . . . . . . . . . . . . . 147 A.1.3. Routing Information Base . . . . . . . . . . . . . . 151
A.2. Example Operation in Storing Mode With Subnet-wide A.2. Example Operation in Storing Mode With Subnet-wide
Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 148 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 152
A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 153
A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 149 A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 154
A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 150 A.2.3. Routing Information Base . . . . . . . . . . . . . . 154
A.2.3. Routing Information Base . . . . . . . . . . . . . . 150
A.3. Example Operation in Non-Storing Mode With Node-owned A.3. Example Operation in Non-Storing Mode With Node-owned
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 151 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 155
A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 152 A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 156
A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 152 A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 156
A.3.3. Routing Information Base . . . . . . . . . . . . . . 153 A.3.3. Routing Information Base . . . . . . . . . . . . . . 157
A.4. Example Operation in Non-Storing Mode With A.4. Example Operation in Non-Storing Mode With
Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 153 Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 157
A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 154 A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 158
A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 155 A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 159
A.4.3. Routing Information Base . . . . . . . . . . . . . . 155 A.4.3. Routing Information Base . . . . . . . . . . . . . . 159
A.5. Example with External Prefixes . . . . . . . . . . . . . 156 A.5. Example with External Prefixes . . . . . . . . . . . . . 160
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
1. Introduction 1. Introduction
Low power and Lossy Networks (LLNs) consist of largely of constrained Low power and Lossy Networks (LLNs) consist of largely of constrained
nodes (with limited processing power, memory, and sometimes energy nodes (with limited processing power, memory, and sometimes energy
when they are battery operated or energy scavenging). These routers when they are battery operated or energy scavenging). These routers
are interconnected by lossy links, typically supporting only low data are interconnected by lossy links, typically supporting only low data
rates, that are usually unstable with relatively low packet delivery rates, that are usually unstable with relatively low packet delivery
rates. Another characteristic of such networks is that the traffic rates. Another characteristic of such networks is that the traffic
patterns are not simply point-to-point, but in many cases point-to- patterns are not simply point-to-point, but in many cases point-to-
skipping to change at page 8, line 46 skipping to change at page 8, line 46
In order to be useful in a wide range of LLN application domains, RPL In order to be useful in a wide range of LLN application domains, RPL
separates packet processing and forwarding from the routing separates packet processing and forwarding from the routing
optimization objective. Examples of such objectives include optimization objective. Examples of such objectives include
minimizing energy, minimizing latency, or satisfying constraints. minimizing energy, minimizing latency, or satisfying constraints.
This document describes the mode of operation of RPL. Other This document describes the mode of operation of RPL. Other
companion documents specify routing objective functions. A RPL companion documents specify routing objective functions. A RPL
implementation, in support of a particular LLN application, will implementation, in support of a particular LLN application, will
include the necessary objective function(s) as required by the include the necessary objective function(s) as required by the
application. application.
RPL operations require bidirectional links. It is required that the RPL operations require bidirectional links. In some LLN scenarios
reachability of a router is verified before the router can be used as those links may exhibit asymmetric properties. It is required that
a parent. RPL expects an external mechanism to be triggered during the reachability of a router is verified before the router can be
the parent selection phase in order to verify link properties and used as a parent. RPL expects an external mechanism to be triggered
neighbor reachability. Neighbor Unreachability Detection (NUD) is during the parent selection phase in order to verify link properties
such a mechanism, but alternates are possible, including and neighbor reachability. Neighbor Unreachability Detection (NUD)
is such a mechanism, but alternates are possible, including
Bidirectional Forwarding Detection [RFC5881] and hints from lower Bidirectional Forwarding Detection [RFC5881] and hints from lower
layers via L2 triggers like [RFC5184]. In a general fashion, a layers via L2 triggers like [RFC5184]. In a general fashion, a
detection mechanism that is reactive to traffic is favored in order detection mechanism that is reactive to traffic is favored in order
to minimize the cost of monitoring links that are not being used. to minimize the cost of monitoring links that are not being used.
RPL also expects an external mechanism to access and transport some RPL also expects an external mechanism to access and transport some
control information, referred to as the "RPL Packet Information", in control information, referred to as the "RPL Packet Information", in
data packets. The RPL Packet Information is defined in Section 11.2 data packets. The RPL Packet Information is defined in Section 11.2
and enables the association of a data packet with a RPL instance and and enables the association of a data packet with a RPL instance and
the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option
skipping to change at page 31, line 48 skipping to change at page 31, line 48
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RPL Control Message Figure 6: RPL Control Message
The RPL Control message is an ICMPv6 information message with a The RPL Control message is an ICMPv6 information message with a
requested Type of 155 (to be confirmed by IANA). requested Type of 155 (to be confirmed by IANA).
The Code field identifies the type of RPL Control Message. This The Code field identifies the type of RPL Control Message. This
document defines codes for the following RPL Control Message types document defines codes for the following RPL Control Message types
(all codes are to be confirmed by IANA Section 19.2): (all codes are to be confirmed by IANA Section 20.2):
o 0x00: DODAG Information Solicitation (Section 6.2) o 0x00: DODAG Information Solicitation (Section 6.2)
o 0x01: DODAG Information Object (Section 6.3) o 0x01: DODAG Information Object (Section 6.3)
o 0x02: Destination Advertisement Object (Section 6.4) o 0x02: Destination Advertisement Object (Section 6.4)
o 0x03: Destination Advertisement Object Acknowledgment o 0x03: Destination Advertisement Object Acknowledgment
(Section 6.5) (Section 6.5)
skipping to change at page 34, line 19 skipping to change at page 34, line 19
ICMPv6 checksum temporarily set to zero. Encryption provides ICMPv6 checksum temporarily set to zero. Encryption provides
confidentiality of the secured RPL ICMPv6 message starting at the confidentiality of the secured RPL ICMPv6 message starting at the
first byte after the Security section and continuing to the last byte first byte after the Security section and continuing to the last byte
of the packet. The security transformation yields a secured ICMPv6 of the packet. The security transformation yields a secured ICMPv6
RPL message with the inclusion of the cryptographic fields (MAC, RPL message with the inclusion of the cryptographic fields (MAC,
signature, etc.). In other words, the security transformation itself signature, etc.). In other words, the security transformation itself
(e.g. the Signature and/or Algorithm in use) will detail how to (e.g. the Signature and/or Algorithm in use) will detail how to
incorporate the cryptographic fields into the secured packet. The incorporate the cryptographic fields into the secured packet. The
Security section itself does not explicitly carry those cryptographic Security section itself does not explicitly carry those cryptographic
fields. Use of the Security section is further detailed in fields. Use of the Security section is further detailed in
Section 18 and Section 10. Section 19 and Section 10.
Counter is Time (T): If the Counter is Time flag is set then the 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 field is a timestamp. If the flag is cleared then the
Counter is an incrementing counter. Section 10.5 describes the Counter is an incrementing counter. Section 10.5 describes the
details of the 'T' flag and Counter field. details of the 'T' flag and Counter field.
Reserved: 7-bit unused field. The field MUST be initialized to zero Reserved: 7-bit unused field. The field MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
Security Algorithm (Algorithm): The Security Algorithm field Security Algorithm (Algorithm): The Security Algorithm field
skipping to change at page 44, line 41 skipping to change at page 44, line 41
Flags: The 7-bits remaining unused in the Flags field are reserved Flags: The 7-bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender for flags. The field MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
DAOSequence: Incremented at each DAO message from a node, and echoed DAOSequence: Incremented at each DAO message from a node, and echoed
in the DAO-ACK by the recipient. The DAOSequence is used to 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 correlate a DAO message and a DAO ACK message and is not to be
confused with the Transit Information option Path Sequence that confused with the Transit Information option Path Sequence that
is associated to a given target Down the DODAG. is associated to a given target Down the DODAG.
Status: Indicates the completion. Status 0 is unqualified Status: Indicates the completion. Status 0 is defined as
acceptance, 1 to 127 are unassigned and undetermined, and 128 unqualified acceptance in this specification. The remaining
and greater are rejection codes used to indicate that the node status values are reserved as rejection codes. No rejection
should select an alternate parent. No rejection codes are status codes are defined in this specification, although status
defined in this specification. Rejection codes are to be codes SHOULD be allocated according to the following guidelines
elaborated in future specifications. in future specifications:
0: Unqualified acceptance (i.e. the node receiving the
DAO-ACK is not rejected).
1-127: Not an outright rejection; the node sending the DAO-
ACK is willing to act as a Parent, but the receiving
node is suggested to find and use an alternate parent
instead.
127-255: Rejection; the node sending the DAO-ACK is unwilling
to act as a Parent.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root DODAGID (optional): 128-bit unsigned integer set by a DODAG root
which uniquely identifies a DODAG. This field is only present which uniquely identifies a DODAG. This field is only present
when the 'D' flag is set. This field is typically 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 when a local RPLInstanceID is in use, in order to identify the
DODAGID that is associated with the RPLInstanceID. When a DODAGID that is associated with the RPLInstanceID. When a
global RPLInstanceID is in use this field need not be present. global RPLInstanceID is in use this field need not be present.
Unassigned bits of the DAO-ACK Base are reserved. They MUST be set Unassigned bits of the DAO-ACK Base are reserved. They MUST be set
to zero on transmission and MUST be ignored on reception. to zero on transmission and MUST be ignored on reception.
skipping to change at page 47, line 14 skipping to change at page 47, line 33
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Option Type | Option Length | Option Data | Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 19: RPL Option Generic Format Figure 19: RPL Option Generic Format
Option Type: 8-bit identifier of the type of option. The Option Option Type: 8-bit identifier of the type of option. The Option
Type values are to be confirmed by IANA Section 19.4. Type values are to be confirmed by IANA Section 20.4.
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields. fields.
Option Data: A variable length field that contains data specific to Option Data: A variable length field that contains data specific to
the option. the option.
When processing a RPL message containing an option for which the When processing a RPL message containing an option for which the
Option Type value is not recognized by the receiver, the receiver Option Type value is not recognized by the receiver, the receiver
skipping to change at page 68, line 51 skipping to change at page 69, line 51
3. A node MUST NOT send DIOs for DODAG Versions of which it is not a 3. A node MUST NOT send DIOs for DODAG Versions of which it is not a
member. member.
4. DODAG roots MAY increment the DODAGVersionNumber that they 4. DODAG roots MAY increment the DODAGVersionNumber that they
advertise and thus move to a new DODAG Version. When a DODAG advertise and thus move to a new DODAG Version. When a DODAG
root increments its DODAGVersionNumber, it MUST follow the root increments its DODAGVersionNumber, it MUST follow the
conventions of Serial Number Arithmetic as described in conventions of Serial Number Arithmetic as described in
Section 7. Events triggering the increment of the Section 7. Events triggering the increment of the
DODAGVersionNumber are described later in this section and in DODAGVersionNumber are described later in this section and in
Section 17. Section 18.
5. Within a given DODAG, a node that is a not a root MUST NOT 5. Within a given DODAG, a node that is a not a root MUST NOT
advertise a DODAGVersionNumber higher than the highest advertise a DODAGVersionNumber higher than the highest
DODAGVersionNumber it has heard. Higher is defined as the DODAGVersionNumber it has heard. Higher is defined as the
greater-than operator in Section 7. greater-than operator in Section 7.
6. Once a node has advertised a DODAG Version by sending a DIO, it 6. Once a node has advertised a DODAG Version by sending a DIO, it
MUST NOT be a member of a previous DODAG Version of the same MUST NOT be a member of a previous DODAG Version of the same
DODAG (i.e. with the same RPLInstanceID, the same DODAGID, and a DODAG (i.e. with the same RPLInstanceID, the same DODAGID, and a
lower DODAGVersionNumber). Lower is defined as the less-than lower DODAGVersionNumber). Lower is defined as the less-than
operator in Section 7. operator in Section 7.
When the DODAG parent set becomes empty on a node that is not a root, When the DODAG parent set becomes empty on a node that is not a root,
(i.e. the last parent has been removed, causing the node to no longer (i.e. the last parent has been removed, causing the node to no longer
be associated with that DODAG), then the DODAG information should not be associated with that DODAG), then the DODAG information should not
be suppressed until after the expiration of an implementation- be suppressed until after the expiration of an implementation-
specific local timer in order to observe if the DODAGVersionNumber specific local timer. During the interval prior to suppression of
has been incremented, should any new parents appear for the DODAG. the 'old' DODAG state, the node will be able to observe if the
This will help protect against the possibility of loops that may DODAGVersionNumber has been incremented should any new parents
occur if that node were to inadvertently rejoin the old DODAG Version appear. This will help protect against the possibility of loops that
in its own prior sub-DODAG. may occur if that node were to inadvertently rejoin the old DODAG
Version in its own prior sub-DODAG.
As the DODAGVersionNumber is incremented, a new DODAG Version spreads As the DODAGVersionNumber is incremented, a new DODAG Version spreads
outward from the DODAG root. A parent that advertises the new outward from the DODAG root. A parent that advertises the new
DODAGVersionNumber cannot belong to the sub-DODAG of a node DODAGVersionNumber cannot belong to the sub-DODAG of a node
advertising an older DODAGVersionNumber. Therefore a node can safely advertising an older DODAGVersionNumber. Therefore a node can safely
add a parent of any Rank with a newer DODAGVersionNumber without add a parent of any Rank with a newer DODAGVersionNumber without
forming a loop. forming a loop.
For example, suppose that a node has left a DODAG with For example, suppose that a node has left a DODAG with
DODAGVersionNumber N. Suppose that node had a sub-DODAG, and did DODAGVersionNumber N. Suppose that node had a sub-DODAG, and did
skipping to change at page 72, line 27 skipping to change at page 73, line 27
its parent set. its parent set.
Although an implementation may advertise INFINITE_RANK for the Although an implementation may advertise INFINITE_RANK for the
purposes of poisoning, doing so is not the same as setting Rank to purposes of poisoning, doing so is not the same as setting Rank to
INFINITE_RANK. For example, a node may continue to send data packets INFINITE_RANK. For example, a node may continue to send data packets
whose RPL Packet Information includes a Rank that is not whose RPL Packet Information includes a Rank that is not
INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs. INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs.
When a (former) parent is observed to advertise a Rank of When a (former) parent is observed to advertise a Rank of
INFINITE_RANK, that (former) parent has detached from the DODAG and INFINITE_RANK, that (former) parent has detached from the DODAG and
is no longer able to act as a parent, nor is there any why that is no longer able to act as a parent, nor is there any way that
another node may be considered to have a Rank greater-than another node may be considered to have a Rank greater-than
INFINITE_RANK. Therefore that (former) parent cannot act as a parent INFINITE_RANK. Therefore that (former) parent cannot act as a parent
any longer and is removed from the parent set. any longer and is removed from the parent set.
8.2.2.6. Detaching 8.2.2.6. Detaching
1. A node unable to stay connected to a DODAG within a given DODAG 1. A node unable to stay connected to a DODAG within a given DODAG
Version, i.e. that cannot retain non-empty parent set without Version, i.e. that cannot retain non-empty parent set without
violating the rules of this specification, MAY detach from this violating the rules of this specification, MAY detach from this
DODAG Version. A node that detaches becomes root of its own DODAG Version. A node that detaches becomes root of its own
skipping to change at page 73, line 14 skipping to change at page 74, line 14
8.2.3. DIO Message Communication 8.2.3. DIO Message Communication
When an DIO message is received, the receiving node must first When an DIO message is received, the receiving node must first
determine whether or not the DIO message should be accepted for determine whether or not the DIO message should be accepted for
further processing, and subsequently present the DIO message for further processing, and subsequently present the DIO message for
further processing if eligible. further processing if eligible.
1. If the DIO message is malformed, then the DIO message is not 1. If the DIO message is malformed, then the DIO message is not
eligible for further processing and a node MUST silently discard eligible for further processing and a node MUST silently discard
it. (See Section 17 for error logging). it. (See Section 18 for error logging).
2. If the sender of the DIO message is a member of the candidate 2. If the sender of the DIO message is a member of the candidate
neighbor set and the DIO message is not malformed, the node MUST neighbor set and the DIO message is not malformed, the node MUST
process the DIO. process the DIO.
8.2.3.1. DIO Message Processing 8.2.3.1. DIO Message Processing
As DIO messages are received from candidate neighbors, the neighbors As DIO messages are received from candidate neighbors, the neighbors
may be promoted to DODAG parents by following the rules of DODAG may be promoted to DODAG parents by following the rules of DODAG
discovery as described in Section 8.2. When a node places a neighbor discovery as described in Section 8.2. When a node places a neighbor
skipping to change at page 75, line 17 skipping to change at page 76, line 17
A node SHOULD verify that bidirectional connectivity and adequate A node SHOULD verify that bidirectional connectivity and adequate
link quality is available with a candidate neighbor before it link quality is available with a candidate neighbor before it
considers that candidate as a DODAG parent. considers that candidate as a DODAG parent.
8.5. Operation as a Leaf Node 8.5. Operation as a Leaf Node
In some cases a RPL node may attach to a DODAG as a leaf node only. In some cases a RPL node may attach to a DODAG as a leaf node only.
One example of such a case is when a node does not understand or does One example of such a case is when a node does not understand or does
not support (policy) the RPL Instance's OF or advertised metric/ not support (policy) the RPL Instance's OF or advertised metric/
constraint. As specified in Section 17.6 related to policy function, constraint. As specified in Section 18.6 related to policy function,
the node may either join the DODAG as a leaf node or may not join the the node may either join the DODAG as a leaf node or may not join the
DODAG. As mentioned in Section 17.5, it is then recommended to log a DODAG. As mentioned in Section 18.5, it is then recommended to log a
fault. fault.
A leaf node does not extend DODAG connectivity but in some cases the A leaf node does not extend DODAG connectivity but in some cases the
leaf node may still need to transmit DIOs on occasion, in particular leaf node may still need to transmit DIOs on occasion, in particular
when the leaf node may not have always been acting as a leaf node and when the leaf node may not have always been acting as a leaf node and
an inconsistency is detected. an inconsistency is detected.
A node operating as a leaf node must obey the following rules: A node operating as a leaf node must obey the following rules:
1. It MUST NOT transmit DIOs containing the DAG Metric Container. 1. It MUST NOT transmit DIOs containing the DAG Metric Container.
skipping to change at page 78, line 23 skipping to change at page 79, line 23
1. All nodes who join a DODAG MUST abide by the MOP setting from the 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 root. Nodes that do not have the capability to fully participate
as a router, e.g. that does not match the advertised MOP, MAY as a router, e.g. that does not match the advertised MOP, MAY
join the DODAG as a leaf. join the DODAG as a leaf.
2. If the MOP is 0, indicating no downward routing, nodes MUST NOT 2. If the MOP is 0, indicating no downward routing, nodes MUST NOT
transmit DAO messages, and MAY ignore DAO messages. transmit DAO messages, and MAY ignore DAO messages.
3. In non-storing mode, the DODAG Root SHOULD store source routing 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. The DODAG Root
MUST be able to generate source routes for those destinations
learned from DAOs which were stored.
4. In storing mode, all non-root, non-leaf nodes MUST store routing 4. In storing mode, all non-root, non-leaf nodes MUST store routing
table entries for destinations learned from DAOs. table entries for destinations learned from DAOs.
A DODAG can have one of several possible modes of operation, as A DODAG can have one of several possible modes of operation, as
defined by the MOP field. Either it does not support downward defined by the MOP field. Either it does not support downward
routes, it supports downward routes through source routing from DODAG routes, it supports downward routes through source routing from DODAG
Roots, or it supports downward routes through in-network routing Roots, or it supports downward routes through in-network routing
tables. tables.
When downward routes are supported through source routing from DODAG When downward routes are supported through source routing from DODAG
Roots, it is generally expected that the DODAG Root has stored the Roots, it is generally expected that the DODAG Root has stored the
source routing information learned from DAOs in order to construct source routing information learned from DAOs in order to construct
the source routes. If the DODAG Root fails to store some the source routes. If the DODAG Root fails to store some
information, then some destinations may be unreachable. A particular information, then some destinations may be unreachable.
implementation may choose to discard the source routing information
in some cases as required by implementation specific constraints. In
that case it is necessary for the implementation to accommodate an
appropriate behavior if it does not store all of the source routing
information, for example a policy of storing DAOs for the 'most
recently used' routes.
When downward routes are supported through in-network routing tables, When downward routes are supported through in-network routing tables,
the multicast operation defined in this specification may or may not the multicast operation defined in this specification may or may not
be supported, also as indicated by the MOP field. be supported, also as indicated by the MOP field.
When downward routes are supported through in-network routing tables When downward routes are supported through in-network routing tables
as described in this specification, it is expected that nodes acting as described in this specification, it is expected that nodes acting
as routers have been provisioned sufficiently to hold the required as routers have been provisioned sufficiently to hold the required
routing table state. If a node acting as a router is unable to hold routing table state. If a node acting as a router is unable to hold
the full routing table state then the routing state is not complete, the full routing table state then the routing state is not complete,
messages may be dropped as a consequence, and a fault may be logged messages may be dropped as a consequence, and a fault may be logged
(Section 17.5). Future extensions to RPL may elaborate on refined (Section 18.5). Future extensions to RPL may elaborate on refined
actions/behaviors to manage this case. actions/behaviors to manage this case.
As of this specification RPL does not support mixed-mode operation, As of this specification RPL does not support mixed-mode operation,
where some nodes source route and other store routing tables: future where some nodes source route and other store routing tables: future
extensions to RPL may support this mode of operation. extensions to RPL may support this mode of operation.
9.2.1. Maintenance of Path Sequence 9.2.1. Maintenance of Path Sequence
For each Target that is associated with (owned by) a node, that node For each Target that is associated with (owned by) a node, that node
is responsible to emit DAO messages in order to provision the is responsible to emit DAO messages in order to provision the
skipping to change at page 100, line 35 skipping to change at page 101, line 35
2. If a local administrative preference favors a route that has been 2. If a local administrative preference favors a route that has been
learned from a different routing protocol than RPL, then use that learned from a different routing protocol than RPL, then use that
successor. successor.
3. If the packet header specifies a source route by including a RH4 3. If the packet header specifies a source route by including a RH4
header as specified in [I-D.ietf-6man-rpl-routing-header], then header as specified in [I-D.ietf-6man-rpl-routing-header], then
use that route. If the node fails to forward the packet with use that route. If the node fails to forward the packet with
that specified source route, then that packet should be dropped. that specified source route, then that packet should be dropped.
The node MAY log an error. The node may send an ICMPv6 Error in The node MAY log an error. The node may send an ICMPv6 Error in
Source Routing Header message to the source of the packet (See Source Routing Header message to the source of the packet (See
Section 19.18). Section 20.18).
4. If there is an entry in the routing table matching the 4. If there is an entry in the routing table matching the
destination that has been learned from a multicast destination destination that has been learned from a multicast destination
advertisement (e.g. the destination is a one-hop neighbor), then advertisement (e.g. the destination is a one-hop neighbor), then
use that successor. use that successor.
5. If there is an entry in the routing table matching the 5. If there is an entry in the routing table matching the
destination that has been learned from a unicast destination destination that has been learned from a unicast destination
advertisement (e.g. the destination is located Down the sub- advertisement (e.g. the destination is located Down the sub-
DODAG), then use that successor. If there are DAO Path Control DODAG), then use that successor. If there are DAO Path Control
skipping to change at page 111, line 5 skipping to change at page 112, line 5
boundaries. boundaries.
o When mapping/transposing an IPv6 ND option for redistribution as a o When mapping/transposing an IPv6 ND option for redistribution as a
RPL option, any padding octets should be removed when possible. RPL option, any padding octets should be removed when possible.
For example, the Prefix Length field in the PIO is sufficient to For example, the Prefix Length field in the PIO is sufficient to
describe the length of the Prefix field. When mapping/transposing describe the length of the Prefix field. When mapping/transposing
a RPL option for redistribution as an IPv6 ND option, any such a RPL option for redistribution as an IPv6 ND option, any such
padding octets should be restored. This procedure must be padding octets should be restored. This procedure must be
unambiguous. unambiguous.
16. RPL Constants and Variables 16. Summary of Requirements for Interoperable Implementations
This section summarizes basic interoperability and references
normative text for RPL implementations operating in one of three
major modes. Implementations are expected to support either no
downward routes, non-storing mode only, or storing mode only. A
fourth mode, operation as a leaf, is also possible.
Implementations conforming to this specification may contain
different subsets of capabilities as appropriate to the application
scenario. It is important for the implementer to support a level of
interoperability consistent with that required by the application
scenario. To this end, further guidance may be provided beyond this
specification (e.g. as applicability statements), and it is
understood that in some cases such further guidance may override
portions of this specification.
16.1. Common Requirements
In a general case the greatest level of interoperability may be
achieved when all of the nodes in a RPL LLN are cooperating to use
the same MOP, OF, metrics, and constraints, and are thus able to act
as RPL Routers. When a node is not capable to be a RPL Router it may
be possible to interoperate in a more limited manner as a RPL leaf.
All RPL implementations need to support the use of RPL Packet
Information transported within data packets (Section 11.2). One such
mechanism is described in [I-D.ietf-6man-rpl-option].
RPL implementations will need to support the use of Neighbor
Unreachability Detection (NUD), or an equivalent mechanism, to
maintain the reachability of neighboring RPL nodes (Section 8.2.1).
Alternate mechanisms may be optimized to the constrained capabilities
of the implementation, such as hints from the link layer.
This specification provides means to obtain a PIO and thus form an
IPv6 address. When that mechanism is used it may be necessary to
perform address resolution and duplicate address detection through an
external process, such as IPv6 ND ([RFC4861]) or 6LoWPAN ND
([I-D.ietf-6lowpan-nd]).
16.2. Operation as a RPL Leaf Node (only)
o An implementation of a Leaf Node (only) does not ever participate
as a RPL Router. Interoperable implementations of leaf nodes
behave as summarized in Section 8.5.
o Support of a particular MOP encoding is not required, although if
the leaf node sends DAO messages to setup downward routes the leaf
node should do so in a manner consistent with the mode of
operation described by the MOP.
o Support of a particular OF is not required.
o In brief summary, a leaf node does not generally issue DIO
messages, it may issue DAO and DIS messages. A leaf node accepts
DIO messages though it generally ignores DAO and DIS messages.
16.3. Operation as a RPL Router
If further guidance is not available then a RPL Router implementation
MUST at least support the metric-less OF0 [I-D.ietf-roll-of0].
For consistent operation a RPL Router implementation needs to support
the MOP in use by the DODAG.
All RPL Routers will need to implement Trickle
([I-D.ietf-roll-trickle])
16.3.1. Support for Upward Routes only
An implementation of a RPL router that supports only Upward Routes
supports the following:
o Upward Routes (Section 8)
o MOP encoding 0 (Section 20.3)
o In brief summary DIO and DIS messages are issued, and DAO messages
are not issued. DIO and DIS messages are accepted, and DAO
messages are ignored.
16.3.2. Support for Upward Routes and Downward Routes in Non-Storing
mode
An implementation of a RPL router that supports Upward Routes and
Downward Routes in Non-Storing mode supports the following:
o Upward Routes (Section 8)
o Downward Routes (Non-Storing) (Section 9)
o MOP encoding 1 (Section 20.3)
o Source-routed downward traffic
([I-D.ietf-6man-rpl-routing-header])
o In brief summary DIO and DIS messages are issued, and DAO messages
are issued to the DODAG Root. DIO and DIS messages are accepted,
and DAO messages are ignored by nodes other than DODAG Roots.
Multicast is not supported through the means described in this
specification, though it may be supported through some alternate
means.
16.3.3. Support for Upward Routes and Downward Routes in Storing mode
An implementation of a RPL router that supports Upward Routes and
Downward Routes in Storing mode supports the following:
o Upward Routes (Section 8)
o Downward Routes (Storing) (Section 9)
o MOP encoding 2 (Section 20.3)
o In brief summary DIO, DIS, and DAO messages are issued. DIO, DIS,
and DAO messages are accepted. Multicast is not supported through
the means described in this specification, though it may be
supported through some alternate means.
16.3.3.1. Optional support for basic multicast scheme
A Storing mode implementation may be enhanced with basic multicast
support through the following additions:
o Basic Multicast Support (Section 12)
o MOP encoding 3 (Section 20.3)
16.4. Items for Future Specification
A number of items are left to future specification, including but not
limited to:
o How to attach a non-RPL node such as an IPv6 host, e.g. to
consistently distribute at least PIO material to the attached
node.
o How to obtain authentication material in support if authenticated
mode is used (Section 10.3).
o Details of operation over multiple simultaneous instances.
o Advanced configuration mechanisms, such as provisioning of
RPLInstanceIDs, parameterization of objective functions, and
parameters to control security. (It is expected that such
mechanisms might extend the DIO as a means to disseminate
information across the DODAG).
17. RPL Constants and Variables
Following is a summary of RPL constants and variables: Following is a summary of RPL constants and variables:
BASE_RANK This is the rank for a virtual root that might be used to BASE_RANK This is the rank for a virtual root that might be used to
coordinate multiple roots. BASE_RANK has a value of 0. coordinate multiple roots. BASE_RANK has a value of 0.
ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value
of MinHopRankIncrease (as advertised by the DODAG root), such of MinHopRankIncrease (as advertised by the DODAG root), such
that DAGRank(ROOT_RANK) is 1. that DAGRank(ROOT_RANK) is 1.
skipping to change at page 113, line 5 skipping to change at page 117, line 5
parents chosen to receive destination advertisements) per parents chosen to receive destination advertisements) per
DODAG. Expiry triggers sending of DAO message to the DAO DODAG. Expiry triggers sending of DAO message to the DAO
parent. See Section 9.5 parent. See Section 9.5
RemoveTimer Up to one timer per DAO entry per neighbor (i.e. those RemoveTimer Up to one timer per DAO entry per neighbor (i.e. those
neighbors that have given DAO messages to this node as a DODAG neighbors that have given DAO messages to this node as a DODAG
parent) Expiry may trigger No-Path advertisements or parent) Expiry may trigger No-Path advertisements or
immediately deallocate the DAO entry if there are no DAO immediately deallocate the DAO entry if there are no DAO
parents. parents.
17. Manageability Considerations 18. Manageability Considerations
The aim of this section is to give consideration to the manageability The aim of this section is to give consideration to the manageability
of RPL, and how RPL will be operated in a LLN. The scope of this of RPL, and how RPL will be operated in a LLN. The scope of this
section is to consider the following aspects of manageability: section is to consider the following aspects of manageability:
configuration, monitoring, fault management, accounting, and configuration, monitoring, fault management, accounting, and
performance of the protocol in light of the recommendations set forth performance of the protocol in light of the recommendations set forth
in [RFC5706]. in [RFC5706].
17.1. Introduction 18.1. Introduction
Most of the existing IETF management standards are Structure of Most of the existing IETF management standards are Structure of
Management Information (SMI) based data models (MIB modules) to Management Information (SMI) based data models (MIB modules) to
monitor and manage networking devices. monitor and manage networking devices.
For a number of protocols, the IETF community has used the IETF For a number of protocols, the IETF community has used the IETF
Standard Management Framework, including the Simple Network Standard Management Framework, including the Simple Network
Management Protocol [RFC3410], the Structure of Management Management Protocol [RFC3410], the Structure of Management
Information [RFC2578], and MIB data models for managing new Information [RFC2578], and MIB data models for managing new
protocols. protocols.
skipping to change at page 114, line 9 skipping to change at page 118, line 9
aspects are discussed in detail in the following sections. aspects are discussed in detail in the following sections.
RPL will be used on a variety of devices that may have resources such RPL will be used on a variety of devices that may have resources such
as memory varying from a few Kbytes to several hundreds of Kbytes and as memory varying from a few Kbytes to several hundreds of Kbytes and
even Mbytes. When memory is highly constrained, it may not be even Mbytes. When memory is highly constrained, it may not be
possible to satisfy all the requirements listed in this section. possible to satisfy all the requirements listed in this section.
Still it is worth listing all of these in an exhaustive fashion, and Still it is worth listing all of these in an exhaustive fashion, and
implementers will then determine which of these requirements could be implementers will then determine which of these requirements could be
satisfied according to the available resources on the device. satisfied according to the available resources on the device.
17.2. Configuration Management 18.2. Configuration Management
This section discusses the configuration management, listing the This section discusses the configuration management, listing the
protocol parameters for which configuration management is relevant. protocol parameters for which configuration management is relevant.
Some of the RPL parameters are optional. The requirements for Some of the RPL parameters are optional. The requirements for
configuration are only applicable for the options that are used. configuration are only applicable for the options that are used.
17.2.1. Initialization Mode 18.2.1. Initialization Mode
"Architectural Principles of the Internet" [RFC1958], Section 3.8, "Architectural Principles of the Internet" [RFC1958], Section 3.8,
states: "Avoid options and parameters whenever possible. Any options states: "Avoid options and parameters whenever possible. Any options
and parameters should be configured or negotiated dynamically rather and parameters should be configured or negotiated dynamically rather
than manually." This is especially true in LLNs where the number of than manually." This is especially true in LLNs where the number of
devices may be large and manual configuration is infeasible. This devices may be large and manual configuration is infeasible. This
has been taken into account in the design of RPL whereby the DODAG has been taken into account in the design of RPL whereby the DODAG
root provides a number of parameters to the devices joining the root provides a number of parameters to the devices joining the
DODAG, thus avoiding cumbersome configuration on the routers and DODAG, thus avoiding cumbersome configuration on the routers and
potential sources of misconfiguration (e.g. values of trickle timers, potential sources of misconfiguration (e.g. values of trickle timers,
...). Still there are additional RPL parameters that a RPL ...). Still there are additional RPL parameters that a RPL
implementation should allow to be configured, which are discussed in implementation should allow to be configured, which are discussed in
this section. this section.
17.2.1.1. DIS mode of operation upon boot-up 18.2.1.1. DIS mode of operation upon boot-up
When a node is first powered up: When a node is first powered up:
1. The node may decide to stay silent, waiting to receive DIO 1. The node may decide to stay silent, waiting to receive DIO
messages from DODAG of interest (advertising a supported OF and messages from DODAG of interest (advertising a supported OF and
metrics/constraints) and not send any multicast DIO messages metrics/constraints) and not send any multicast DIO messages
until it has joined a DODAG. until it has joined a DODAG.
2. The node may decide to send one or more DIS messages (optionally 2. The node may decide to send one or more DIS messages (optionally
requesting DIO for a specific DODAG) as an initial probe for requesting DIO for a specific DODAG) as an initial probe for
nearby DODAGs, and in the absence of DIO messages in reply after nearby DODAGs, and in the absence of DIO messages in reply after
some configurable period of time, the node may decide to root a some configurable period of time, the node may decide to root a
floating DODAG and start sending multicast DIO messages. floating DODAG and start sending multicast DIO messages.
A RPL implementation SHOULD allow configuring the preferred mode of A RPL implementation SHOULD allow configuring the preferred mode of
operation listed above along with the required parameters (in the operation listed above along with the required parameters (in the
second mode: the number of DIS messages and related timer). second mode: the number of DIS messages and related timer).
17.2.2. DIO and DAO Base Message and Options Configuration 18.2.2. DIO and DAO Base Message and Options Configuration
RPL specifies a number of protocol parameters considering the large RPL specifies a number of protocol parameters considering the large
spectrum of applications where it will be used. That said, spectrum of applications where it will be used. That said,
particular attention has been given to limiting the number of these particular attention has been given to limiting the number of these
parameters that must be configured on each RPL router. Instead, a parameters that must be configured on each RPL router. Instead, a
number of the default values can be used, and when required these number of the default values can be used, and when required these
parameters can be provided by the DODAG root thus allowing for parameters can be provided by the DODAG root thus allowing for
dynamic parameter setting. dynamic parameter setting.
A RPL implementation SHOULD allow configuring the following routing A RPL implementation SHOULD allow configuring the following routing
protocol parameters. As pointed out above, note that a large set of protocol parameters. As pointed out above, note that a large set of
parameters is configured on the DODAG root. parameters is configured on the DODAG root.
17.2.3. Protocol Parameters to be configured on every router in the LLN 18.2.3. Protocol Parameters to be configured on every router in the LLN
A RPL implementation MUST allow configuring the following RPL A RPL implementation MUST allow configuring the following RPL
parameters: parameters:
o RPLInstanceID [DIO message, in DIO base message]. Although the o RPLInstanceID [DIO message, in DIO base message]. Although the
RPLInstanceID must be configured on the DODAG root, it must also RPLInstanceID must be configured on the DODAG root, it must also
be configured as a policy on every node in order to determine be configured as a policy on every node in order to determine
whether or not the node should join a particular DODAG. Note that whether or not the node should join a particular DODAG. Note that
a second RPLInstance can be configured on the node, should it a second RPLInstance can be configured on the node, should it
become root of a floating DODAG. become root of a floating DODAG.
skipping to change at page 116, line 14 skipping to change at page 120, line 14
along with the value of the RPLInstance ID, V/I/D flags. along with the value of the RPLInstance ID, V/I/D flags.
o 'K' flag: when a node should set the 'K' flag in a DAO message o 'K' flag: when a node should set the 'K' flag in a DAO message
[DAO message, in DAO base message]. [DAO message, in DAO base message].
o MOP (Mode of Operation) [DIO message, in DIO base message]. o MOP (Mode of Operation) [DIO message, in DIO base message].
o Route Information (and preference) [DIO message, in Route o Route Information (and preference) [DIO message, in Route
Information option] Information option]
17.2.4. Protocol Parameters to be configured on every non-DODAG-root 18.2.4. Protocol Parameters to be configured on every non-DODAG-root
router in the LLN router in the LLN
A RPL implementation MUST allow configuring the Target prefix [DAO A RPL implementation MUST allow configuring the Target prefix [DAO
message, in RPL Target option]. message, in RPL Target option].
Furthermore, there are circumstances where a node may want to Furthermore, there are circumstances where a node may want to
designate a Target to allow for specific processing of the Target designate a Target to allow for specific processing of the Target
(prioritization, ...). Such processing rules are out of scope for (prioritization, ...). Such processing rules are out of scope for
this specification. When used, a RPL implementation SHOULD allow this specification. When used, a RPL implementation SHOULD allow
configuring the Target Descriptor on a per-Target basis (for example configuring the Target Descriptor on a per-Target basis (for example
skipping to change at page 116, line 39 skipping to change at page 120, line 39
less preferred. Thus a RPL implementation MUST allow configuring the less preferred. Thus a RPL implementation MUST allow configuring the
set of actions that the node should initiate in this case: set of actions that the node should initiate in this case:
o Start its own (floating) DODAG: the new DODAGID must be configured o Start its own (floating) DODAG: the new DODAGID must be configured
in addition to its DAGPreference. in addition to its DAGPreference.
o Poison the broken path (see procedure in Section 8.2.2.5). o Poison the broken path (see procedure in Section 8.2.2.5).
o Trigger a local repair. o Trigger a local repair.
17.2.5. Parameters to be configured on the DODAG root 18.2.5. Parameters to be configured on the DODAG root
In addition, several other parameters are configured only on the In addition, several other parameters are configured only on the
DODAG root and advertised in options carried in DIO messages. DODAG root and advertised in options carried in DIO messages.
As specified in Section 8.3, a RPL implementation makes use of As specified in Section 8.3, a RPL implementation makes use of
trickle timers to govern the sending of DIO messages. The operation trickle timers to govern the sending of DIO messages. The operation
of the trickle algorithm is determined by a set of configurable of the trickle algorithm is determined by a set of configurable
parameters, which MUST be configurable and that are then advertised parameters, which MUST be configurable and that are then advertised
by the DODAG root along the DODAG in DIO messages. by the DODAG root along the DODAG in DIO messages.
skipping to change at page 117, line 37 skipping to change at page 121, line 37
support the ability to configure whether or not a node could act as a support the ability to configure whether or not a node could act as a
floating DODAG root for a configured period of time. floating DODAG root for a configured period of time.
DAG Version Number Increment: a RPL implementation may allow by DAG Version Number Increment: a RPL implementation may allow by
configuration at the DODAG root to refresh the DODAG states by configuration at the DODAG root to refresh the DODAG states by
updating the DODAGVersionNumber. A RPL implementation SHOULD allow updating the DODAGVersionNumber. A RPL implementation SHOULD allow
configuring whether or not periodic or event triggered mechanisms are configuring whether or not periodic or event triggered mechanisms are
used by the DODAG root to control DODAGVersionNumber change (which used by the DODAG root to control DODAGVersionNumber change (which
triggers a global repair as specified in Section 3.2.2. triggers a global repair as specified in Section 3.2.2.
17.2.6. Configuration of RPL Parameters related to DAO-based mechanisms 18.2.6. Configuration of RPL Parameters related to DAO-based mechanisms
DAO messages are optional and used in DODAGs that require downward DAO messages are optional and used in DODAGs that require downward
routing operation. This section deals with the set of parameters routing operation. This section deals with the set of parameters
related to DAO messages and provides recommendations on their related to DAO messages and provides recommendations on their
configuration. configuration.
As stated in Section 9.5, it is recommended to delay the sending of As stated in Section 9.5, it is recommended to delay the sending of
DAO message to DAO parents in order to maximize the chances to DAO message to DAO parents in order to maximize the chances to
perform route aggregation. Upon receiving a DAO message, the node perform route aggregation. Upon receiving a DAO message, the node
should thus start a DelayDAO timer. The default value is should thus start a DelayDAO timer. The default value is
skipping to change at page 118, line 15 skipping to change at page 122, line 15
A RPL implementation MAY allow for configuring a set of rules A RPL implementation MAY allow for configuring a set of rules
specifying the triggers for DTSN increment (manual or event-based). specifying the triggers for DTSN increment (manual or event-based).
When a DAO entry times out or is invalidated, a node SHOULD make a When a DAO entry times out or is invalidated, a node SHOULD make a
reasonable attempt to report a No-Path to each of the DAO parents. reasonable attempt to report a No-Path to each of the DAO parents.
That number of attempts MAY be configurable. That number of attempts MAY be configurable.
An implementation should support rate-limiting the sending of DAO An implementation should support rate-limiting the sending of DAO
messages. The related parameters MAY be configurable. messages. The related parameters MAY be configurable.
17.2.7. Configuration of RPL Parameters related to Security mechanisms 18.2.7. Configuration of RPL Parameters related to Security mechanisms
As described in Section 10, the security features described in this As described in Section 10, the security features described in this
document are optional to implement and a given implementation may document are optional to implement and a given implementation may
support a subset (including the empty set) of the described security support a subset (including the empty set) of the described security
features. features.
To this end an implementation supporting described security features To this end an implementation supporting described security features
may conceptually implement a security policy database. In support of may conceptually implement a security policy database. In support of
the security mechanisms, a RPL implementation SHOULD allow for the security mechanisms, a RPL implementation SHOULD allow for
configuring a subset of the following parameters: configuring a subset of the following parameters:
skipping to change at page 119, line 5 skipping to change at page 123, line 5
In addition, a RPL implementation SHOULD allow for configuring a In addition, a RPL implementation SHOULD allow for configuring a
DODAG root with a subset of the following parameters: DODAG root with a subset of the following parameters:
o Level values advertised [Secure DIO message, in Security Section] o Level values advertised [Secure DIO message, in Security Section]
o KIM value advertised [Secure DIO message, in Security Section] o KIM value advertised [Secure DIO message, in Security Section]
o Algorithm value advertised [Secure DIO message, in Security o Algorithm value advertised [Secure DIO message, in Security
Section] Section]
17.2.8. Default Values 18.2.8. Default Values
This document specifies default values for the following set of RPL This document specifies default values for the following set of RPL
variables: variables:
DEFAULT_PATH_CONTROL_SIZE DEFAULT_PATH_CONTROL_SIZE
DEFAULT_DIO_INTERVAL_MIN DEFAULT_DIO_INTERVAL_MIN
DEFAULT_DIO_INTERVAL_DOUBLINGS DEFAULT_DIO_INTERVAL_DOUBLINGS
DEFAULT_DIO_REDUNDANCY_CONSTANT DEFAULT_DIO_REDUNDANCY_CONSTANT
DEFAULT_MIN_HOP_RANK_INCREASE DEFAULT_MIN_HOP_RANK_INCREASE
DEFAULT_DAO_DELAY DEFAULT_DAO_DELAY
skipping to change at page 119, line 30 skipping to change at page 123, line 30
of nodes, link and nodes types are expected to vary significantly. of nodes, link and nodes types are expected to vary significantly.
Thus, these default values are likely to change with the context and Thus, these default values are likely to change with the context and
as the technology will evolve. Indeed, LLNs' related technology as the technology will evolve. Indeed, LLNs' related technology
(e.g. hardware, link layers) have been evolving dramatically over the (e.g. hardware, link layers) have been evolving dramatically over the
past few years and such technologies are expected to change and past few years and such technologies are expected to change and
evolve considerably in the coming years. evolve considerably in the coming years.
The proposed values are not based on extensive best current practices The proposed values are not based on extensive best current practices
and are considered to be conservative. and are considered to be conservative.
17.3. Monitoring of RPL Operation 18.3. Monitoring of RPL Operation
Several RPL parameters should be monitored to verify the correct Several RPL parameters should be monitored to verify the correct
operation of the routing protocol and the network itself. This operation of the routing protocol and the network itself. This
section lists the set of monitoring parameters of interest. section lists the set of monitoring parameters of interest.
17.3.1. Monitoring a DODAG parameters 18.3.1. Monitoring a DODAG parameters
A RPL implementation SHOULD provide information about the following A RPL implementation SHOULD provide information about the following
parameters: parameters:
o DODAG Version number [DIO message, in DIO base message] o DODAG Version number [DIO message, in DIO base message]
o Status of the G flag [DIO message, in DIO base message] o Status of the G flag [DIO message, in DIO base message]
o Status of the MOP field [DIO message, in DIO base message] o Status of the MOP field [DIO message, in DIO base message]
skipping to change at page 120, line 31 skipping to change at page 124, line 31
Values that may be monitored only on the DODAG root Values that may be monitored only on the DODAG root
o Transit Information [DAO, Transit Information option]: A RPL o Transit Information [DAO, Transit Information option]: A RPL
implementation SHOULD allow configuring whether the set of implementation SHOULD allow configuring whether the set of
received Transit Information options should be displayed on the received Transit Information options should be displayed on the
DODAG root. In this case, the RPL database of received Transit DODAG root. In this case, the RPL database of received Transit
Information should also contain: the path-sequence, path control, Information should also contain: the path-sequence, path control,
path lifetime and parent address. path lifetime and parent address.
17.3.2. Monitoring a DODAG inconsistencies and loop detection 18.3.2. Monitoring a DODAG inconsistencies and loop detection
Detection of DODAG inconsistencies is particularly critical in RPL Detection of DODAG inconsistencies is particularly critical in RPL
networks. Thus it is recommended for a RPL implementation to provide networks. Thus it is recommended for a RPL implementation to provide
appropriate monitoring tools. A RPL implementation SHOULD provide a appropriate monitoring tools. A RPL implementation SHOULD provide a
counter reporting the number of a times the node has detected an counter reporting the number of a times the node has detected an
inconsistency with respect to a DODAG parent, e.g. if the DODAGID has inconsistency with respect to a DODAG parent, e.g. if the DODAGID has
changed. changed.
When possible more granular information about inconsistency detection When possible more granular information about inconsistency detection
should be provided. A RPL implementation MAY provide counters should be provided. A RPL implementation MAY provide counters
skipping to change at page 121, line 6 skipping to change at page 125, line 6
o Packets received with 'O' bit set (to Down) from a node with a o Packets received with 'O' bit set (to Down) from a node with a
higher rank higher rank
o Packets received with 'O' bit cleared (to Up) from a node with a o Packets received with 'O' bit cleared (to Up) from a node with a
lower rank lower rank
o Number of packets with the 'F' bit set o Number of packets with the 'F' bit set
o Number of packets with the 'R' bit set o Number of packets with the 'R' bit set
17.4. Monitoring of the RPL data structures 18.4. Monitoring of the RPL data structures
17.4.1. Candidate Neighbor Data Structure 18.4.1. Candidate Neighbor Data Structure
A node in the candidate neighbor list is a node discovered by the A node in the candidate neighbor list is a node discovered by the
some means and qualified to potentially become a parent (with high some means and qualified to potentially become a parent (with high
enough local confidence). A RPL implementation SHOULD provide a way enough local confidence). A RPL implementation SHOULD provide a way
to allow for the candidate neighbor list to be monitored with some to allow for the candidate neighbor list to be monitored with some
metric reflecting local confidence (the degree of stability of the metric reflecting local confidence (the degree of stability of the
neighbors) as measured by some metrics. neighbors) as measured by some metrics.
A RPL implementation MAY provide a counter reporting the number of A RPL implementation MAY provide a counter reporting the number of
times a candidate neighbor has been ignored, should the number of times a candidate neighbor has been ignored, should the number of
candidate neighbors exceeds the maximum authorized value. candidate neighbors exceeds the maximum authorized value.
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table 18.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table
For each DODAG, a RPL implementation is expected to keep track of the For each DODAG, a RPL implementation is expected to keep track of the
following DODAG table values: following DODAG table values:
o RPLInstanceID o RPLInstanceID
o DODAGID o DODAGID
o DODAGVersionNumber o DODAGVersionNumber
skipping to change at page 122, line 5 skipping to change at page 126, line 5
o List of DAO parents o List of DAO parents
o DTSN o DTSN
o Node status (router versus leaf) o Node status (router versus leaf)
A RPL implementation SHOULD allow for monitoring the set of A RPL implementation SHOULD allow for monitoring the set of
parameters listed above. parameters listed above.
17.4.3. Routing Table and DAO Routing Entries 18.4.3. Routing Table and DAO Routing Entries
A RPL implementation maintains several information elements related A RPL implementation maintains several information elements related
to the DODAG and the DAO entries (for storing nodes). In the case of to the DODAG and the DAO entries (for storing nodes). In the case of
a non storing node, a limited amount of information is maintained a non storing node, a limited amount of information is maintained
(the routing table is mostly reduced to a set of DODAG parents along (the routing table is mostly reduced to a set of DODAG parents along
with characteristics of the DODAG as mentioned above) whereas in the with characteristics of the DODAG as mentioned above) whereas in the
case of storing nodes, this information is augmented with routing case of storing nodes, this information is augmented with routing
entries. entries.
A RPL implementation SHOULD allow for the following parameters to be A RPL implementation SHOULD allow for the following parameters to be
skipping to change at page 123, line 5 skipping to change at page 127, line 5
* DAO Lifetime * DAO Lifetime
* DAO Path Control * DAO Path Control
o Destination Prefix (or Address or Mcast Group) o Destination Prefix (or Address or Mcast Group)
A RPL implementation SHOULD provide information about the state of A RPL implementation SHOULD provide information about the state of
each DAO Routing Table entry states. each DAO Routing Table entry states.
17.5. Fault Management 18.5. Fault Management
Fault management is a critical component used for troubleshooting, Fault management is a critical component used for troubleshooting,
verification of the correct mode of operation of the protocol, verification of the correct mode of operation of the protocol,
network design, and is also a key component of network performance network design, and is also a key component of network performance
monitoring. A RPL implementation SHOULD allow providing the monitoring. A RPL implementation SHOULD allow providing the
following information related to fault managements: following information related to fault managements:
o Memory overflow along with the cause (e.g. routing tables o Memory overflow along with the cause (e.g. routing tables
overflow, ...) overflow, ...)
skipping to change at page 123, line 35 skipping to change at page 127, line 35
o Number of received malformed messages o Number of received malformed messages
o Number of seconds with packets to forward and no next hop (DODAG o Number of seconds with packets to forward and no next hop (DODAG
parent) parent)
o Number of seconds without next hop (DODAG parent) o Number of seconds without next hop (DODAG parent)
o Number of times a node has joined a DODAG as a leaf because it o Number of times a node has joined a DODAG as a leaf because it
received a DIO with metric/constraint not understood and it was received a DIO with metric/constraint not understood and it was
configured to join as a leaf node in this case (see Section 17.6). configured to join as a leaf node in this case (see Section 18.6).
It is RECOMMENDED to report faults via at least error log messages. It is RECOMMENDED to report faults via at least error log messages.
Other protocols may be used to report such faults. Other protocols may be used to report such faults.
17.6. Policy 18.6. Policy
Policy rules can be used by a RPL implementation to determine whether Policy rules can be used by a RPL implementation to determine whether
or not the node is allowed to join a particular DODAG advertised by a or not the node is allowed to join a particular DODAG advertised by a
neighbor by means of DIO messages. neighbor by means of DIO messages.
This document specifies operation within a single DODAG. A DODAG is This document specifies operation within a single DODAG. A DODAG is
characterized by the following tuple (RPLInstanceID, DODAGID). characterized by the following tuple (RPLInstanceID, DODAGID).
Furthermore, as pointed out above, DIO messages are used to advertise Furthermore, as pointed out above, DIO messages are used to advertise
other DODAG characteristics such as the routing metrics and other DODAG characteristics such as the routing metrics and
constraints used to build to the DODAG and the Objective Function in constraints used to build to the DODAG and the Objective Function in
skipping to change at page 124, line 49 skipping to change at page 128, line 49
preference for the routing protocol from which the route was learned. preference for the routing protocol from which the route was learned.
Internal Data Structures: some RPL implementations may limit the size Internal Data Structures: some RPL implementations may limit the size
of the candidate neighbor list in order to bound the memory usage, in of the candidate neighbor list in order to bound the memory usage, in
which case some otherwise viable candidate neighbors may not be which case some otherwise viable candidate neighbors may not be
considered and simply dropped from the candidate neighbor list. considered and simply dropped from the candidate neighbor list.
A RPL implementation MAY provide an indicator on the size of the A RPL implementation MAY provide an indicator on the size of the
candidate neighbor list. candidate neighbor list.
17.7. Fault Isolation 18.7. Fault Isolation
It is RECOMMENDED to quarantine neighbors that start emitting It is RECOMMENDED to quarantine neighbors that start emitting
malformed messages at unacceptable rates. malformed messages at unacceptable rates.
17.8. Impact on Other Protocols 18.8. Impact on Other Protocols
RPL has very limited impact on other protocols. Where more than one 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 routing protocol is required on a router such as a LBR, it is
expected for the device to support routing redistribution functions expected for the device to support routing redistribution functions
between the routing protocols to allow for reachability between the between the routing protocols to allow for reachability between the
two routing domains. Such redistribution SHOULD be governed by the two routing domains. Such redistribution SHOULD be governed by the
use of user configurable policy. use of user configurable policy.
With regards to the impact in terms of traffic on the network, RPL With regards to the impact in terms of traffic on the network, RPL
has been designed to limit the control traffic thanks to mechanisms has been designed to limit the control traffic thanks to mechanisms
such as Trickle timers (Section 8.3). Thus the impact of RPL on such as Trickle timers (Section 8.3). Thus the impact of RPL on
other protocols should be extremely limited. other protocols should be extremely limited.
17.9. Performance Management 18.9. Performance Management
Performance management is always an important aspect of a protocol Performance management is always an important aspect of a protocol
and RPL is not an exception. Several metrics of interest have been and RPL is not an exception. Several metrics of interest have been
specified by the IP Performance Monitoring (IPPM) Working Group: that specified by the IP Performance Monitoring (IPPM) Working Group: that
being said, they will be hardly applicable to LLN considering the being said, they will be hardly applicable to LLN considering the
cost of monitoring these metrics in terms of resources on the devices cost of monitoring these metrics in terms of resources on the devices
and required bandwidth. Still, RPL implementation MAY support some and required bandwidth. Still, RPL implementation MAY support some
of these, and other parameters of interest are listed below: of these, and other parameters of interest are listed below:
o Number of repairs and time to repair in seconds (average, o Number of repairs and time to repair in seconds (average,
skipping to change at page 125, line 41 skipping to change at page 129, line 41
o Number of times and duration during which a devices could not o Number of times and duration during which a devices could not
forward a packet because of a lack of reachable neighbor in its forward a packet because of a lack of reachable neighbor in its
routing table routing table
o Monitoring of resources consumption by RPL in terms of bandwidth o Monitoring of resources consumption by RPL in terms of bandwidth
and required memory and required memory
o Number of RPL control messages sent and received o Number of RPL control messages sent and received
17.10. Diagnostics 18.10. Diagnostics
There may be situations where a node should be placed in "verbose" There may be situations where a node should be placed in "verbose"
mode to improve diagnostics. Thus a RPL implementation SHOULD mode to improve diagnostics. Thus a RPL implementation SHOULD
provide the ability to place a node in and out of verbose mode in provide the ability to place a node in and out of verbose mode in
order to get additional diagnostic information. order to get additional diagnostic information.
18. Security Considerations 19. Security Considerations
18.1. Overview 19.1. Overview
From a security perspective, RPL networks are no different from any From a security perspective, RPL networks are no different from any
other network. They are vulnerable to passive eavesdropping attacks other network. They are vulnerable to passive eavesdropping attacks
and potentially even active tampering when physical access to a wire and potentially even active tampering when physical access to a wire
is not required to participate in communications. The very nature of is not required to participate in communications. The very nature of
ad hoc networks and their cost objectives impose additional security ad hoc networks and their cost objectives impose additional security
constraints, which perhaps make these networks the most difficult constraints, which perhaps make these networks the most difficult
environments to secure. Devices are low-cost and have limited environments to secure. Devices are low-cost and have limited
capabilities in terms of computing power, available storage, and capabilities in terms of computing power, available storage, and
power drain; and it cannot always be assumed they have a trusted power drain; and it cannot always be assumed they have a trusted
skipping to change at page 128, line 5 skipping to change at page 132, line 5
public-key based techniques. With public-key based techniques (via public-key based techniques. With public-key based techniques (via
signatures), one corroborates evidence as to the unique originator of signatures), one corroborates evidence as to the unique originator of
transmitted information, whereas with symmetric-key based techniques transmitted information, whereas with symmetric-key based techniques
data authenticity is only provided relative to devices in a key- data authenticity is only provided relative to devices in a key-
sharing group. Thus, public-key based authentication may be useful sharing group. Thus, public-key based authentication may be useful
in scenarios that require a more fine-grained authentication than can in scenarios that require a more fine-grained authentication than can
be provided with symmetric-key based authentication techniques alone, be provided with symmetric-key based authentication techniques alone,
such as with group communications (broadcast, multicast), or in such as with group communications (broadcast, multicast), or in
scenarios that require non-repudiation. scenarios that require non-repudiation.
19. IANA Considerations 20. IANA Considerations
19.1. RPL Control Message 20.1. RPL Control Message
The RPL Control Message is an ICMP information message type that is The RPL Control Message is an ICMP information message type that is
to be used carry DODAG Information Objects, DODAG Information to be used carry DODAG Information Objects, DODAG Information
Solicitations, and Destination Advertisement Objects in support of Solicitations, and Destination Advertisement Objects in support of
RPL operation. RPL operation.
IANA has defined an ICMPv6 Type Number Registry. The suggested type IANA has defined an ICMPv6 Type Number Registry. The suggested type
value for the RPL Control Message is 155, to be confirmed by IANA. value for the RPL Control Message is 155, to be confirmed by IANA.
19.2. New Registry for RPL Control Codes 20.2. New Registry for RPL Control Codes
IANA is requested to create a registry, RPL Control Codes, for the IANA is requested to create a registry, RPL Control Codes, for the
Code field of the ICMPv6 RPL Control Message. Code field of the ICMPv6 RPL Control Message.
New codes may be allocated only by an IETF Review. Each code should New codes may be allocated only by an IETF Review. Each code should
be tracked with the following qualities: be tracked with the following qualities:
o Code o Code
o Description o Description
skipping to change at page 129, line 16 skipping to change at page 133, line 16
| | | | | | | |
| 0x83 | Secure Destination Advertisement Object | This | | 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document | | | Acknowledgment | document |
| | | | | | | |
| 0x8A | Consistency Check | This | | 0x8A | Consistency Check | This |
| | | document | | | | document |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
RPL Control Codes RPL Control Codes
19.3. New Registry for the Mode of Operation (MOP) 20.3. New Registry for the Mode of Operation (MOP)
IANA is requested to create a registry for the 3-bit Mode of IANA is requested to create a registry for the 3-bit Mode of
Operation (MOP), 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 New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities: should be tracked with the following qualities:
o Mode of Operation Value o Mode of Operation Value
o Capability description o Capability description
skipping to change at page 130, line 5 skipping to change at page 134, line 5
| | multicast support | document | | | multicast support | document |
| | | | | | | |
| 3 | Storing mode of operation with multicast | This | | 3 | Storing mode of operation with multicast | This |
| | support | document | | | support | document |
+----------+------------------------------------------+-------------+ +----------+------------------------------------------+-------------+
DIO Mode of operation DIO Mode of operation
The rest of the range, decimal 4 to 7, is currently unassigned. The rest of the range, decimal 4 to 7, is currently unassigned.
19.4. RPL Control Message Option 20.4. RPL Control Message Option
IANA is requested to create a registry for the RPL Control Message IANA is requested to create a registry for the RPL Control Message
Options Options
New values may be allocated only by an IETF Review. Each value New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities: should be tracked with the following qualities:
o Value o Value
o Meaning o Meaning
skipping to change at page 130, line 45 skipping to change at page 134, line 45
| | | | | | | |
| 7 | Solicited Information | This Document | | 7 | Solicited Information | This Document |
| | | | | | | |
| 8 | Prefix Information | This Document | | 8 | Prefix Information | This Document |
| | | | | | | |
| 9 | Target Descriptor | This Document | | 9 | Target Descriptor | This Document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
RPL Control Message Options RPL Control Message Options
19.5. Objective Code Point (OCP) Registry 20.5. Objective Code Point (OCP) Registry
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a registry to manage the codespace of the
Objective Code Point (OCP) field. Objective Code Point (OCP) field.
No OCP codepoints are defined in this specification. No OCP codepoints are defined in this specification.
New codes may be allocated only by an IETF Review. Each code should New codes may be allocated only by an IETF Review. Each code should
be tracked with the following qualities: be tracked with the following qualities:
o OCP code o OCP code
o Description o Description
o Defining RFC o Defining RFC
19.6. New Registry for the Security Section Algorithm 20.6. New Registry for the Security Section Algorithm
IANA is requested to create a registry for the values of 8-bit IANA is requested to create a registry for the values of 8-bit
Algorithm field in the Security Section. Algorithm field in the Security Section.
New values may be allocated only by an IETF Review. Each value New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities: should be tracked with the following qualities:
o Value o Value
o Encryption/MAC o Encryption/MAC
skipping to change at page 131, line 38 skipping to change at page 135, line 38
The following value is currently defined: The following value is currently defined:
+-------+------------------+------------------+---------------+ +-------+------------------+------------------+---------------+
| Value | Encryption/MAC | Signature | Reference | | Value | Encryption/MAC | Signature | Reference |
+-------+------------------+------------------+---------------+ +-------+------------------+------------------+---------------+
| 0 | CCM with AES-128 | RSA with SHA-256 | This document | | 0 | CCM with AES-128 | RSA with SHA-256 | This document |
+-------+------------------+------------------+---------------+ +-------+------------------+------------------+---------------+
Security Section Algorithm Security Section Algorithm
19.7. New Registry for the Security Section Flags 20.7. New Registry for the Security Section Flags
IANA is requested to create a registry for the 8-bit Security Section IANA is requested to create a registry for the 8-bit Security Section
Flag Field. Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the Security Section Flags. No bit is currently defined for the Security Section Flags.
19.8. New Registry for Per-KIM Security Levels 20.8. New Registry for Per-KIM Security Levels
IANA is requested to create one registry for the 3-bit Security Level IANA is requested to create one registry for the 3-bit Security Level
(LVL) Field per allocated KIM value. (LVL) Field per allocated KIM value.
For a given KIM value, new levels may be allocated only by an IETF For a given KIM value, new levels may be allocated only by an IETF
Review. Each level should be tracked with the following qualities: Review. Each level should be tracked with the following qualities:
o Level o Level
o KIM value o KIM value
skipping to change at page 133, line 43 skipping to change at page 137, line 43
| | | | | | | | | |
| 1 | 3 | See Figure 11 | This document | | 1 | 3 | See Figure 11 | This document |
| | | | | | | | | |
| 2 | 3 | See Figure 11 | This document | | 2 | 3 | See Figure 11 | This document |
| | | | | | | | | |
| 3 | 3 | See Figure 11 | This document | | 3 | 3 | See Figure 11 | This document |
+-------+-----------+---------------+---------------+ +-------+-----------+---------------+---------------+
Per-KIM Security Levels Per-KIM Security Levels
19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags 20.9. New Registry for the DIS (DODAG Informational Solicitation) Flags
IANA is requested to create a registry for the DIS (DODAG IANA is requested to create a registry for the DIS (DODAG
Informational Solicitation) Flag Field. Informational Solicitation) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the DIS (DODAG Informational No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags. Solicitation) Flags.
19.10. New Registry for the DODAG Information Object (DIO) Flags 20.10. New Registry for the DODAG Information Object (DIO) Flags
IANA is requested to create a registry for the 8-bit DODAG IANA is requested to create a registry for the 8-bit DODAG
Information Object (DIO) Flag Field. Information Object (DIO) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the DIS (DODAG Informational No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags. Solicitation) Flags.
19.11. New Registry for the Destination Advertisement Object (DAO) 20.11. New Registry for the Destination Advertisement Object (DAO)
Flags Flags
IANA is requested to create a registry for the 8-bit Destination IANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Flag Field. Advertisement Object (DAO) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
skipping to change at page 135, line 15 skipping to change at page 139, line 15
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DAO-ACK request (K) | This document | | 0 | DAO-ACK request (K) | This document |
| | | | | | | |
| 1 | DODAGID field is present (D) | This document | | 1 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
DAO Base Flags DAO Base Flags
19.12. New Registry for the Destination Advertisement Object (DAO) 20.12. New Registry for the Destination Advertisement Object (DAO)
Acknowledgement Flags Acknowledgement Flags
IANA is requested to create a registry for the 8-bit Destination IANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Acknowledgement Flag Field. Advertisement Object (DAO) Acknowledgement Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
skipping to change at page 135, line 40 skipping to change at page 139, line 40
The following bit is currently defined: The following bit is currently defined:
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DODAGID field is present (D) | This document | | 0 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
DAO-ACK Base Flags DAO-ACK Base Flags
19.13. New Registry for the Consistency Check (CC) Flags 20.13. New Registry for the Consistency Check (CC) Flags
IANA is requested to create a registry for the 8-bit Consistency IANA is requested to create a registry for the 8-bit Consistency
Check (CC) Flag Field. Check (CC) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
skipping to change at page 136, line 16 skipping to change at page 140, line 16
The following bit is currently defined: The following bit is currently defined:
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| 0 | CC Response (R) | This document | | 0 | CC Response (R) | This document |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
Consistency Check Base Flags Consistency Check Base Flags
19.14. New Registry for the DODAG Configuration Option Flags 20.14. New Registry for the DODAG Configuration Option Flags
IANA is requested to create a registry for the 8-bit DODAG IANA is requested to create a registry for the 8-bit DODAG
Configuration Option Flag Field. Configuration Option Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
skipping to change at page 136, line 42 skipping to change at page 140, line 42
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
| 4 | Authentication Enabled (A) | This document | | 4 | Authentication Enabled (A) | This document |
| | | | | | | |
| 5-7 | Path Control Size (PCS) | This document | | 5-7 | Path Control Size (PCS) | This document |
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
DODAG Configuration Option Flags DODAG Configuration Option Flags
19.15. New Registry for the RPL Target Option Flags 20.15. New Registry for the RPL Target Option Flags
IANA is requested to create a registry for the 8-bit RPL Target IANA is requested to create a registry for the 8-bit RPL Target
Option Flag Field. Option Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the RPL Target Option Flags. No bit is currently defined for the RPL Target Option Flags.
19.16. New Registry for the Transit Information Option Flags 20.16. New Registry for the Transit Information Option Flags
IANA is requested to create a registry for the 8-bit Transit IANA is requested to create a registry for the 8-bit Transit
Information Option (RIO) Flag Field. Information Option (RIO) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
skipping to change at page 137, line 37 skipping to change at page 141, line 37
The following bits are currently defined: The following bits are currently defined:
+------------+--------------+---------------+ +------------+--------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+--------------+---------------+ +------------+--------------+---------------+
| 0 | External (E) | This document | | 0 | External (E) | This document |
+------------+--------------+---------------+ +------------+--------------+---------------+
Transit Information Option Flags Transit Information Option Flags
19.17. New Registry for the Solicited Information Option Flags 20.17. New Registry for the Solicited Information Option Flags
IANA is requested to create a registry for the 8-bit Solicited IANA is requested to create a registry for the 8-bit Solicited
Information Option (RIO) Flag Field. Information Option (RIO) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
skipping to change at page 138, line 17 skipping to change at page 142, line 17
+------------+--------------------------------+---------------+ +------------+--------------------------------+---------------+
| 0 | Version Predicate match (V) | This document | | 0 | Version Predicate match (V) | This document |
| | | | | | | |
| 1 | InstanceID Predicate match (I) | This document | | 1 | InstanceID Predicate match (I) | This document |
| | | | | | | |
| 2 | DODAGID Predicate match (D) | This document | | 2 | DODAGID Predicate match (D) | This document |
+------------+--------------------------------+---------------+ +------------+--------------------------------+---------------+
Solicited Information Option Flags Solicited Information Option Flags
19.18. ICMPv6: Error in Source Routing Header 20.18. ICMPv6: Error in Source Routing Header
In some cases RPL will return an ICMPv6 error message when a message In some cases RPL will return an ICMPv6 error message when a message
cannot be delivered as specified by its source routing header. This cannot be delivered as specified by its source routing header. This
ICMPv6 error message is "Error in Source Routing Header". ICMPv6 error message is "Error in Source Routing Header".
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
Types. ICMPv6 Message Type 1 describes "Destination Unreachable" Types. ICMPv6 Message Type 1 describes "Destination Unreachable"
codes. The "Error in Source Routing Header" code is suggested to be codes. The "Error in Source Routing Header" code is suggested to be
allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message
Type 1, with a suggested code value of 7, to be confirmed by IANA. Type 1, with a suggested code value of 7, to be confirmed by IANA.
19.19. Link-Local Scope multicast address 20.19. Link-Local Scope multicast address
The rules for assigning new IPv6 multicast addresses are defined in The rules for assigning new IPv6 multicast addresses are defined in
[RFC3307]. This specification requires the allocation of a new [RFC3307]. This specification requires the allocation of a new
permanent multicast address with a link local scope for RPL nodes permanent multicast address with a link local scope for RPL nodes
called all-RPL-nodes, with a suggested value of FF02::1A, to be called all-RPL-nodes, with a suggested value of FF02::1A, to be
confirmed by IANA. confirmed by IANA.
20. Acknowledgements 21. Acknowledgements
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel, comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel,
Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa
Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar
Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko,
Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru
Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep
Tripathi, and Nicolas Tsiftes. Tripathi, and Nicolas Tsiftes.
skipping to change at page 139, line 27 skipping to change at page 143, line 27
by the ROLL Chairs, David Culler and JP Vasseur, and the Area by the ROLL Chairs, David Culler and JP Vasseur, and the Area
Director Adrian Farrel. Director Adrian Farrel.
The authors would like to acknowledge prior contributions of Robert The authors would like to acknowledge prior contributions of Robert
Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon,
Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom
have provided useful design considerations to RPL. have provided useful design considerations to RPL.
RPL Security Design, found in Section 10, Section 18, and elsewhere RPL Security Design, found in Section 10, Section 19, and elsewhere
throughout the document, is primarily the contribution of the throughout the document, is primarily the contribution of the
Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
Levis, Kris Pister, Rene Struik, and Adrian Farrel. Levis, Kris Pister, Rene Struik, and Adrian Farrel.
21. Contributors Thanks also to Jari Arkko and Ralph Droms for their attentive
reviews, especially with respect to interoperability considerations
and integration with other IETF specifications.
22. Contributors
Stephen Dawson-Haggerty Stephen Dawson-Haggerty
UC Berkeley UC Berkeley
Soda Hall, UC Berkeley Soda Hall, UC Berkeley
Berkeley, CA 94720 Berkeley, CA 94720
USA USA
Email: stevedh@cs.berkeley.edu Email: stevedh@cs.berkeley.edu
22. References 23. References
22.1. Normative References 23.1. Normative References
[I-D.ietf-6man-rpl-option] [I-D.ietf-6man-rpl-option]
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
Information in Data-Plane Datagrams", Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-01 (work in progress), draft-ietf-6man-rpl-option-02 (work in progress),
October 2010. February 2011.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-01 (work in progress), draft-ietf-6man-rpl-routing-header-02 (work in progress),
October 2010. March 2011.
[I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-07 (work in progress), March 2011.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-17 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
January 2011. March 2011.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", draft-ietf-roll-trickle-08 (work "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work
in progress), January 2011. in progress), January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
skipping to change at page 142, line 14 skipping to change at page 146, line 19
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
22.2. Informative References 23.2. Informative References
[FIPS180] National Institute of Standards and Technology, "FIPS Pub [FIPS180] National Institute of Standards and Technology, "FIPS Pub
180-3, Secure Hash Standard (SHS)", US Department of 180-3, Secure Hash Standard (SHS)", US Department of
Commerce , February 2008, Commerce , February 2008,
<http://www.nist.gov/itl/upload/fips180-3_final.pdf>. <http://www.nist.gov/itl/upload/fips180-3_final.pdf>.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low-power and Lossy Networks",
draft-ietf-6lowpan-nd-15 (work in progress),
December 2010.
[I-D.ietf-manet-nhdp] [I-D.ietf-manet-nhdp]
Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-15 (work in progress), draft-ietf-manet-nhdp-15 (work in progress),
December 2010. December 2010.
[I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-05 (work in progress), January 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010. progress), September 2010.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks 7: 395-405, Information", North-Holland Computer Networks 7: 395-405,
1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/ 1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/
readings/p83.pdf>. readings/p83.pdf>.
skipping to change at page 154, line 33 skipping to change at page 158, line 33
.--------------+--------------. .--------------+--------------.
/ \ / \
/ \ / \
+------+------+ +------+------+ +------+------+ +------+------+
| | | | | | | |
| Node C | | Node D | | Node C | | Node D |
| A::C | | A::D | | A::C | | A::D |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 35: XXX Figure 35: Non-Storing Mode With Subnet-wide Prefix
A.4.1. DIO messages and PIO A.4.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows: Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Clear 'L' flag: Clear
'R' flag: Set 'R' flag: Set
Prefix Length: 64 Prefix Length: 64
Prefix: A::A Prefix: A::A
 End of changes. 88 change blocks. 
248 lines changed or deleted 404 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/