draft-ietf-roll-rpl-14.txt   draft-ietf-roll-rpl-15.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: April 28, 2011 Cisco Systems Expires: May 10, 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
October 25, 2010 November 6, 2010
RPL: IPv6 Routing Protocol for Low power and Lossy Networks RPL: IPv6 Routing Protocol for Low power and Lossy Networks
draft-ietf-roll-rpl-14 draft-ietf-roll-rpl-15
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 April 28, 2011. This Internet-Draft will expire on May 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Design Principles . . . . . . . . . . . . . . . . . . . 7 1.1. Design Principles . . . . . . . . . . . . . . . . . . . 7
1.2. Expectations of Link Layer Type . . . . . . . . . . . . 8 1.2. Expectations of Link Layer Type . . . . . . . . . . . . 9
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. RPL Identifiers . . . . . . . . . . . . . . . . . . . 12 3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 13
3.2. Instances, DODAGs, and DODAG Versions . . . . . . . . . 12 3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 13
3.3. Upward Routes and DODAG Construction . . . . . . . . . . 14 3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 14
3.3.1. Objective Function (OF) . . . . . . . . . . . . . . . 15 3.2. Upward Routes and DODAG Construction . . . . . . . . . . 16
3.3.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 15 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 16
3.3.3. Security . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 16
3.3.4. Grounded and Floating DODAGs . . . . . . . . . . . . 16 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 17
3.3.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 16 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 17
3.3.6. Administrative Preference . . . . . . . . . . . . . . 16 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 17
3.3.7. Datapath Validation and Loop Detection . . . . . . . 16 3.2.6. Administrative Preference . . . . . . . . . . . . . . 18
3.3.8. Distributed Algorithm Operation . . . . . . . . . . . 17 3.2.7. Datapath Validation and Loop Detection . . . . . . . 18
3.4. Downward Routes and Destination Advertisement . . . . . 17 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 18
3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 18 3.3. Downward Routes and Destination Advertisement . . . . . 19
3.6. Rank Properties . . . . . . . . . . . . . . . . . . . . 18 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 19
3.6.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 19 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 19
3.6.2. Rank Relationships . . . . . . . . . . . . . . . . . 20 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 20
3.7. Routing Metrics and Constraints Used By RPL . . . . . . 20 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 21
3.8. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 22 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 22
3.8.1. Greediness and Instability . . . . . . . . . . . . . 22 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 23
3.8.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 24 3.7.1. Greediness and Instability . . . . . . . . . . . . . 23
3.8.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 24 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 25
4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 26 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 26 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 27
4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 26 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 27
4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 26 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 27
5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 27
5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 27 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 28
6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 29 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 28
6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 31 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 30
6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 35 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 32
6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 35 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 37
6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 35 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 37
6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 35 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 37
6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 36 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 37
6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 36 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 37
6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 38 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 38
6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 38 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 40
6.4. Destination Advertisement Object (DAO) . . . . . . . . . 38 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 40
6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 38 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 40
6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 40 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 40
6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 40 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 42
6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 42
6.5. Destination Advertisement Object Acknowledgement 6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 40 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 42
6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 40 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 42
6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 42 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 44
6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 42 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 44
6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 42 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 44
6.6.1. Format of the CC Base Object . . . . . . . . . . . . 42 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 44
6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 43 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 45
6.7. RPL Control Message Options . . . . . . . . . . . . . . 43 6.7. RPL Control Message Options . . . . . . . . . . . . . . 45
6.7.1. RPL Control Message Option Generic Format . . . . . . 43 6.7.1. RPL Control Message Option Generic Format . . . . . . 45
6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 44 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 46
6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 45 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 47
6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 45 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 47
6.7.5. Route Information . . . . . . . . . . . . . . . . . . 46 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 48
6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 48 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 50
6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 49 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 52
6.7.8. Transit Information . . . . . . . . . . . . . . . . . 51 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 53
6.7.9. Solicited Information . . . . . . . . . . . . . . . . 54 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 56
6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 55 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 58
6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 58 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 60
7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 60 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 62
7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 60 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 62
7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 61 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 63
8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 63 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 63 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 65
8.2. Upward Route Discovery and Maintenance . . . . . . . . . 63 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 66
8.2.1. Neighbors and Parents within a DODAG Version . . . . 63 8.2.1. Neighbors and Parents within a DODAG Version . . . . 66
8.2.2. Neighbors and Parents across DODAG Versions . . . . . 64 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 67
8.2.3. DIO Message Communication . . . . . . . . . . . . . . 69 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 72
8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 70 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 72
8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 70 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 73
8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 71 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 73
8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 71 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 74
8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 72 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 75
9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 73 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 76
9.1. Destination Advertisement Parents . . . . . . . . . . . 73 9.1. Destination Advertisement Parents . . . . . . . . . . . 76
9.2. Downward Route Discovery and Maintenance . . . . . . . . 74 9.2. Downward Route Discovery and Maintenance . . . . . . . . 77
9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 75 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 78
9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 75 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 78
9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 76 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 79
9.4. DAO Transmission Scheduling . . . . . . . . . . . . . . 76 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 79
9.5. Triggering DAO Messages . . . . . . . . . . . . . . . . 77 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 81
9.6. Structure of DAO Messages . . . . . . . . . . . . . . . 78 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 81
9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 79 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 82
9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 80 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 83
9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 81 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 84
9.9.1. Path Control Example . . . . . . . . . . . . . . . . 82 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 85
9.10. Multicast Destination Advertisement Messages . . . . . . 87
9.10. Multicast Destination Advertisement Messages . . . . . . 84 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 88
10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 85 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 88
10.1. Security Overview . . . . . . . . . . . . . . . . . . . 85 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 89
10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 86 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 90
10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 87 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 90
10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 87 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 91
10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 88 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 92
10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 89 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 93
10.7. Reception of Incoming Packets . . . . . . . . . . . . . 90 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 94
10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 91 10.8. Coverage of Integrity and Confidentiality . . . . . . . 95
10.8. Coverage of Integrity and Confidentiality . . . . . . . 92 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 95
10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 92 10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 95
10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 92 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 96
10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 93 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 98
11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 95 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 98
11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 95 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 99
11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 96 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 100
11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 97 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 100
11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 97 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 103
12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 100 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 105
13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 102 14. Guidelines for Objective Functions . . . . . . . . . . . . . 106
14. Guidelines for Objective Functions . . . . . . . . . . . . . 103 14.1. Objective Function Behavior . . . . . . . . . . . . . . 106
14.1. Objective Function Behavior . . . . . . . . . . . . . . 103 15. Suggestions for Interoperation with Neighbor Discovery . . . 108
15. Suggestions for Interoperation with Neighbor Discovery . . . 105 16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 109
16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 106 17. Manageability Considerations . . . . . . . . . . . . . . . . 111
17. Manageability Considerations . . . . . . . . . . . . . . . . 108 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 111
17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 108 17.2. Configuration Management . . . . . . . . . . . . . . . . 112
17.2. Configuration Management . . . . . . . . . . . . . . . . 109 17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 112
17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 109 17.2.2. DIO and DAO Base Message and Options Configuration . 113
17.2.2. DIO and DAO Base Message and Options Configuration . 110
17.2.3. Protocol Parameters to be configured on every 17.2.3. Protocol Parameters to be configured on every
router in the LLN . . . . . . . . . . . . . . . . . . 110 router in the LLN . . . . . . . . . . . . . . . . . . 113
17.2.4. Protocol Parameters to be configured on every 17.2.4. Protocol Parameters to be configured on every
non-DODAG-root router in the LLN . . . . . . . . . . 111 non-DODAG-root router in the LLN . . . . . . . . . . 114
17.2.5. Parameters to be configured on the DODAG root . . . . 111 17.2.5. Parameters to be configured on the DODAG root . . . . 114
17.2.6. Configuration of RPL Parameters related to 17.2.6. Configuration of RPL Parameters related to
DAO-based mechanisms . . . . . . . . . . . . . . . . 112 DAO-based mechanisms . . . . . . . . . . . . . . . . 115
17.2.7. Configuration of RPL Parameters related to 17.2.7. Configuration of RPL Parameters related to
Security mechanisms . . . . . . . . . . . . . . . . . 113 Security mechanisms . . . . . . . . . . . . . . . . . 116
17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 114 17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 117
17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 114 17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 117
17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 114 17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 117
17.3.2. Monitoring a DODAG inconsistencies and loop 17.3.2. Monitoring a DODAG inconsistencies and loop
detection . . . . . . . . . . . . . . . . . . . . . . 115 detection . . . . . . . . . . . . . . . . . . . . . . 118
17.4. Monitoring of the RPL data structures . . . . . . . . . 116 17.4. Monitoring of the RPL data structures . . . . . . . . . 119
17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 116 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 119
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) 17.4.2. Destination Oriented Directed Acyclic Graph (DAG)
Table . . . . . . . . . . . . . . . . . . . . . . . . 116 Table . . . . . . . . . . . . . . . . . . . . . . . . 119
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 120
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 121
17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 121
17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 122
17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 119 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 123
17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 120 17.9. Performance Management . . . . . . . . . . . . . . . . . 123
17.9. Performance Management . . . . . . . . . . . . . . . . . 120 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 123
17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 120 18. Security Considerations . . . . . . . . . . . . . . . . . . . 124
18. Security Considerations . . . . . . . . . . . . . . . . . . . 121 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 124
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 121 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 126
19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 123 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 126
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 123 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 127
19.3. New Registry for the Mode of Operation (MOP) . . . . . . 124 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 128
19.4. RPL Control Message Option . . . . . . . . . . . . . . . 125 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 128
19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 125 19.6. New Registry for the Security Section Algorithm . . . . 129
19.6. New Registry for the Security Section Algorithm . . . . 126 19.7. New Registry for the Security Section Flags . . . . . . 129
19.7. New Registry for the Security Section Flags . . . . . . 126 19.8. New Registry for Per-KIM Security Levels . . . . . . . . 130
19.8. New Registry for the Key Identification Mode . . . . . . 127 19.9. New Registry for the DIS (DODAG Informational
19.9. New Registry for the KIM levels . . . . . . . . . . . . 127 Solicitation) Flags . . . . . . . . . . . . . . . . . . 131
19.10. New Registry for the DIS (DODAG Informational 19.10. New Registry for the DODAG Information Object (DIO)
Solicitation) Flags . . . . . . . . . . . . . . . . . . 128
19.11. New Registry for the DODAG Information Object (DIO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 129
19.12. New Registry for the Destination Advertisement Object
(DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 129
19.13. New Registry for the Destination Advertisement Object
(DAO) Acknowledgement Flags . . . . . . . . . . . . . . 130
19.14. New Registry for the Consistency Check (CC) Flags . . . 130
19.15. New Registry for the DODAG Configuration Option Flags . 131
19.16. New Registry for the RPL Target Option Flags . . . . . . 131
19.17. New Registry for the Transit Information Option Flags . 132
19.18. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132
19.19. ICMPv6: Error in Source Routing Header . . . . . . . . . 133 19.11. New Registry for the Destination Advertisement Object
19.20. Link-Local Scope multicast address . . . . . . . . . . . 133 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 132
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 134 19.12. New Registry for the Destination Advertisement Object
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 135 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 133
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 136 19.13. New Registry for the Consistency Check (CC) Flags . . . 133
22.1. Normative References . . . . . . . . . . . . . . . . . . 136 19.14. New Registry for the DODAG Configuration Option Flags . 134
22.2. Informative References . . . . . . . . . . . . . . . . . 137 19.15. New Registry for the RPL Target Option Flags . . . . . . 134
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 19.16. New Registry for the Transit Information Option Flags . 134
19.17. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 135
19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 136
19.19. Link-Local Scope multicast address . . . . . . . . . . . 136
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 137
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 138
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 139
22.1. Normative References . . . . . . . . . . . . . . . . . . 139
22.2. Informative References . . . . . . . . . . . . . . . . . 140
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143
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 7, line 46 skipping to change at page 7, 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. RPL expects an external RPL operations require bidirectional links. It is required that the
mechanism to verify link properties and neighbor reachability. reachability of a router is verified before the router can be used as
Neighbor Unreachability Detection (NUD) is an example such a a parent. RPL expects an external mechanism to be triggered during
mechanism, but alternates are possible, such as L2 triggers. the parent selection phase in order to verify link properties and
neighbor reachability. Neighbor Unreachability Detection (NUD) is
such a mechanism, but alternates are possible, including
Bidirectional Forwarding Detection [RFC5881] and hints from lower
layers via L2 triggers like [RFC5184]. In a general fashion, a
detection mechanism that is reactive to traffic is favored in order
to minimize the cost of monitoring links that are not being used.
RPL provides a mechanism to disseminate information, in particular a RPL also expects an external mechanism to access and transport some
prefix shared within a subnet. When this is used, one or more control information, referred to as the "RPL Packet Information", in
routers own a prefix and are authoritative for generating its data packets. The RPL Packet Information is defined in Section 11.2
advertisements. Other routers propagate the prefix information and enables the association of a data packet with a RPL instance and
without changing the prefix or the associated control information. the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option
This capability of announcing the subnet prefix is not to be confused [I-D.ietf-6man-rpl-option] is an example of such mechanism. The
with route advertisements, and this mechanism does not by any means mechanism is required for all packets except when strict source
constrain RPL operations to within a subnet. Routers that own routing is used (that is for packets going downward in non-storing
prefixes can also benefit from RPL to form a larger routed structures mode as detailed further in Section 9), which by nature prevents
whereby each router announces its prefixes to its peers in the endless loops and alleviates the need for the RPL Packet Information.
network. Future companion specifications may propose alternate ways to carry
the RPL Packet Information in the IPv6 packets and may extend the RPL
Packet Information to support additional features.
RPL provides a mechanism to disseminate information over the
dynamically-formed network topology. The dissemination enables
minimal configuration in the nodes, allowing nodes to operate mostly
autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to
optimize the dissemination as described in Section 8.3.
In some applications, RPL assembles topologies of routers that own
independent prefixes. Those prefixes may or may not be aggregatable
depending on the origin of the routers. RPL also introduces the
capability to bind a subnet together and route within that subnet.
In that case, the source of the dissemination is authoritative for
the information about the subnet that RPL disseminates.
When operating within a subnet, RPL may in particular disseminate
Neighbor Discovery information such as the [RFC4861] Prefix
Information Option (PIO) and the [RFC4191] Route Information Option
(RIO). ND information that is disseminated by RPL conserves its
original semantics. It is not to be confused with routing
advertisements and it is not to be directly redistributed in another
routing protocol. However, a RPL router may trivially reform the
original ND option, use the option as if received in an ND Router
Advertisements and expose it in its own RAs.
A set of companion documents to this specification will provide A set of companion documents to this specification will provide
further guidance in the form of applicability statements specifying a further guidance in the form of applicability statements specifying a
set of operating points appropriate to the Building Automation, Home set of operating points appropriate to the Building Automation, Home
Automation, Industrial, and Urban application scenarios. Automation, Industrial, and Urban application scenarios.
1.2. Expectations of Link Layer Type 1.2. Expectations of Link Layer Type
In compliance with the layered architecture of IP, RPL does not rely In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link layer technology. RPL on any particular features of a specific link layer technology. RPL
skipping to change at page 11, line 20 skipping to change at page 12, line 20
Goal. Goal.
Floating: A DODAG is floating if it is not Grounded. A floating Floating: A DODAG is floating if it is not Grounded. A floating
DODAG is not expected to have the properties required to DODAG is not expected to have the properties required to
satisfy the goal. It may, however, provide connectivity to satisfy the goal. It may, however, provide connectivity to
other nodes within the DODAG. other nodes within the DODAG.
DODAG parent: A parent of a node within a DODAG is one of the DODAG parent: A parent of a node within a DODAG is one of the
immediate successors of the node on a path towards the DODAG immediate successors of the node on a path towards the DODAG
root. A DODAG parent's Rank is lower than the node's. (See root. A DODAG parent's Rank is lower than the node's. (See
Section 3.6.1). Section 3.5.1).
Sub-DODAG The sub-DODAG of a node is the set of other nodes whose Sub-DODAG The sub-DODAG of a node is the set of other nodes whose
paths to the DODAG root pass through that node. Nodes in the paths to the DODAG root pass through that node. Nodes in the
sub-DODAG of a node have a greater Rank than that node. (See sub-DODAG of a node have a greater Rank than that node. (See
Section 3.6.1). Section 3.5.1).
Local DODAG: Local DODAGs contain one and only one root node, and Local DODAG: Local DODAGs contain one and only one root node, and
allows that single root node to allocate and manage a RPL allows that single root node to allocate and manage a RPL
Instance, identified by a local RPLInstanceID, without Instance, identified by a local RPLInstanceID, without
coordination with other nodes. This is typically done in order coordination with other nodes. This is typically done in order
to optimize routes to a destination within the LLN. (See to optimize routes to a destination within the LLN. (See
Section 5). Section 5).
Global DODAG: A Global DODAG uses a global RPLInstanceID that may be Global DODAG: A Global DODAG uses a global RPLInstanceID that may be
coordinated among several other nodes. (See Section 5). coordinated among several other nodes. (See Section 5).
skipping to change at page 12, line 16 skipping to change at page 13, line 16
The aim of this section is to describe RPL in the spirit of The aim of this section is to describe RPL in the spirit of
[RFC4101]. Protocol details can be found in further sections. [RFC4101]. Protocol details can be found in further sections.
3.1. Topology 3.1. Topology
This section describes the basic RPL topologies that may be formed, This section describes the basic RPL topologies that may be formed,
and the rules by which these are constructed, i.e. the rules and the rules by which these are constructed, i.e. the rules
governing DODAG formation. governing DODAG formation.
3.1.1. RPL Identifiers 3.1.1. Constructing Topologies
LLNs, such as Radio Networks, do not typically have a predefined
topologies, for example those imposed by point to point wires, so RPL
has to discover links and then select peers sparingly.
Because in many cases layer 2 ranges overlap only partially, RPL
forms non-transitive/NBMA network topologies upon which it computes
routes.
RPL routes are optimized for traffic to or from one or more roots
that act as sinks for the topology. As a result, RPL organizes a
topology as a Directed Acyclic Graph (DAG) that is partitioned into
one or more Destination Oriented DAGS (DODAGs), one DODAG per sink.
If the DAG has multiple roots, then it is expected that the roots are
federated by a common backbone such as a transit link.
3.1.2. RPL Identifiers
RPL uses four values to identify and maintain a topology: RPL uses four values to identify and maintain a topology:
o The first is a RPLInstanceID. A RPLInstanceID identifies a set of o The first is a RPLInstanceID. A RPLInstanceID identifies a set of
one or more Destination Oriented DAGs (DODAGs). A network may one or more Destination Oriented DAGs (DODAGs). A network may
have multiple RPLInstanceIDs, each of which defines an independent have multiple RPLInstanceIDs, each of which defines an independent
set of DODAGs, which may be optimized for different Objective set of DODAGs, which may be optimized for different Objective
Functions (OFs) and/or applications. The set of DODAGs identified Functions (OFs) and/or applications. The set of DODAGs identified
by a RPLInstanceID is called a RPL Instance. All DODAGs in the by a RPLInstanceID is called a RPL Instance. All DODAGs in the
same RPL Instance use the same OF. same RPL Instance use the same OF.
skipping to change at page 12, line 43 skipping to change at page 14, line 11
o The third is a DODAGVersionNumber. The scope of a o The third is a DODAGVersionNumber. The scope of a
DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed
from the DODAG root, by incrementing the DODAGVersionNumber. The from the DODAG root, by incrementing the DODAGVersionNumber. The
combination of RPLInstanceID, DODAGID, and DODAGVersionNumber combination of RPLInstanceID, DODAGID, and DODAGVersionNumber
uniquely identifies a DODAG Version. uniquely identifies a DODAG Version.
o The fourth is Rank. The scope of Rank is a DODAG Version. Rank o The fourth is Rank. The scope of Rank is a DODAG Version. Rank
establishes a partial order over a DODAG Version, defining establishes a partial order over a DODAG Version, defining
individual node positions with respect to the DODAG root. individual node positions with respect to the DODAG root.
3.2. Instances, DODAGs, and DODAG Versions 3.1.3. Instances, DODAGs, and DODAG Versions
A RPL Instance contains one or more DODAG roots. A RPL Instance may A RPL Instance contains one or more DODAG roots. A RPL Instance may
provide routes to certain destination prefixes, reachable via the provide routes to certain destination prefixes, reachable via the
DODAG roots or alternate paths within the DODAG. These roots may DODAG roots or alternate paths within the DODAG. These roots may
operate independently, or may coordinate over a network that is not operate independently, or may coordinate over a network that is not
necessarily as constrained as a LLN. necessarily as constrained as a LLN.
A RPL Instance may comprise: A RPL Instance may comprise:
o a single DODAG with a single root o a single DODAG with a single root
skipping to change at page 14, line 43 skipping to change at page 16, line 24
| | ------/ | \ | | | ------/ | \ |
| | / | (B) | | | / | (B) |
| | | |\ | | | | |\ |
| | | : : | | | | : : |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
Version N Version N+1 Version N Version N+1
Figure 2: DODAG Version Figure 2: DODAG Version
3.3. Upward Routes and DODAG Construction 3.2. Upward Routes and DODAG Construction
RPL provisions routes Up towards DODAG roots, forming a DODAG RPL provisions routes Up towards DODAG roots, forming a DODAG
optimized according to an Objective Function (OF). RPL nodes optimized according to an Objective Function (OF). RPL nodes
construct and maintain these DODAGs through DODAG Information Object construct and maintain these DODAGs through DODAG Information Object
(DIO) messages. (DIO) messages.
3.3.1. Objective Function (OF) 3.2.1. Objective Function (OF)
The Objective Function (OF) defines how RPL nodes select and optimize The Objective Function (OF) defines how RPL nodes select and optimize
routes within a RPL Instance. The OF is identified by an Objective routes within a RPL Instance. The OF is identified by an Objective
Code Point (OCP) within the DIO Configuration option. An OF defines Code Point (OCP) within the DIO Configuration option. An OF defines
how nodes translate one or more metrics and constraints, which are how nodes translate one or more metrics and constraints, which are
themselves defined in [I-D.ietf-roll-routing-metrics], into a value themselves defined in [I-D.ietf-roll-routing-metrics], into a value
called Rank, which approximates the node's distance from a DODAG called Rank, which approximates the node's distance from a DODAG
root. An OF also defines how nodes select parents. Further details root. An OF also defines how nodes select parents. Further details
may be found in Section 14, [I-D.ietf-roll-routing-metrics], may be found in Section 14, [I-D.ietf-roll-routing-metrics],
[I-D.ietf-roll-of0], and related companion specifications. [I-D.ietf-roll-of0], and related companion specifications.
3.3.2. DODAG Repair 3.2.2. DODAG Repair
A DODAG Root institutes a global repair operation by incrementing the A DODAG Root institutes a global repair operation by incrementing the
DODAG Version Number. This initiates a new DODAG Version. Nodes in DODAG Version Number. This initiates a new DODAG Version. Nodes in
the new DODAG Version can choose a new position whose Rank is not the new DODAG Version can choose a new position whose Rank is not
constrained by their Rank within the old DODAG Version. constrained by their Rank within the old DODAG Version.
RPL also supports mechanisms which may be used for local repair RPL also supports mechanisms which may be used for local repair
within the DODAG Version. The DIO message specifies the necessary within the DODAG Version. The DIO message specifies the necessary
parameters as configured from and controlled by policy at the DODAG parameters as configured from and controlled by policy at the DODAG
root. root.
3.3.3. Security 3.2.3. Security
RPL supports message confidentiality and integrity. It is designed RPL supports message confidentiality and integrity. It is designed
such that link-layer mechanisms can be used when available and such that link-layer mechanisms can be used when available and
appropriate, yet in their absence RPL can use its own mechanisms. appropriate, yet in their absence RPL can use its own mechanisms.
RPL has three basic security modes. RPL has three basic security modes.
In the first, called "unsecured," RPL control messages are sent In the first, called "unsecured," RPL control messages are sent
without any additional security mechanisms. Unsecured mode does not without any additional security mechanisms. Unsecured mode does not
imply that the RPL network is unsecure: it could be using other imply that the RPL network is unsecure: it could be using other
present security primitives (e.g. link-layer security) to meet present security primitives (e.g. link-layer security) to meet
skipping to change at page 16, line 5 skipping to change at page 17, line 32
secured RPL messages. secured RPL messages.
The third mode is called "authenticated." In authenticated mode, The third mode is called "authenticated." In authenticated mode,
nodes have pre-installed keys as in pre-installed mode, but the pre- nodes have pre-installed keys as in pre-installed mode, but the pre-
installed key may only be used to join a RPL Instance as a leaf. installed key may only be used to join a RPL Instance as a leaf.
Joining an authenticated RPL Instance as a router requires obtaining Joining an authenticated RPL Instance as a router requires obtaining
a key from an authentication authority. The process by which this a key from an authentication authority. The process by which this
key is obtained is out of scope for this specification (to be defined key is obtained is out of scope for this specification (to be defined
in future companion specifications). in future companion specifications).
3.3.4. Grounded and Floating DODAGs 3.2.4. Grounded and Floating DODAGs
DODAGs can be grounded or floating: the DODAG root advertises which DODAGs can be grounded or floating: the DODAG root advertises which
is the case. A grounded DODAG offers connectivity to hosts that are is the case. A grounded DODAG offers connectivity to hosts that are
required for satisfying the application-defined goal. A floating required for satisfying the application-defined goal. A floating
DODAG is not expected to satisfy the goal and in most cases only DODAG is not expected to satisfy the goal and in most cases only
provides routes to nodes within the DODAG. Floating DODAGs may be provides routes to nodes within the DODAG. Floating DODAGs may be
used, for example, to preserve inner connectivity during repair. used, for example, to preserve inner connectivity during repair.
3.3.5. Local DODAGs 3.2.5. Local DODAGs
RPL nodes can optimize routes to a destination within an LLN by RPL nodes can optimize routes to a destination within an LLN by
forming a local DODAG whose DODAG Root is the desired destination. forming a local DODAG whose DODAG Root is the desired destination.
Unlike global DAGs, which can consist of multiple DODAGs, local DAGs Unlike global DAGs, which can consist of multiple DODAGs, local DAGs
have one and only one DODAG and therefore one DODAG Root. Local have one and only one DODAG and therefore one DODAG Root. Local
DODAGs can be constructed on-demand. DODAGs can be constructed on-demand.
3.3.6. Administrative Preference 3.2.6. Administrative Preference
An implementation/deployment may specify that some DODAG roots should An implementation/deployment may specify that some DODAG roots should
be used over others through an administrative preference. be used over others through an administrative preference.
Administrative preference offers a way to control traffic and Administrative preference offers a way to control traffic and
engineer DODAG formation in order to better support application engineer DODAG formation in order to better support application
requirements or needs. requirements or needs.
3.3.7. Datapath Validation and Loop Detection 3.2.7. Datapath Validation and Loop Detection
RPL often needs to carry control information in data packets. This
information is used to validate the routing states as discussed in
Section 11.2. The only exception is when strict source routing is
used for packets going downward in non-storing mode (detailed further
in Section 9), which by nature prevents endless loops and alleviates
the need for the control information.
RPL control information may be extended to add additional features in
future companion specifications.
The low-power and lossy nature of LLNs motivates RPL's use of on- The low-power and lossy nature of LLNs motivates RPL's use of on-
demand loop detection using data packets. Because data traffic can demand loop detection using data packets. Because data traffic can
be infrequent, maintaining a routing topology that is constantly up be infrequent, maintaining a routing topology that is constantly up
to date with the physical topology can waste energy. Typical LLNs to date with the physical topology can waste energy. Typical LLNs
exhibit variations in physical connectivity that are transient and exhibit variations in physical connectivity that are transient and
innocuous to traffic, but that would be costly to track closely from innocuous to traffic, but that would be costly to track closely from
the control plane. Transient and infrequent changes in connectivity the control plane. Transient and infrequent changes in connectivity
need not be addressed by RPL until there is data to send. This need not be addressed by RPL until there is data to send. This
aspect of RPL's design draws from existing, highly used LLN protocols aspect of RPL's design draws from existing, highly used LLN protocols
as well as extensive experimental and deployment evidence on its as well as extensive experimental and deployment evidence on its
efficacy. efficacy.
Each data packet includes the Rank of the transmitter. An The RPL Packet Information that is transported with data packets
inconsistency between the routing decision for a packet (upward or includes the Rank of the transmitter. An inconsistency between the
downward) and the Rank relationship between the two nodes indicates a routing decision for a packet (upward or downward) and the Rank
possible loop. On receiving such a packet, a node institutes a local relationship between the two nodes indicates a possible loop. On
repair operation. receiving such a packet, a node institutes a local repair operation.
For example, if a node receives a packet flagged as moving in the For example, if a node receives a packet flagged as moving in the
upward direction, and if that packet records that the transmitter is upward direction, and if that packet records that the transmitter is
of a lower (lesser) Rank than the receiving node, then the receiving of a lower (lesser) Rank than the receiving node, then the receiving
node is able to conclude that the packet has not progressed in the node is able to conclude that the packet has not progressed in the
upward direction and that the DODAG is inconsistent. upward direction and that the DODAG is inconsistent.
3.3.8. Distributed Algorithm Operation 3.2.8. Distributed Algorithm Operation
A high level overview of the distributed algorithm, which constructs A high level overview of the distributed algorithm, which constructs
the DODAG, is as follows: the DODAG, is as follows:
o Some nodes are configured to be DODAG roots, with associated DODAG o Some nodes are configured to be DODAG roots, with associated DODAG
configurations. configurations.
o Nodes advertise their presence, affiliation with a DODAG, routing o Nodes advertise their presence, affiliation with a DODAG, routing
cost, and related metrics by sending link-local multicast DIO cost, and related metrics by sending link-local multicast DIO
messages to all-RPL-nodes. messages to all-RPL-nodes.
o Nodes listen for DIOs and use their information to join a new o Nodes listen for DIOs and use their information to join a new
DODAG (thus selecting DODAG parents), or to maintain an existing DODAG (thus selecting DODAG parents), or to maintain an existing
DODAG, according to the specified Objective Function and Rank of DODAG, according to the specified Objective Function and Rank of
their neighbors. their neighbors.
o Nodes provision routing table entries, for the destinations o Nodes provision routing table entries, for the destinations
specified by the DIO message, via their DODAG parents in the DODAG specified by the DIO message, via their DODAG parents in the DODAG
Version. Nodes that decide to join a DODAG MUST provision a DODAG Version. Nodes that decide to join a DODAG can provision one or
parent as a default route for the associated instance. more DODAG parents as the next-hop for the default route and a
number of other external routes for the associated instance.
3.4. Downward Routes and Destination Advertisement 3.3. Downward Routes and Destination Advertisement
RPL uses Destination Advertisement Object (DAO) messages to establish RPL uses Destination Advertisement Object (DAO) messages to establish
downward routes. DAO messages are an optional feature for downward routes. DAO messages are an optional feature for
applications that require P2MP or P2P traffic. RPL supports two applications that require P2MP or P2P traffic. RPL supports two
modes of downward traffic: storing (fully stateful) or non-storing modes of downward traffic: storing (fully stateful) or non-storing
(fully source routed). Any given RPL Instance is either storing or (fully source routed). Any given RPL Instance is either storing or
non-storing. In both cases, P2P packets travel Up toward a DODAG non-storing. In both cases, P2P packets travel Up toward a DODAG
Root then Down to the final destination (unless the destination is on Root then Down to the final destination (unless the destination is on
the upward route). In the non-storing case the packet will travel the upward route). In the non-storing case the packet will travel
all the way to a DODAG root before traveling Down. In the storing all the way to a DODAG root before traveling Down. In the storing
case the packet may be directed Down towards the destination by a case the packet may be directed Down towards the destination by a
common ancestor of the source and the destination prior to reaching a common ancestor of the source and the destination prior to reaching a
DODAG Root. DODAG Root.
This specification describes a basic mode of operation in support of This specification describes a basic mode of operation in support of
P2P traffic. Note that more optimized P2P solutions may be described P2P traffic. Note that more optimized P2P solutions may be described
in companion specifications. in companion specifications.
3.5. Local DODAGs Route Discovery 3.4. Local DODAGs Route Discovery
A RPL network can optionally support on-demand discovery of DODAGs to A RPL network can optionally support on-demand discovery of DODAGs to
specific destinations within an LLN. Such local DODAGs behave specific destinations within an LLN. Such local DODAGs behave
slightly differently than global DODAGs: they are uniquely defined by slightly differently than global DODAGs: they are uniquely defined by
the combination of DODAGID and RPLInstanceID. The RPLInstanceID the combination of DODAGID and RPLInstanceID. The RPLInstanceID
denotes whether a DODAG is a local DODAG. denotes whether a DODAG is a local DODAG.
3.6. Rank Properties 3.5. Rank Properties
The rank of a node is a scalar representation of the location of that The rank of a node is a scalar representation of the location of that
node within a DODAG Version. The rank is used to avoid and detect node within a DODAG Version. The rank is used to avoid and detect
loops, and as such must demonstrate certain properties. The exact loops, and as such must demonstrate certain properties. The exact
calculation of the rank is left to the Objective Function. Even calculation of the rank is left to the Objective Function. Even
though the specific computation of the rank is left to the Objective though the specific computation of the rank is left to the Objective
Function, the rank must implement generic properties regardless of Function, the rank must implement generic properties regardless of
the Objective Function. the Objective Function.
In particular, the rank of the nodes must monotonically decrease as In particular, the rank of the nodes must monotonically decrease as
skipping to change at page 19, line 22 skipping to change at page 20, line 46
Abstract: The rank does not have a physical unit, but rather a range Abstract: The rank does not have a physical unit, but rather a range
of increment per hop, where the assignment of each increment of increment per hop, where the assignment of each increment
is to be determined by the Objective Function. is to be determined by the Objective Function.
The rank value feeds into DODAG parent selection, according to the The rank value feeds into DODAG parent selection, according to the
RPL loop-avoidance strategy. Once a parent has been added, and a RPL loop-avoidance strategy. Once a parent has been added, and a
rank value for the node within the DODAG has been advertised, the rank value for the node within the DODAG has been advertised, the
node's further options with regard to DODAG parent selection and node's further options with regard to DODAG parent selection and
movement within the DODAG are restricted in favor of loop avoidance. movement within the DODAG are restricted in favor of loop avoidance.
3.6.1. Rank Comparison (DAGRank()) 3.5.1. Rank Comparison (DAGRank())
Rank may be thought of as a fixed point number, where the position of Rank may be thought of as a fixed point number, where the position of
the radix point between the integer part and the fractional part is the radix point between the integer part and the fractional part is
determined by MinHopRankIncrease. MinHopRankIncrease is the minimum determined by MinHopRankIncrease. MinHopRankIncrease is the minimum
increase in rank between a node and any of its DODAG parents. A increase in rank between a node and any of its DODAG parents. A
DODAG Root provisions MinHopRankIncrease. MinHopRankIncrease creates DODAG Root provisions MinHopRankIncrease. MinHopRankIncrease creates
a tradeoff between hop cost precision and the maximum number of hops a tradeoff between hop cost precision and the maximum number of hops
a network can support. A very large MinHopRankIncrease, for example, a network can support. A very large MinHopRankIncrease, for example,
allows precise characterization of a given hop's affect on Rank but allows precise characterization of a given hop's affect on Rank but
cannot support many hops. cannot support many hops.
skipping to change at page 20, line 16 skipping to change at page 21, line 38
A node A has a rank less than the rank of a node B if DAGRank(A) is A node A has a rank less than the rank of a node B if DAGRank(A) is
less than DAGRank(B). less than DAGRank(B).
A node A has a rank equal to the rank of a node B if DAGRank(A) is A node A has a rank equal to the rank of a node B if DAGRank(A) is
equal to DAGRank(B). equal to DAGRank(B).
A node A has a rank greater than the rank of a node B if DAGRank(A) A node A has a rank greater than the rank of a node B if DAGRank(A)
is greater than DAGRank(B). is greater than DAGRank(B).
3.6.2. Rank Relationships 3.5.2. Rank Relationships
Rank computations maintain the following properties for any nodes M Rank computations maintain the following properties for any nodes M
and N that are neighbors in the LLN: and N that are neighbors in the LLN:
DAGRank(M) is less than DAGRank(N): In this case, the position of M DAGRank(M) is less than DAGRank(N): In this case, the position of M
is closer to the DODAG root than the position of N. Node M is closer to the DODAG root than the position of N. Node M
may safely be a DODAG parent for Node N without risk of may safely be a DODAG parent for Node N without risk of
creating a loop. Further, for a node N, all parents in the creating a loop. Further, for a node N, all parents in the
DODAG parent set must be of rank less than DAGRank(N). In DODAG parent set must be of rank less than DAGRank(N). In
other words, the rank presented by a node N MUST be greater other words, the rank presented by a node N MUST be greater
skipping to change at page 20, line 48 skipping to change at page 22, line 24
node N selects node M as DODAG parent there is a risk to node N selects node M as DODAG parent there is a risk to
create a loop. create a loop.
As an example, the rank could be computed in such a way so as to As an example, the rank could be computed in such a way so as to
closely track ETX (Expected Transmission Count, a fairly common closely track ETX (Expected Transmission Count, a fairly common
routing metric used in LLN and defined in routing metric used in LLN and defined in
[I-D.ietf-roll-routing-metrics]) when the metric that an objective [I-D.ietf-roll-routing-metrics]) when the metric that an objective
function minimizes is ETX, or latency, or in a more complicated way function minimizes is ETX, or latency, or in a more complicated way
as appropriate to the objective function being used within the DODAG. as appropriate to the objective function being used within the DODAG.
3.7. Routing Metrics and Constraints Used By RPL 3.6. Routing Metrics and Constraints Used By RPL
Routing metrics are used by routing protocols to compute shortest Routing metrics are used by routing protocols to compute shortest
paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120])
and OSPF ([RFC4915]) use static link metrics. Such link metrics can and OSPF ([RFC4915]) use static link metrics. Such link metrics can
simply reflect the bandwidth or can also be computed according to a simply reflect the bandwidth or can also be computed according to a
polynomial function of several metrics defining different link polynomial function of several metrics defining different link
characteristics. Some routing protocols support more than one characteristics. Some routing protocols support more than one
metric: in the vast majority of the cases, one metric is used per metric: in the vast majority of the cases, one metric is used per
(sub)topology. Less often, a second metric may be used as a tie- (sub)topology. Less often, a second metric may be used as a tie-
breaker in the presence of Equal Cost Multiple Paths (ECMP). The breaker in the presence of Equal Cost Multiple Paths (ECMP). The
skipping to change at page 22, line 9 skipping to change at page 23, line 28
The set of supported link/node constraints and metrics is specified The set of supported link/node constraints and metrics is specified
in [I-D.ietf-roll-routing-metrics]. in [I-D.ietf-roll-routing-metrics].
Example 1: Shortest path: path offering the shortest end-to-end Example 1: Shortest path: path offering the shortest end-to-end
delay. delay.
Example 2: Shortest Constrained path: the path that does not traverse Example 2: Shortest Constrained path: the path that does not traverse
any battery-operated node and that optimizes the path any battery-operated node and that optimizes the path
reliability. reliability.
3.8. Loop Avoidance 3.7. Loop Avoidance
RPL avoids creating loops when undergoing topology changes and RPL avoids creating loops when undergoing topology changes and
includes rank-based datapath validation mechanisms for detecting includes rank-based datapath validation mechanisms for detecting
loops when they do occur (see Section 11 for more details). In loops when they do occur (see Section 11 for more details). In
practice, this means that RPL guarantees neither loop free path practice, this means that RPL guarantees neither loop free path
selection nor tight delay convergence times, but can detect and selection nor tight delay convergence times, but can detect and
repair a loop as soon as it is used. RPL uses this loop detection to repair a loop as soon as it is used. RPL uses this loop detection to
ensure that packets make forward progress within the DODAG Version ensure that packets make forward progress within the DODAG Version
and trigger repairs when necessary. and trigger repairs when necessary.
3.8.1. Greediness and Instability 3.7.1. Greediness and Instability
A node is greedy if it attempts to move deeper (increase Rank) in the A node is greedy if it attempts to move deeper (increase Rank) in the
DODAG Version in order to increase the size of the parent set or DODAG Version in order to increase the size of the parent set or
improve some other metric. Once a node has joined a DODAG Version, improve some other metric. Once a node has joined a DODAG Version,
RPL disallows certain behaviors, including greediness, in order to RPL disallows certain behaviors, including greediness, in order to
prevent resulting instabilities in the DODAG Version. prevent resulting instabilities in the DODAG Version.
Suppose a node is willing to receive and process a DIO message from a Suppose a node is willing to receive and process a DIO message from a
node in its own sub-DODAG, and in general a node deeper than itself. node in its own sub-DODAG, and in general a node deeper than itself.
In this case, a possibility exists that a feedback loop is created, In this case, a possibility exists that a feedback loop is created,
wherein two or more nodes continue to try and move in the DODAG wherein two or more nodes continue to try and move in the DODAG
Version while attempting to optimize against each other. In some Version while attempting to optimize against each other. In some
cases, this will result in instability. It is for this reason that cases, this will result in instability. It is for this reason that
RPL limits the cases where a node may process DIO messages from RPL limits the cases where a node may process DIO messages from
deeper nodes to some forms of local repair. This approach creates an deeper nodes to some forms of local repair. This approach creates an
'event horizon', whereby a node cannot be influenced beyond some 'event horizon', whereby a node cannot be influenced beyond some
limit into an instability by the action of nodes that may be in its limit into an instability by the action of nodes that may be in its
own sub-DODAG. own sub-DODAG.
3.8.1.1. Example: Greedy Parent Selection and Instability 3.7.1.1. Example: Greedy Parent Selection and Instability
(A) (A) (A) (A) (A) (A)
|\ |\ |\ |\ |\ |\
| `-----. | `-----. | `-----. | `-----. | `-----. | `-----.
| \ | \ | \ | \ | \ | \
(B) (C) (B) \ | (C) (B) (C) (B) \ | (C)
\ | | / \ | | /
`-----. | | .-----' `-----. | | .-----'
\| |/ \| |/
(C) (B) (C) (B)
skipping to change at page 24, line 26 skipping to change at page 25, line 37
* Nodes (B) and (C) stay at a rank sufficient to attach to their * Nodes (B) and (C) stay at a rank sufficient to attach to their
most preferred parent (A) and don't go for any deeper (worse) most preferred parent (A) and don't go for any deeper (worse)
alternate parents (Nodes are not greedy) alternate parents (Nodes are not greedy)
* Nodes (B) and (C) do not process DIO messages from nodes deeper * Nodes (B) and (C) do not process DIO messages from nodes deeper
than themselves (because such nodes are possibly in their own than themselves (because such nodes are possibly in their own
sub-DODAGs) sub-DODAGs)
These mechanisms are further described in Section 8.2.2.4 These mechanisms are further described in Section 8.2.2.4
3.8.2. DODAG Loops 3.7.2. DODAG Loops
A DODAG loop may occur when a node detaches from the DODAG and A DODAG loop may occur when a node detaches from the DODAG and
reattaches to a device in its prior sub-DODAG. This may happen in reattaches to a device in its prior sub-DODAG. This may happen in
particular when DIO messages are missed. Strict use of the DODAG particular when DIO messages are missed. Strict use of the DODAG
Version Number can eliminate this type of loop, but this type of loop Version Number can eliminate this type of loop, but this type of loop
may possibly be encountered when using some local repair mechanisms. may possibly be encountered when using some local repair mechanisms.
For example, consider the local repair mechanism that allows a node For example, consider the local repair mechanism that allows a node
to detach from the DODAG, advertise a rank of INFINITE_RANK (in order to detach from the DODAG, advertise a rank of INFINITE_RANK (in order
to poison its routes / inform its sub-DODAG), and then to re-attach to poison its routes / inform its sub-DODAG), and then to re-attach
to the DODAG. In that case the node may in some cases re-attach to to the DODAG. In that case the node may in some cases re-attach to
its own prior-sub-DODAG, causing a DODAG loop, because the poisoning its own prior-sub-DODAG, causing a DODAG loop, because the poisoning
may fail if the INFINITE_RANK advertisements are lost in the LLN may fail if the INFINITE_RANK advertisements are lost in the LLN
environment. (In this case the rank-based datapath validation environment. (In this case the rank-based datapath validation
mechanisms would eventually detect and trigger correction of the mechanisms would eventually detect and trigger correction of the
loop). loop).
3.8.3. DAO Loops 3.7.3. DAO Loops
A DAO loop may occur when the parent has a route installed upon A DAO loop may occur when the parent has a route installed upon
receiving and processing a DAO message from a child, but the child receiving and processing a DAO message from a child, but the child
has subsequently cleaned up the related DAO state. This loop happens has subsequently cleaned up the related DAO state. This loop happens
when a No-Path (a DAO message that invalidates a previously announced when a No-Path (a DAO message that invalidates a previously announced
prefix) was missed and persists until all state has been cleaned up. prefix) was missed and persists until all state has been cleaned up.
RPL includes an optional mechanism to acknowledge DAO messages, which RPL includes an optional mechanism to acknowledge DAO messages, which
may mitigate the impact of a single DAO message being missed. RPL may mitigate the impact of a single DAO message being missed. RPL
includes loop detection mechanisms that mitigate the impact of DAO includes loop detection mechanisms that mitigate the impact of DAO
loops and trigger their repair. (See Section 11.2.2.3). loops and trigger their repair. (See Section 11.2.2.3).
skipping to change at page 27, line 40 skipping to change at page 28, line 40
any instance that would match the packet. any instance that would match the packet.
Control and data packets within RPL network are tagged to Control and data packets within RPL network are tagged to
unambiguously identify what RPL Instance they are part of. unambiguously identify what RPL Instance they are part of.
Every RPL control message has a RPLInstanceID field. Some RPL Every RPL control message has a RPLInstanceID field. Some RPL
control messages, when referring to a local RPLInstanceID as defined control messages, when referring to a local RPLInstanceID as defined
below, may also include a DODAGID. below, may also include a DODAGID.
Data packets that flow within the RPL network expose the Data packets that flow within the RPL network expose the
RPLInstanceID in the IPv6 Hop-by-Hop RPL Option that is specified in RPLInstanceID as part of the RPL Packet Information that RPL
[I-D.ietf-6man-rpl-option], and further described in Section 11.2. requires, as further described in Section 11.2. For data packets
For data packets coming from outside the RPL network, the coming from outside the RPL network, the ingress router determines
RPLInstanceID is determined by the RPL network ingress router and the RPLInstanceID and places it into the resulting packet that it
placed in the IPv6 Hop-by-Hop RPL Option that is added to the packet. injects into the RPL network.
5.1. RPL Instance ID 5.1. RPL Instance ID
A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms
for allocating and provisioning global RPLInstanceID are out of scope for allocating and provisioning global RPLInstanceID are out of scope
for this specification. There can be up to 128 global instance in for this specification. There can be up to 128 global instance in
the whole network. Local instances are always used in conjunction the whole network. Local instances are always used in conjunction
with a DODAGID (which is either given explicitly or implicitly in with a DODAGID (which is either given explicitly or implicitly in
some cases), and up 64 local instances per DODAGID can be supported. some cases), and up 64 local instances per DODAGID can be supported.
Local instances are allocated and managed by the node that owns the Local instances are allocated and managed by the node that owns the
skipping to change at page 30, line 25 skipping to change at page 31, line 25
o 0x81: Secure DODAG Information Object (Section 6.3.2) o 0x81: Secure DODAG Information Object (Section 6.3.2)
o 0x82: Secure Destination Advertisement Object (Section 6.4.2) o 0x82: Secure Destination Advertisement Object (Section 6.4.2)
o 0x83: Secure Destination Advertisement Object Acknowledgment o 0x83: Secure Destination Advertisement Object Acknowledgment
(Section 6.5.2) (Section 6.5.2)
o 0x8A: Consistency Check (Section 6.6) o 0x8A: Consistency Check (Section 6.6)
If a node receives a RPL control message with an unknown Code field,
the node MUST discard the message without any further processing, MAY
raise a management alert, and MUST NOT send any messages in response.
The checksum is computed as specified in [RFC4443]. It is set to The checksum is computed as specified in [RFC4443]. It is set to
zero for the RPL security operations specified below, and computed zero for the RPL security operations specified below, and computed
once the rest of the content of the RPL message including the once the rest of the content of the RPL message including the
security fields is all set. security fields is all set.
The high order bit (0x80) of the code denotes whether the RPL message The high order bit (0x80) of the code denotes whether the RPL message
has security enabled. Secure RPL messages have a format to support has security enabled. Secure RPL messages have a format to support
confidentiality and integrity, illustrated in Figure 7. confidentiality and integrity, illustrated in Figure 7.
0 1 2 3 0 1 2 3
skipping to change at page 31, line 24 skipping to change at page 32, line 43
and delay protection. Because security covers the base message as and delay protection. Because security covers the base message as
well as options, in secured messages the security information lies well as options, in secured messages the security information lies
between the checksum and base, as shown in Figure 7. between the checksum and base, as shown in Figure 7.
The level of security and the algorithms in use are indicated in the The level of security and the algorithms in use are indicated in the
protocol messages as described below: protocol messages as described below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Level | Algorithm | KIM |Reserved | Flags | |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter | | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Key Identifier . . Key Identifier .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Section Figure 8: Security Section
Message authentication codes (MACs) and signatures cover the entire Message authentication codes (MACs) and signatures cover the entire
ICMPv6 RPL message, while encryption starts after the Security unsecured ICMPv6 RPL message, yielding a secured ICMPv6 RPL message
section. Use of the Security section is further detailed in with the inclusion of the cryptographic fields (MAC, signature,
Section 18 and Section 10. etc.). Encryption starts after the Security section. Use of the
Security section is further detailed in Section 18 and Section 10.
Counter is Time (T): If the Counter is Time flag is set then the Counter 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.
Security Level (Level): The Security Level field indicates the Reserved: 7-bit unused field. The field MUST be initialized to zero
provided packet protection. This value can be adapted on a by the sender and MUST be ignored by the receiver.
per-packet basis and allows for varying levels of data
authenticity and, optionally, for data confidentiality. The
KIM field indicates whether signatures are used and the meaning
of the Level field. The Security Level is set to one of the
values in the tables below:
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-127 | Unassigned | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2-127 | Unassigned | N/A |
+-------+---------------+-----+
Figure 9: Security Level (LVL) Encoding
The MAC attribute indicates that the message has a Message
Authentication Code of the specified length. The ENC attribute
indicates that the message is encrypted. The Sign attribute
indicates that the message has a signature of the specified
length.
Security Algorithm (Algorithm): The Security Algorithm field Security Algorithm (Algorithm): The Security Algorithm field
specifies the encryption, MAC, and signature scheme the network specifies the encryption, MAC, and signature scheme the network
uses. Supported values of this field are as follows: uses. Supported values of this field are as follows:
+-----------+-------------------+------------------------+ +-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature | | Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+ +-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA2 | | 0 | CCM with AES-128 | RSA with SHA-256 |
| 1-255 | Unassigned | Unassigned | | 1-255 | Unassigned | Unassigned |
+-------+-------------------+----------------------------+ +-----------+-------------------+------------------------+
Figure 10: Security Algorithm (Algorithm) Encoding Figure 9: Security Algorithm (Algorithm) Encoding
Section 10.9 describes the algorithms in greater detail. Section 10.9 describes the algorithms in greater detail.
Key Identifier Mode (KIM): The Key Identifier Mode field indicates Key Identifier Mode (KIM): The Key Identifier Mode is a 2-bit field
whether the key used for packet protection is determined that indicates whether the key used for packet protection is
implicitly or explicitly and indicates the particular determined implicitly or explicitly and indicates the
representation of the Key Identifier field. The Key Identifier particular representation of the Key Identifier field. The Key
Mode is set one of the values from the table below: Identifier Mode is set one of the values from the table below:
+------+-----+-----------------------------+------------+ +------+-----+-----------------------------+------------+
| Mode | KIM | Meaning | Key | | Mode | KIM | Meaning | Key |
| | | | Identifier | | | | | Identifier |
| | | | Length | | | | | Length |
| | | | (octets) | | | | | (octets) |
+------+-----+-----------------------------+------------+ +------+-----+-----------------------------+------------+
| 0 | 00 | Group key used. | 1 | | 0 | 00 | Group key used. | 1 |
| | | Key determined by Key Index | | | | | Key determined by Key Index | |
| | | field. | | | | | field. | |
skipping to change at page 33, line 50 skipping to change at page 34, line 42
| 3 | 11 | Node's signature key used. | 0/9 | | 3 | 11 | Node's signature key used. | 0/9 |
| | | If packet is encrypted, | | | | If packet is encrypted, |
| | | it uses a group key, Key | | | | | it uses a group key, Key | |
| | | Index and Key Source | | | | | Index and Key Source | |
| | | specify key. | | | | | specify key. | |
| | | | | | | | | |
| | | Key Source may be present. | | | | | Key Source may be present. | |
| | | Key Index may be present. | | | | | Key Index may be present. | |
+------+-----+-----------------------------+------------+ +------+-----+-----------------------------+------------+
Figure 11: Key Identifier Mode (KIM) Encoding Figure 10: Key Identifier Mode (KIM) Encoding
In Mode 3 (KIM=11), the presence or absence of the Key Source In Mode 3 (KIM=11), the presence or absence of the Key Source
and Key Identifier depends on the Security Level (LVL) and Key Identifier depends on the Security Level (LVL)
described below. If the Security Level indicates there is described below. If the Security Level indicates there is
encryption, then the fields are present; if it indicates there encryption, then the fields are present; if it indicates there
is no encryption, then the fields are not present. is no encryption, then the fields are not present.
Reserved: 5-bit unused field. The field MUST be initialized to zero Resvd: 3-bit unused field. The field MUST be initialized to zero by
by the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
Security Level (LVL): The Security Level is a 3-bit field that
indicates the provided packet protection. This value can be
adapted on a per-packet basis and allows for varying levels of
data authenticity and, optionally, for data confidentiality.
The KIM field indicates whether signatures are used and the
meaning of the Level field. Note that the assigned values of
Security Level are not necessarily ordered-- a higher value of
LVL does not necessarily equate to increased security. The
Security Level is set to one of the values in the tables below:
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-7 | Unassigned | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2-7 | Unassigned | N/A |
+-------+---------------+-----+
Figure 11: Security Level (LVL) Encoding
The MAC attribute indicates that the message has a Message
Authentication Code of the specified length. The ENC attribute
indicates that the message is encrypted. The Sign attribute
indicates that the message has a signature of the specified
length.
Flags: 8-bit unused field reserved for flags. The field MUST be Flags: 8-bit unused field reserved for flags. The field MUST be
initialized to zero by the sender and MUST be ignored by the initialized to zero by the sender and MUST be ignored by the
receiver. receiver.
Counter: The Counter field indicates the non-repeating 4-octet value Counter: The Counter field indicates the non-repeating 4-octet value
(nonce) used with the cryptographic mechanism that implements (nonce) used with the cryptographic mechanism that implements
packet protection and allows for the provision of semantic packet protection and allows for the provision of semantic
security. security.
skipping to change at page 46, line 28 skipping to change at page 48, line 28
Option Type: 0x02 (to be confirmed by IANA) Option Type: 0x02 (to be confirmed by IANA)
Option Length: The Option Length field contains the length in octets Option Length: The Option Length field contains the length in octets
of the Metric Data. of the Metric Data.
Metric Data: The order, content, and coding of the Metric Container Metric Data: The order, content, and coding of the Metric Container
data is as specified in [I-D.ietf-roll-routing-metrics]. data is as specified in [I-D.ietf-roll-routing-metrics].
6.7.5. Route Information 6.7.5. Route Information
The Route Information option MAY be present in DIO messages, and is The Route Information option MAY be present in DIO messages, and
equivalent in function to the IPv6 Neighbor Discovery (ND) Route carries the same information as the IPv6 Neighbor Discovery (ND)
Information option as defined in [RFC4191]. The format of the option Route Information option as defined in [RFC4191]. The root of a
is modified slightly (Type, Length, Prefix) in order to be carried as DODAG is authoritative for setting that information and the
a RPL option as follows: information is unchanged as propagated down the DODAG. A RPL router
may trivially transform it back into a ND option to advertise in its
own RAs so a node attached to the RPL router will end up using the
DODAG for which the root has the best preference for the destination
of a packet. In addition to the existing ND semantics, it is
possible for an Objective function to use this information to favor a
DODAG which root is most preferred for a specific destination. The
format of the option is modified slightly (Type, Length, Prefix) in
order to be carried as a RPL option as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd| | Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime | | Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Prefix (Variable Length) . . Prefix (Variable Length) .
skipping to change at page 49, line 32 skipping to change at page 51, line 49
DIORedundancyConstant: 8-bit unsigned integer used to configure k of DIORedundancyConstant: 8-bit unsigned integer used to configure k of
the DIO trickle timer (see Section 8.3.1). The default value the DIO trickle timer (see Section 8.3.1). The default value
of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT.
MaxRankIncrease: 16-bit unsigned integer used to configure MaxRankIncrease: 16-bit unsigned integer used to configure
DAGMaxRankIncrease, the allowable increase in rank in support DAGMaxRankIncrease, the allowable increase in rank in support
of local repair. If DAGMaxRankIncrease is 0 then this of local repair. If DAGMaxRankIncrease is 0 then this
mechanism is disabled. mechanism is disabled.
MinHopRankInc 16-bit unsigned integer used to configure MinHopRankInc 16-bit unsigned integer used to configure
MinHopRankIncrease as described in Section 3.6.1. The default MinHopRankIncrease as described in Section 3.5.1. The default
value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE. value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE.
Default Lifetime: 8-bit unsigned integer. This is the lifetime that Default Lifetime: 8-bit unsigned integer. This is the lifetime that
is used as default for all RPL routes. It is expressed in is used as default for all RPL routes. It is expressed in
units of Lifetime Units, e.g. the default lifetime in seconds units of Lifetime Units, e.g. the default lifetime in seconds
is (Default Lifetime) * (Lifetime Unit). is (Default Lifetime) * (Lifetime Unit).
Lifetime Unit: 16-bit unsigned integer. Provides the unit in Lifetime Unit: 16-bit unsigned integer. Provides the unit in
seconds that is used to express route lifetimes in RPL. For seconds that is used to express route lifetimes in RPL. For
very stable networks, it can be hours to days. very stable networks, it can be hours to days.
skipping to change at page 50, line 31 skipping to change at page 52, line 48
DODAG. In a DAO, the RPL Target option indicates reachability. DODAG. In a DAO, the RPL Target option indicates reachability.
A RPL Target Option May optionally be paired with a RPL Target A RPL Target Option May optionally be paired with a RPL Target
Descriptor Option (Figure 30) that qualifies the target. Descriptor Option (Figure 30) that qualifies the target.
A set of one or more Transit Information options (Section 6.7.8) MAY A set of one or more Transit Information options (Section 6.7.8) MAY
directly follow a set of one or more Target option in a DAO message directly follow a set of one or more Target option in a DAO message
(where each Target Option MAY be paired with a RPL Target Descriptor (where each Target Option MAY be paired with a RPL Target Descriptor
Option as above). The structure of the DAO message, detailing how Option as above). The structure of the DAO message, detailing how
Target options are used in conjunction with Transit Information Target options are used in conjunction with Transit Information
options, is further described in Section 9.6. options, is further described in Section 9.4.
The RPL Target option may be repeated as necessary to indicate The RPL Target option may be repeated as necessary to indicate
multiple targets. multiple targets.
Option Type: 0x05 (to be confirmed by IANA) Option Type: 0x05 (to be confirmed by IANA)
Option Length: Variable, length of the option in octets excluding Option Length: Variable, length of the option in octets excluding
the Type and Length fields. the Type and Length fields.
Flags: 8-bit unused field reserved for flags. The field MUST be Flags: 8-bit unused field reserved for flags. The field MUST be
skipping to change at page 52, line 14 skipping to change at page 54, line 31
parents in order to signal a preference among parents. That parents in order to signal a preference among parents. That
preference may influence the decision of the DODAG root when preference may influence the decision of the DODAG root when
selecting among the alternate parents/paths for constructing downward selecting among the alternate parents/paths for constructing downward
routes. routes.
One or more Transit Information options MUST be preceded by one or One or more Transit Information options MUST be preceded by one or
more RPL Target options. In this manner the RPL Target option more RPL Target options. In this manner the RPL Target option
indicates the child node, and the Transit Information option(s) indicates the child node, and the Transit Information option(s)
enumerate the DODAG parents. The structure of the DAO message, enumerate the DODAG parents. The structure of the DAO message,
further detailing how Target options are used in conjunction with further detailing how Target options are used in conjunction with
Transit Information options, is further described in Section 9.6. Transit Information options, is further described in Section 9.4.
A typical non-storing node will use multiple Transit Information A typical non-storing node will use multiple Transit Information
options, and it will send the DAO message thus formed directly to the options, and it will send the DAO message thus formed directly to the
root. A typical storing node will use one Transit Information option root. A typical storing node will use one Transit Information option
with no parent field, and will send the DAO message thus formed, with with no parent field, and will send the DAO message thus formed, with
additional adjustments to Path Control as detailed later, to one or additional adjustments to Path Control as detailed later, to one or
multiple parents. multiple parents.
For example, in a non-storing mode of operation let Tgt(T) denote a For example, in a non-storing mode of operation let Tgt(T) denote a
Target option for a target T. Let Trnst(P) denote a Transit Target option for a target T. Let Trnst(P) denote a Transit
skipping to change at page 55, line 48 skipping to change at page 58, line 14
DODAGID: 128-bit unsigned integer containing the DODAGID that is DODAGID: 128-bit unsigned integer containing the DODAGID that is
being solicited when valid. being solicited when valid.
Unassigned bits of the Solicited Information option are reserved. Unassigned bits of the Solicited Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on They MUST be set to zero on transmission and MUST be ignored on
reception. reception.
6.7.10. Prefix Information 6.7.10. Prefix Information
The Prefix Information option MAY be present in DIO messages, and is The Prefix Information option MAY be present in DIO messages, and
equivalent in function to the IPv6 ND Prefix Information option as carries the equivalent information for the purpose of configuring RPL
defined in [RFC4861]. The format of the option is modified slightly routers as the IPv6 ND Prefix Information option defined in
(Type, Length, Prefix) in order to be carried as a RPL option as [RFC4861]. In particular, a RPL router may use this option to
follows: autoconfigure an address from a parent prefix as specified in
[RFC4862] and advertise its own address as specified in [RFC3775].
The root of a DODAG is authoritative for setting that information and
the information is unchanged as propagated down the DODAG but for the
suffix of the address of the parent that can be included in the
prefix. A RPL router may trivially transform a RPL PIO that it
advertises in PIO messages back into a ND option to place in RAs so a
node attached to the RPL router can also use it for all ND purposes
including address autoconfiguration. The format of the option is
modified slightly (Type, Length, Prefix) in order to be carried as a
RPL option as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| | Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime | | Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 63, line 14 skipping to change at page 65, line 14
8. Upward Routes 8. Upward Routes
This section describes how RPL discovers and maintains upward routes. This section describes how RPL discovers and maintains upward routes.
It describes the use of DODAG Information Objects (DIOs), the It describes the use of DODAG Information Objects (DIOs), the
messages used to discover and maintain these routes. It specifies messages used to discover and maintain these routes. It specifies
how RPL generates and responds to DIOs. It also describes DODAG how RPL generates and responds to DIOs. It also describes DODAG
Information Solicitation (DIS) messages, which are used to trigger Information Solicitation (DIS) messages, which are used to trigger
DIO transmissions. DIO transmissions.
As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST
provision at least one DODAG parent as a default route for the
associated instance. This default route enables a packet to be
forwarded upwards until it eventually hits a common ancestor from
which it will be routed downwards to the destination. If the
destination is not in the DODAG, then the DODAG root may be able to
forward the packet using connectivity to the outside of the DODAG; if
it can not forward the packet outside then the DODAG root has to drop
it.
A DIO message can also transport explicit routing information:
DODAGID The DODAGID is a Global or Unique Local IPv6 Address of the
root. A node that joins a DODAG SHOULD provision a host route
via a DODAG parent to the address used by the root as DODAGID.
RIO Prefix The root MAY place one or more Route Information options
in a DIO message. The RIO is used to advertise an external
route that is reachable via the root, associated with a
preference, as presented in Section 6.7.5, which incorporates
the RIO from [RFC4191]. It is interpreted as a capability of
the root as opposed to a routing advertisement and it MUST NOT
be redistributed in another routing protocol though it SHOULD
be used by an ingress RPL router to select a DODAG when a
packet is injected in a RPL domain from a node attached to that
RPL router. An Objective Function MAY use the routes
advertised in RIO or the preference for those routes in order
to favor a DODAG versus another one for a same instance.
8.1. DIO Base Rules 8.1. DIO Base Rules
1. For the following DIO Base fields, a node that is not a DODAG 1. For the following DIO Base fields, a node that is not a DODAG
root MUST advertise the same values as its preferred DODAG parent root MUST advertise the same values as its preferred DODAG parent
(defined in Section 8.2.1). In this way these values will (defined in Section 8.2.1). In this way these values will
propagate Down the DODAG unchanged and advertised by every node propagate Down the DODAG unchanged and advertised by every node
that has a route to that DODAG root. These fields are: that has a route to that DODAG root. These fields are:
1. Grounded (G) 1. Grounded (G)
2. Mode of Operation (MOP) 2. Mode of Operation (MOP)
3. DAGPreference (Prf) 3. DAGPreference (Prf)
skipping to change at page 68, line 38 skipping to change at page 71, line 22
8.2.2.5. Poisoning 8.2.2.5. Poisoning
1. A node poisons routes by advertising a Rank of INFINITE_RANK. 1. A node poisons routes by advertising a Rank of INFINITE_RANK.
2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
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 IPv6 Hop-by-Hop RPL Option ([I-D.ietf-6man-rpl-option]) whose RPL Packet Information includes a Rank that is not
includes a Rank that is not INFINITE_RANK, yet still advertise INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs.
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 why 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
skipping to change at page 76, line 39 skipping to change at page 79, line 39
6. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST 6. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST
NOT process them further. NOT process them further.
Unlike the Version field of a DIO, which is incremented only by a Unlike the Version field of a DIO, which is incremented only by a
DODAG Root and repeated unchanged by other nodes, DAOSequence values DODAG Root and repeated unchanged by other nodes, DAOSequence values
are unique to each node. The sequence number space for unicast and are unique to each node. The sequence number space for unicast and
multicast DAO messages can be either the same or distinct. It is multicast DAO messages can be either the same or distinct. It is
RECOMMENDED to use the same sequence number space. RECOMMENDED to use the same sequence number space.
9.4. DAO Transmission Scheduling 9.4. Structure of DAO Messages
Because DAOs flow upwards, receiving a unicast DAO can trigger
sending a unicast DAO to a DAO parent.
1. On receiving a unicast DAO message with updated information, such
as containing a Transit Information option with a new Path
Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO
message immediately. It SHOULD delay sending the DAO message in
order to aggregate DAO information from other nodes for which it
is a DAO parent.
2. A node SHOULD delay sending a DAO message with a timer
(DelayDAO). Receiving a DAO message starts the DelayDAO timer.
DAO messages received while the DelayDAO timer is active do not
reset the timer. When the DelayDAO timer expires, the node sends
a DAO.
3. When a node adds a node to its DAO parent set, it SHOULD schedule
a DAO message transmission.
DelayDAO's value and calculation is implementation-dependent. A
default value of DEFAULT_DAO_DELAY is defined in this specification.
9.5. Triggering DAO Messages
Nodes can trigger their sub-DODAG to send DAO messages. Each node
maintains a DAO Trigger Sequence Number (DTSN), which it communicates
through DIO messages.
1. If a node hears one of its DAO parents increment its DTSN, the
node MUST schedule a DAO message transmission using rules in
Section 9.3 and Section 9.4.
2. In non-storing mode, if a node hears one of its DAO parents
increment its DTSN, the node MUST increment its own DTSN.
In a storing mode of operation, as part of routine routing table
updates and maintenance, a storing node MAY increment DTSN in order
to reliably trigger a set of DAO updates from its immediate children.
In a storing mode of operation it is not necessary to trigger DAO
updates from the entire sub-DODAG, since that state information will
propagate hop-by-hop Up the DODAG.
In a non-storing mode of operation, a DTSN increment will also cause
the immediate children of a node to increment their DTSN in turn,
triggering a set of DAO updates from the entire sub-DODAG. In a non-
storing mode of operation typically only the root would independently
increment the DTSN when a DAO refresh is needed but a global repair
(such as by incrementing DODAGVersionNumber) is not desired. In a
non-storing mode of operation typically all non-root nodes would
increment their DTSN only when their parent(s) are observed to do so.
In the general, a node may trigger DAO updates according to
implementation specific logic, such as based on the detection of a
downward route inconsistency or occasionally based upon an internal
timer.
In the case of triggered DAOs, selecting a proper DAODelay can
greatly reduce the number of DAOs transmitted. The trigger flows
Down the DODAG; in the best case the DAOs flow Up the DODAG such that
leaves send DAOs first, with each node sending a DAO message only
once. Such a scheduling could be approximated by setting DAODelay
inversely proportional to Rank. Note that this suggestion is
intended as an optimization to allow efficient aggregation (it is not
required for correct operation in the general case).
9.6. Structure of DAO Messages
DAOs follow a common structure in both storing and non-storing DAOs follow a common structure in both storing and non-storing
networks. In the most general form, a DAO message may include networks. In the most general form, a DAO message may include
several groups of options, where each group consists of one or more several groups of options, where each group consists of one or more
Target options followed by one or more Transit Information options. Target options followed by one or more Transit Information options.
The entire group of Transit Information options applies to the entire The entire group of Transit Information options applies to the entire
group of Target options. Later sections describe further details for group of Target options. Later sections describe further details for
each mode of operation. each mode of operation.
1. RPL nodes MUST include one or more RPL Target Options in each DAO 1. RPL nodes MUST include one or more RPL Target Options in each DAO
skipping to change at page 79, line 27 skipping to change at page 81, line 8
4. A router might have targets that are not known to be onlink for a 4. A router might have targets that are not known to be onlink for a
parent, either because they are addresses located on an alternate parent, either because they are addresses located on an alternate
interface or because they belong to nodes that are external to interface or because they belong to nodes that are external to
RPL, for instance connected hosts. In order to inject such a RPL, for instance connected hosts. In order to inject such a
target in the RPL network, the router MUST advertise itself as target in the RPL network, the router MUST advertise itself as
the Parent Address in the Transit Information option for that the Parent Address in the Transit Information option for that
target, using an address that is onlink for that nodes DAO target, using an address that is onlink for that nodes DAO
parent. If the target belongs to an external node then the parent. If the target belongs to an external node then the
router MUST set the External 'E' flag in the transit information. router MUST set the External 'E' flag in the transit information.
9.5. DAO Transmission Scheduling
Because DAOs flow upwards, receiving a unicast DAO can trigger
sending a unicast DAO to a DAO parent.
1. On receiving a unicast DAO message with updated information, such
as containing a Transit Information option with a new Path
Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO
message immediately. It SHOULD delay sending the DAO message in
order to aggregate DAO information from other nodes for which it
is a DAO parent.
2. A node SHOULD delay sending a DAO message with a timer
(DelayDAO). Receiving a DAO message starts the DelayDAO timer.
DAO messages received while the DelayDAO timer is active do not
reset the timer. When the DelayDAO timer expires, the node sends
a DAO.
3. When a node adds a node to its DAO parent set, it SHOULD schedule
a DAO message transmission.
DelayDAO's value and calculation is implementation-dependent. A
default value of DEFAULT_DAO_DELAY is defined in this specification.
9.6. Triggering DAO Messages
Nodes can trigger their sub-DODAG to send DAO messages. Each node
maintains a DAO Trigger Sequence Number (DTSN), which it communicates
through DIO messages.
1. If a node hears one of its DAO parents increment its DTSN, the
node MUST schedule a DAO message transmission using rules in
Section 9.3 and Section 9.5.
2. In non-storing mode, if a node hears one of its DAO parents
increment its DTSN, the node MUST increment its own DTSN.
In a storing mode of operation, as part of routine routing table
updates and maintenance, a storing node MAY increment DTSN in order
to reliably trigger a set of DAO updates from its immediate children.
In a storing mode of operation it is not necessary to trigger DAO
updates from the entire sub-DODAG, since that state information will
propagate hop-by-hop Up the DODAG.
In a non-storing mode of operation, a DTSN increment will also cause
the immediate children of a node to increment their DTSN in turn,
triggering a set of DAO updates from the entire sub-DODAG. In a non-
storing mode of operation typically only the root would independently
increment the DTSN when a DAO refresh is needed but a global repair
(such as by incrementing DODAGVersionNumber) is not desired. In a
non-storing mode of operation typically all non-root nodes would
increment their DTSN only when their parent(s) are observed to do so.
In the general, a node may trigger DAO updates according to
implementation specific logic, such as based on the detection of a
downward route inconsistency or occasionally based upon an internal
timer.
In the case of triggered DAOs, selecting a proper DAODelay can
greatly reduce the number of DAOs transmitted. The trigger flows
Down the DODAG; in the best case the DAOs flow Up the DODAG such that
leaves send DAOs first, with each node sending a DAO message only
once. Such a scheduling could be approximated by setting DAODelay
inversely proportional to Rank. Note that this suggestion is
intended as an optimization to allow efficient aggregation (it is not
required for correct operation in the general case).
9.7. Non-storing Mode 9.7. Non-storing Mode
In non-storing mode, RPL routes messages downward using IP source In non-storing mode, RPL routes messages downward using IP source
routing. The following rule applies to nodes that are in non-storing routing. The following rule applies to nodes that are in non-storing
mode. Storing mode has a separate set of rules, described in mode. Storing mode has a separate set of rules, described in
Section 9.8. Section 9.8.
1. The Parent Address field of a Transit Information Option MUST 1. The Parent Address field of a Transit Information Option MUST
contain one or more addresses. All of these addresses MUST be contain one or more addresses. All of these addresses MUST be
addresses of DAO parents of the sender. addresses of DAO parents of the sender.
skipping to change at page 80, line 27 skipping to change at page 83, line 27
1. The Parent Address field of a Transmit Information option MUST be 1. The Parent Address field of a Transmit Information option MUST be
empty. empty.
2. On receiving a unicast DAO, a node MUST compute if the DAO would 2. On receiving a unicast DAO, a node MUST compute if the DAO would
change the set of prefixes that the node itself advertises. This change the set of prefixes that the node itself advertises. This
computation SHOULD include consultation of the Path Sequence computation SHOULD include consultation of the Path Sequence
information in the Transit Information options associated with information in the Transit Information options associated with
the DAO, to determine if the DAO message contains newer the DAO, to determine if the DAO message contains newer
information that supersedes the information already stored at the information that supersedes the information already stored at the
node. If so, the node MUST generate a new DAO message and node. If so, the node MUST generate a new DAO message and
transmit it, following the rules in Section 9.4. Such a change transmit it, following the rules in Section 9.5. Such a change
includes receiving a No-Path DAO. includes receiving a No-Path DAO.
3. When a node generates a new DAO, it SHOULD unicast it to each of 3. When a node generates a new DAO, it SHOULD unicast it to each of
its DAO parents. It MUST NOT unicast the DAO message to nodes its DAO parents. It MUST NOT unicast the DAO message to nodes
that are not DAO parents. that are not DAO parents.
4. When a node removes a node from its DAO parent set, it SHOULD 4. When a node removes a node from its DAO parent set, it SHOULD
send a No-Path DAO message (Section 6.4.3) to that removed DAO send a No-Path DAO message (Section 6.4.3) to that removed DAO
parent to invalidate the existing route. parent to invalidate the existing route.
skipping to change at page 92, line 14 skipping to change at page 95, line 14
processing. If the transmit time is too far in the past or future processing. If the transmit time is too far in the past or future
compared to the local time on the receiver, it MAY discard the compared to the local time on the receiver, it MAY discard the
message without further processing. message without further processing.
10.8. Coverage of Integrity and Confidentiality 10.8. Coverage of Integrity and Confidentiality
For a RPL ICMPv6 message, the entire packet is within the scope of For a RPL ICMPv6 message, the entire packet is within the scope of
RPL security. RPL security.
Message authentication codes (MAC) and signatures are calculated over Message authentication codes (MAC) and signatures are calculated over
the entire IPv6 packet. When computing MACs and signatures, mutable the entire unsecured IPv6 packet. When computing MACs and
IPv6 fields are considered to be filled with zeroes, following the signatures, mutable IPv6 fields are considered to be filled with
rules in Section 3.3.3.1 of [RFC4302] (IPSec Authenticated Header). zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec
MAC and signature calculations are performed before any compression Authenticated Header). MAC and signature calculations are performed
that lower layers may apply. before any compression that lower layers may apply.
When a RPL ICMPv6 message is encrypted, encryption starts at the When a RPL ICMPv6 message is encrypted, encryption starts at the
first byte after the security section and continues to the last byte first byte after the security section and continues to the last byte
of the packet. The IPv6 header, ICMPv6 header, and RPL message up to of the packet. The IPv6 header, ICMPv6 header, and RPL message up to
the end of the security section are not encrypted, as they are needed the end of the security section are not encrypted, as they are needed
to correctly decrypt the packet. to correctly decrypt the packet.
For example, a node sending a message with LVL=5, KIM=0, and For example, a node sending a message with LVL=5, KIM=0, and
Algorithm=0 uses the CCM algorithm[RFC3610] to create a packet with Algorithm=0 uses the CCM algorithm[RFC3610] to create a packet with
attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit
skipping to change at page 93, line 44 skipping to change at page 96, line 44
most-significant-bit first order. most-significant-bit first order.
10.9.2. Signatures 10.9.2. Signatures
If the Key Identification Mode (KIM) mode indicates the use of If the Key Identification Mode (KIM) mode indicates the use of
signatures (a value of 3), then a node appends a signature to the signatures (a value of 3), then a node appends a signature to the
data payload of the packet. The Security Level (LVL) field describes data payload of the packet. The Security Level (LVL) field describes
the length of this signature. the length of this signature.
The signature scheme in RPL for Security Mode 3 is an instantiation The signature scheme in RPL for Security Mode 3 is an instantiation
of the RSA algorithm [RFC3447]. It uses as public key the pair of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of
(n,e), where n is a 3072-bit RSA modulus and where e=2^{16}+1. It [RFC3447]. It uses as public key the pair (n,e), where n is a 3072-
uses CCM mode[RFC3610] as the encryption scheme with M=0 (as a bit RSA modulus and where e=2^{16}+1. It uses CCM mode[RFC3610] as
stream-cipher). It uses the SHA-256 hash function specified in the encryption scheme with M=0 (as a stream-cipher). It uses the
Section 6.2 of [SHA2]. It uses the message encoding rule of SHA-256 hash function specified in Section 6.2 of [FIPS180]. It uses
[RFC3447]. the message encoding rules of Section 8.1 of [RFC3447].
Let 'a' be a concatenation of a six-byte representation of Counter Let 'a' be a concatenation of a six-byte representation of Counter
and the message header. The packet payload is the right- and the message header. The packet payload is the right-
concatenation of packet data 'm' and the signature 's'. This concatenation of packet data 'm' and the signature 's'. This
signature scheme is invoked with the right-concatenation of the signature scheme is invoked with the right-concatenation of the
message parts a and m, whereas the signature verification is invoked message parts a and m, whereas the signature verification is invoked
with the right-concatenation of the message parts a and m, and with with the right-concatenation of the message parts a and m, and with
signature s. signature s.
RSA signatures of this form provide sufficient protection for RPL RSA signatures of this form provide sufficient protection for RPL
skipping to change at page 95, line 35 skipping to change at page 98, 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.19). Section 19.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 96, line 34 skipping to change at page 99, line 34
destination. destination.
11.2. Loop Avoidance and Detection 11.2. Loop Avoidance and Detection
RPL loop avoidance mechanisms are kept simple and designed to RPL loop avoidance mechanisms are kept simple and designed to
minimize churn and states. Loops may form for a number of reasons, minimize churn and states. Loops may form for a number of reasons,
e.g. control packet loss. RPL includes a reactive loop detection e.g. control packet loss. RPL includes a reactive loop detection
technique that protects from meltdown and triggers repair of broken technique that protects from meltdown and triggers repair of broken
paths. paths.
RPL loop detection uses information that contained within the data RPL loop detection uses RPL Packet Information that is transported
packet using the RPL Option [I-D.ietf-6man-rpl-option]) in an IPv6 within the data packets, relying on an external mechanism such as
Hop-by-Hop Option header. The RPL Option contains RPL Packet [I-D.ietf-6man-rpl-option] that places in the RPL Packet Information
Information as defined below, and [I-D.ietf-6man-rpl-option] defines in an IPv6 Hop-by-Hop Option header.
the details of how that RPL Packet Information is carried within the
RPL Option. Future companion specifications may detail alternate
ways to carry this information.
The content of RPL Packet Information is defined as follows: The content of RPL Packet Information is defined as follows:
Down 'O': 1-bit flag indicating whether the packet is expected to Down 'O': 1-bit flag indicating whether the packet is expected to
progress Up or Down. A router sets the 'O' flag when the progress Up or Down. A router sets the 'O' flag when the
packet is expected to progress Down (using DAO routes), and packet is expected to progress Down (using DAO routes), and
clears it when forwarding toward the DODAG root (to a node with clears it when forwarding toward the DODAG root (to a node with
a lower rank). A host or RPL leaf node MUST set the 'O' flag a lower rank). A host or RPL leaf node MUST set the 'O' flag
to 0. to 0.
skipping to change at page 97, line 35 skipping to change at page 100, line 30
packet, then it MUST set the RPLInstanceID field associated with the packet, then it MUST set the RPLInstanceID field associated with the
packet accordingly, otherwise it MUST set it to the packet accordingly, otherwise it MUST set it to the
RPL_DEFAULT_INSTANCE. RPL_DEFAULT_INSTANCE.
11.2.2. Router Operation 11.2.2. Router Operation
11.2.2.1. Instance Forwarding 11.2.2.1. Instance Forwarding
The RPLInstanceID is associated by the source with the packet. This The RPLInstanceID is associated by the source with the packet. This
RPLInstanceID MUST match the RPL Instance onto which the packet is RPLInstanceID MUST match the RPL Instance onto which the packet is
placed by any node, be it a host or router. placed by any node, be it a host or router. The RPLInstanceID is
part of the RPL Packet Information.
A RPL router that forwards a packet in the RPL network MUST check if A RPL router that forwards a packet in the RPL network MUST check if
the packet includes an IPv6 Hop-by-Hop RPL Option, and that the RPL the packet includes the RPL Packet Information. If not, then the RPL
Option contains RPL Packet Information (Section 11.2). If not, then router MUST insert a RPL Packet Information. If the router is an
the RPL router MUST insert a RPL Option with RPL Packet Information
as specified in [I-D.ietf-6man-rpl-option]. If the router is an
ingress router that injects the packet into the RPL network, the ingress router that injects the packet into the RPL network, the
router MUST set the RPLInstanceID field in the RPL Packet router MUST set the RPLInstanceID field in the RPL Packet
Information. The details of how that router determines the mapping Information. The details of how that router determines the mapping
to a RPLInstanceID are out of scope for this specification and left to a RPLInstanceID are out of scope for this specification and left
to future specification. to future specification.
A router that forwards a packet to outside the RPL network MUST A router that forwards a packet to outside the RPL network MUST
remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. remove the RPL Packet Information.
When a router receives a packet that specifies a given RPLInstanceID When a router receives a packet that specifies a given RPLInstanceID
and the node can forward the packet along the DODAG associated to and the node can forward the packet along the DODAG associated to
that instance, then the router MUST do so and leave the RPLInstanceID that instance, then the router MUST do so and leave the RPLInstanceID
value unchanged. value unchanged.
If any node can not forward a packet along the DODAG associated to If any node can not forward a packet along the DODAG associated to
the RPLInstanceID, then the node SHOULD discard the packet and send the RPLInstanceID, then the node SHOULD discard the packet and send
an ICMP error message. an ICMP error message.
skipping to change at page 100, line 13 skipping to change at page 103, line 13
neighbor will be cleaned up as well. neighbor will be cleaned up as well.
12. Multicast Operation 12. Multicast Operation
This section describes further the multicast routing operations over This section describes further the multicast routing operations over
an IPv6 RPL network, and specifically how unicast DAOs can be used to an IPv6 RPL network, and specifically how unicast DAOs can be used to
relay group registrations up. Wherever the following text mentions relay group registrations up. Wherever the following text mentions
Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or
MLDv2 ([RFC3810]). MLDv2 ([RFC3810]).
RPL provides a trivial mapping between MLD queries and RPL DAOs by
transporting a multicast group in a DAO target option. The mapping
excludes the support of source specific filters that are not defined
in DAO options. The mapping enables to proxy a multicast
registration from a non-RPL node attached to a RPL router up to the
root of the DODAG, which can act as a multicast router as if the
listeners were directly attached to it.
Nodes that support the RPL storing mode of operation SHOULD also Nodes that support the RPL storing mode of operation SHOULD also
support multicast DAO operations as described below. Nodes that only support multicast DAO operations as described below. Nodes that only
support the non-storing mode of operation are not expected to support support the non-storing mode of operation are not expected to support
this section. this section.
The multicast operation is controlled by the MOP field in the DIO. The multicast operation is controlled by the MOP field in the DIO.
If the MOP field requires multicast support, then a node that If the MOP field requires multicast support, then a node that
joins the RPL network as a router must operate as described in joins the RPL network as a router must operate as described in
this section for multicast signaling and forwarding within the RPL this section for multicast signaling and forwarding within the RPL
network. A node that does not support the multicast operation network. A node that does not support the multicast operation
required by the MOP field can only join as a leaf. required by the MOP field can only join as a leaf.
If the MOP field does not require multicast support, then If the MOP field does not require multicast support, then
multicast is handled by some other way that is out of scope for multicast is handled by some other way that is out of scope for
this specification. (Examples may include a series of unicast this specification. (Examples may include a series of unicast
copies or limited-scope flooding). copies or limited-scope flooding).
As is traditional, a listener uses a protocol such as MLD with a As is traditional, a listener that is not a RPL node uses a protocol
router to register to a multicast group. such as MLD with a router to register to a multicast group. If the
listener is attached to a RPL router and multicast support is
enabled, then the RPL router maps the MLD query into a RPL DAO
message. A listener that is a RPL node uses a listener registration
DAO message right away.
Along the path between the router and the DODAG root, MLD requests Along the path between the router and the DODAG root, MLD requests
are mapped and transported as DAO messages within RPL; each hop are transported as DAO messages within RPL; each hop coalesces the
coalesces the multiple requests for a same group as a single DAO multiple requests for a same group as a single DAO message to the
message to the parent(s), in a fashion similar to proxy IGMP, but parent(s), in a fashion similar to proxy IGMP, but recursively
recursively between child router and parent Up to the DODAG root. between child router and parent Up to the DODAG root.
A router might select to pass a listener registration DAO message to A router might select to pass a listener registration DAO message to
its preferred parent only, in which case multicast packets coming its preferred parent only, in which case multicast packets coming
back might be lost for all of its sub-DODAG if the transmission fails back might be lost for all of its sub-DODAG if the transmission fails
over that link. Alternatively the router might select to copy over that link. Alternatively the router might select to copy
additional parents as it would do for DAO messages advertising additional parents as it would do for DAO messages advertising
unicast destinations, in which case there might be duplicates that unicast destinations, in which case there might be duplicates that
the router will need to prune. the router will need to prune.
As a result, multicast routing states are installed in each router on As a result, multicast routing states are installed in each router on
skipping to change at page 102, line 14 skipping to change at page 105, line 14
13. Maintenance of Routing Adjacency 13. Maintenance of Routing Adjacency
The selection of successors, along the default paths Up along the The selection of successors, along the default paths Up along the
DODAG, or along the paths learned from destination advertisements DODAG, or along the paths learned from destination advertisements
Down along the DODAG, leads to the formation of routing adjacencies Down along the DODAG, leads to the formation of routing adjacencies
that require maintenance. that require maintenance.
In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance of In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance of
a routing adjacency involves the use of Keepalive mechanisms (Hellos) a routing adjacency involves the use of Keepalive mechanisms (Hellos)
or other protocols such as BFD ([RFC5880]) and MANET Neighborhood or other protocols such as the Bidirectional Forwarding Detection
Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]). Unfortunately, such [RFC5881] (BFD) and the MANET Neighborhood Discovery Protocol
an approach is not desirable in constrained environments such as LLN [I-D.ietf-manet-nhdp](NHDP) . Unfortunately, such a proactive
and would lead to excessive control traffic in light of the data approach is often not desirable in constrained environments where it
traffic with a negative impact on both link loads and nodes would lead to excessive control traffic in light of the data traffic
resources. Overhead to maintain the routing adjacency should be with a negative impact on both link loads and nodes resources.
minimized. Furthermore, it is not always possible to rely on the
link or transport layer to provide information of the associated link
state. The network layer needs to fall back on its own mechanism.
By contrast with several other routing protocols, RPL does not define By contrast with those routing protocols, RPL does not define any
any 'keep-alive' mechanisms to detect routing adjacency failure: this 'keep-alive' mechanisms to detect routing adjacency failures: this is
is in most cases, because such a mechanism may be too expensive in because in many cases such a mechanism would be too expensive in
terms of bandwidth and even more importantly energy (a battery terms of bandwidth and even more importantly energy (a battery
operated device could not afford to send periodic Keep alive). Still operated device could not afford to send periodic Keep alive). Still
RPL requires mechanisms to detect that a neighbor is no longer RPL requires an external mechanisms to detect that a neighbor is no
reachable: this can be performed by using mechanisms such as Neighbor longer reachable. Such a mechanism should preferably be reactive to
Unreachability Detection as defined in [RFC4861] or even some form of traffic in order to minimize the overhead to maintain the routing
Keep-alive that are outside of this document. adjacency and focus on links that are actually being used.
Example reactive mechanisms that can be used include:
The Neighbor Unreachability Detection [RFC4861] mechanism.
Layer 2 triggers [RFC5184] derived from events such as association
states and L2 acknowledgements.
14. Guidelines for Objective Functions 14. Guidelines for Objective Functions
An Objective Function (OF), in conjunction with routing metrics and An Objective Function (OF), in conjunction with routing metrics and
constraints, allows for the selection of a DODAG to join, and a constraints, allows for the selection of a DODAG to join, and a
number of peers in that DODAG as parents. The OF is used to compute number of peers in that DODAG as parents. The OF is used to compute
an ordered list of parents. The OF is also responsible to compute an ordered list of parents. The OF is also responsible to compute
the rank of the device within the DODAG Version. the rank of the device within the DODAG Version.
The Objective Function is indicated in the DIO message using an The Objective Function is indicated in the DIO message using an
skipping to change at page 107, line 6 skipping to change at page 110, line 6
DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This
configuration is a conservative value for trickle suppression configuration is a conservative value for trickle suppression
mechanism. mechanism.
DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of
MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value
of 256. This configuration results in an 8-bit wide integer of 256. This configuration results in an 8-bit wide integer
part of Rank. part of Rank.
DEFAULT_DAO_DELAY This is the default value for the DelayDAO Timer. DEFAULT_DAO_DELAY This is the default value for the DelayDAO Timer.
DEFAULT_DAO_DELAY has value of 1 second. See Section 9.4. DEFAULT_DAO_DELAY has value of 1 second. See Section 9.5.
DIO Timer One instance per DODAG that a node is a member of. Expiry DIO Timer One instance per DODAG that a node is a member of. Expiry
triggers DIO message transmission. Trickle timer with variable triggers DIO message transmission. Trickle timer with variable
interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See
Section 8.3.1 Section 8.3.1
DAG Version Increment Timer Up to one instance per DODAG that the DAG Version Increment Timer Up to one instance per DODAG that the
node is acting as DODAG root of. May not be supported in all node is acting as DODAG root of. May not be supported in all
implementations. Expiry triggers increment of implementations. Expiry triggers increment of
DODAGVersionNumber, causing a new series of updated DIO message DODAGVersionNumber, causing a new series of updated DIO message
to be sent. Interval should be chosen appropriate to to be sent. Interval should be chosen appropriate to
propagation time of DODAG and as appropriate to application propagation time of DODAG and as appropriate to application
requirements (e.g. response time vs. overhead). requirements (e.g. response time vs. overhead).
DelayDAO Timer Up to one timer per DAO parent (the subset of DODAG DelayDAO Timer Up to one timer per DAO parent (the subset of DODAG
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.4 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 17. 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
skipping to change at page 112, line 35 skipping to change at page 115, line 35
example a battery-operated node may not want to act as a floating example a battery-operated node may not want to act as a floating
DODAG root for a long period of time. Thus a RPL implementation MAY DODAG root for a long period of time. Thus a RPL implementation MAY
support the ability to configure whether or not a node could act as a 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.3.2. triggers a global repair as specified in Section 3.2.2.
17.2.6. Configuration of RPL Parameters related to DAO-based mechanisms 17.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.4, 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
DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring
the DelayDAO timer. the DelayDAO timer.
In a storing mode of operation, a storing node may increment DTSN in In a storing mode of operation, a storing node may increment DTSN in
order to reliably trigger a set of DAO updates from its immediate order to reliably trigger a set of DAO updates from its immediate
children, as part of routine routing table updates and maintenance. children, as part of routine routing table updates and maintenance.
A RPL implementation MAY allow for configuring a set of rules A RPL implementation MAY allow for configuring a set of rules
skipping to change at page 121, line 17 skipping to change at page 124, line 17
18.1. Overview 18.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 neither a power drain; and it cannot always be assumed they have a trusted
trusted computing base nor a high-quality random number generator computing base or a high-quality random number generator aboard.
aboard. Communications cannot rely on the online availability of a Communications cannot rely on the online availability of a fixed
fixed infrastructure and might involve short-term relationships infrastructure and might involve short-term relationships between
between devices that may never have communicated before. These devices that may never have communicated before. These constraints
constraints might severely limit the choice of cryptographic might severely limit the choice of cryptographic algorithms and
algorithms and protocols and influence the design of the security protocols and influence the design of the security architecture
architecture because the establishment and maintenance of trust because the establishment and maintenance of trust relationships
relationships between devices need to be addressed with care. In between devices need to be addressed with care. In addition, battery
addition, battery lifetime and cost constraints put severe limits on lifetime and cost constraints put severe limits on the security
the security overhead these networks can tolerate, something that is overhead these networks can tolerate, something that is of far less
of far less concern with higher bandwidth networks. Most of these concern with higher bandwidth networks. Most of these security
security architectural elements can be implemented at higher layers architectural elements can be implemented at higher layers and may,
and may, therefore, be considered to be out of scope for this therefore, be considered to be out of scope for this specification.
specification. Special care, however, needs to be exercised with Special care, however, needs to be exercised with respect to
respect to interfaces to these higher layers. interfaces to these higher layers.
The security mechanisms in this standard are based on symmetric-key The security mechanisms in this standard are based on symmetric-key
and public-key cryptography and use keys that are to be provided by and public-key cryptography and use keys that are to be provided by
higher layer processes. The establishment and maintenance of these higher layer processes. The establishment and maintenance of these
keys are out of scope for this specification. The mechanisms assume keys are out of scope for this specification. The mechanisms assume
a secure implementation of cryptographic operations and secure and a secure implementation of cryptographic operations and secure and
authentic storage of keying material. authentic storage of keying material.
The security mechanisms specified provide particular combinations of The security mechanisms specified provide particular combinations of
the following security services: the following security services:
skipping to change at page 126, line 30 skipping to change at page 129, line 30
o Value o Value
o Encryption/MAC o Encryption/MAC
o Signature o Signature
o Defining RFC o Defining RFC
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 SHA2 | 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 19.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 the Key Identification Mode 19.8. New Registry for Per-KIM Security Levels
IANA is requested to create a registry for the 3-bit Key
Identification Mode Field.
New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities:
o Value
o Description
o Defining RFC
The following values are currently defined:
+-------+---------------+---------------+
| Value | Description | Reference |
+-------+---------------+---------------+
| 0 | See Figure 11 | This document |
| | | |
| 1 | See Figure 11 | This document |
| | | |
| 2 | See Figure 11 | This document |
| | | |
| 3 | See Figure 11 | This document |
+-------+---------------+---------------+
Key Identification Mode
The rest of the range, decimal 4 to 7, is currently unassigned.
19.9. New Registry for the KIM levels
IANA is requested to create one registry for the 7-bit KIM level IANA is requested to create one registry for the 3-bit Security Level
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
o Description o Description
o Defining RFC o Defining RFC
The following levels pre KIM value are currently defined: The following levels pre KIM value are currently defined:
+-------+-----------+--------------+---------------+ +-------+-----------+---------------+---------------+
| Level | KIM value | Description | Reference | | Level | KIM value | Description | Reference |
+-------+-----------+--------------+---------------+ +-------+-----------+---------------+---------------+
| 0 | 0 | See Figure 9 | This document | | 0 | 0 | See Figure 11 | This document |
| | | | | | | | | |
| 1 | 0 | See Figure 9 | This document | | 1 | 0 | See Figure 11 | This document |
| | | | | | | | | |
| 2 | 0 | See Figure 9 | This document | | 2 | 0 | See Figure 11 | This document |
| | | | | | | | | |
| 3 | 0 | See Figure 9 | This document | | 3 | 0 | See Figure 11 | This document |
| | | | | | | | | |
| 0 | 1 | See Figure 9 | This document | | 0 | 1 | See Figure 11 | This document |
| | | | | | | | | |
| 1 | 1 | See Figure 9 | This document | | 1 | 1 | See Figure 11 | This document |
| | | | | | | | | |
| 2 | 1 | See Figure 9 | This document | | 2 | 1 | See Figure 11 | This document |
| | | | | | | | | |
| 3 | 1 | See Figure 9 | This document | | 3 | 1 | See Figure 11 | This document |
| | | | | | | | | |
| 0 | 2 | See Figure 9 | This document | | 0 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 1 | 2 | See Figure 9 | This document | | 1 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 2 | 2 | See Figure 9 | This document | | 2 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 3 | 2 | See Figure 9 | This document | | 3 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 0 | 3 | See Figure 9 | This document | | 0 | 3 | See Figure 11 | This document |
| | | | | | | | | |
| 1 | 3 | See Figure 9 | This document | | 1 | 3 | See Figure 11 | This document |
+-------+-----------+--------------+---------------+ +-------+-----------+---------------+---------------+
KIM levels Per-KIM Security Levels
19.10. New Registry for the DIS (DODAG Informational Solicitation) 19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags
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
skipping to change at page 129, line 10 skipping to change at page 132, line 4
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.11. New Registry for the DODAG Information Object (DIO) Flags 19.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.12. New Registry for the Destination Advertisement Object (DAO) 19.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 130, line 15 skipping to change at page 133, line 5
+------------+--------------------------+---------------+ +------------+--------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+--------------------------+---------------+ +------------+--------------------------+---------------+
| 0 | DAO-ACK request | This document | | 0 | DAO-ACK request | This document |
| | | | | | | |
| 1 | DODAGID field is present | This document | | 1 | DODAGID field is present | This document |
+------------+--------------------------+---------------+ +------------+--------------------------+---------------+
DAO Base Flags DAO Base Flags
19.13. New Registry for the Destination Advertisement Object (DAO) 19.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 130, line 40 skipping to change at page 133, line 30
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 | This document | | 0 | DODAGID field is present | This document |
+------------+--------------------------+---------------+ +------------+--------------------------+---------------+
DAO-ACK Base Flags DAO-ACK Base Flags
19.14. New Registry for the Consistency Check (CC) Flags 19.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 131, line 16 skipping to change at page 134, line 5
The following bit is currently defined: The following bit is currently defined:
+------------+-------------+---------------+ +------------+-------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-------------+---------------+ +------------+-------------+---------------+
| 0 | CC Response | This document | | 0 | CC Response | This document |
+------------+-------------+---------------+ +------------+-------------+---------------+
Consistency Check Base Flags Consistency Check Base Flags
19.15. New Registry for the DODAG Configuration Option Flags 19.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 131, line 42 skipping to change at page 134, line 31
+------------+------------------------+---------------+ +------------+------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+------------------------+---------------+ +------------+------------------------+---------------+
| 4 | Authentication Enabled | This document | | 4 | Authentication Enabled | This document |
| | | | | | | |
| 5-7 | Path Control Size | This document | | 5-7 | Path Control Size | This document |
+------------+------------------------+---------------+ +------------+------------------------+---------------+
DODAG Configuration Option Flags DODAG Configuration Option Flags
19.16. New Registry for the RPL Target Option Flags 19.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.17. New Registry for the Transit Information Option Flags 19.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 132, line 37 skipping to change at page 135, line 22
The following bits are currently defined: The following bits are currently defined:
+------------+-------------+---------------+ +------------+-------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-------------+---------------+ +------------+-------------+---------------+
| 0 | External | This document | | 0 | External | This document |
+------------+-------------+---------------+ +------------+-------------+---------------+
Transit Information Option Flags Transit Information Option Flags
19.18. New Registry for the Solicited Information Option Flags 19.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 133, line 17 skipping to change at page 136, line 5
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
| 0 | Version Predicate match | This document | | 0 | Version Predicate match | This document |
| | | | | | | |
| 1 | InstanceID Predicate match | This document | | 1 | InstanceID Predicate match | This document |
| | | | | | | |
| 2 | DODAGID Predicate match | This document | | 2 | DODAGID Predicate match | This document |
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
Solicited Information Option Flags Solicited Information Option Flags
19.19. ICMPv6: Error in Source Routing Header 19.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.20. Link-Local Scope multicast address 19.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 20. Acknowledgements
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
skipping to change at page 137, line 11 skipping to change at page 140, line 11
December 2005. December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
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
Address Autoconfiguration", RFC 4862, September 2007.
22.2. Informative References 22.2. Informative References
[FIPS180] National Institute of Standards and Technology, "FIPS Pub
180-3, Secure Hash Standard (SHS)", US Department of
Commerce , February 2008,
<http://www.nist.gov/itl/upload/fips180-3_final.pdf>.
[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-14 (work in progress), July 2010. draft-ietf-manet-nhdp-14 (work in progress), July 2010.
[I-D.ietf-roll-of0] [I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0", Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-03 (work in progress), July 2010. draft-ietf-roll-of0-03 (work in progress), July 2010.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
skipping to change at page 138, line 23 skipping to change at page 141, line 31
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005. June 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007. RFC 4915, June 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, November 2009. RFC 5706, November 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
June 2010.
[SHA2] National Institute of Standards and Technology, "FIPS Pub
180-3, Secure Hash Standard (SHS)", US Department of
Commerce , February 2008,
<http://www.nist.gov/itl/upload/fips180-3_final.pdf>.
Authors' Addresses Authors' Addresses
Tim Winter (editor) Tim Winter (editor)
Email: wintert@acm.org Email: wintert@acm.org
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Village d'Entreprises Green Side Village d'Entreprises Green Side
 End of changes. 103 change blocks. 
547 lines changed or deleted 623 lines changed or added

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