draft-ietf-roll-rpl-11.txt   draft-ietf-roll-rpl-12.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: January 29, 2011 Cisco Systems Expires: April 4, 2011 Cisco Systems
RPL Author Team A. Brandt
IETF ROLL WG Sigma Designs
July 28, 2010 T. Clausen
LIX, Ecole Polytechnique
J. Hui
Arch Rock Corporation
R. Kelsey
Ember Corporation
P. Levis
Stanford University
K. Pister
Dust Networks
R. Struik
JP. Vasseur
Cisco Systems
October 1, 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-11 draft-ietf-roll-rpl-12
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 (any subset of) processing typically operate with constraints on processing power, memory, and
power, memory and energy (battery), and their interconnects are energy (battery power). Their interconnects are characterized by
characterized by (any subset of) high loss rates, low data rates and high loss rates, low data rates, and instability. LLNs are comprised
instability. LLNs are comprised of anything from a few dozen and up of anything from a few dozen and up to thousands of routers.
to thousands of routers, and support point-to-point traffic (between Supported traffic flows include point-to-point (between devices
devices inside the LLN), point-to-multipoint traffic (from a central inside the LLN), point-to-multipoint (from a central control point to
control point to a subset of devices inside the LLN) and multipoint- a subset of devices inside the LLN), and multipoint-to-point (from
to-point traffic (from devices inside the LLN towards a central devices inside the LLN towards a central control point). This
control point). This document specifies the IPv6 Routing Protocol document specifies the IPv6 Routing Protocol for LLNs (RPL), which
for LLNs (RPL), which provides a mechanism whereby multipoint-to- provides a mechanism whereby multipoint-to-point traffic from devices
point traffic from devices inside the LLN towards a central control inside the LLN towards a central control point, as well as point-to-
point, as well as point-to-multipoint traffic from the central multipoint traffic from the central control point to the devices
control point to the devices inside the LLN, is supported. Support inside the LLN, is supported. Support for point-to-point traffic is
for point-to-point traffic is also available. also available.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 29, 2011. This Internet-Draft will expire on April 4, 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
skipping to change at page 2, line 40 skipping to change at page 3, line 25
3.3. Upward Routes and DODAG Construction . . . . . . . . . . 14 3.3. Upward Routes and DODAG Construction . . . . . . . . . . 14
3.3.1. Objective Function (OF) . . . . . . . . . . . . . . . 15 3.3.1. Objective Function (OF) . . . . . . . . . . . . . . . 15
3.3.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 15 3.3.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 15
3.3.3. Security . . . . . . . . . . . . . . . . . . . . . . 15 3.3.3. Security . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4. Grounded and Floating DODAGs . . . . . . . . . . . . 16 3.3.4. Grounded and Floating DODAGs . . . . . . . . . . . . 16
3.3.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 16 3.3.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 16
3.3.6. Administrative Preference . . . . . . . . . . . . . . 16 3.3.6. Administrative Preference . . . . . . . . . . . . . . 16
3.3.7. Datapath Validation and Loop Detection . . . . . . . 16 3.3.7. Datapath Validation and Loop Detection . . . . . . . 16
3.3.8. Distributed Algorithm Operation . . . . . . . . . . . 17 3.3.8. Distributed Algorithm Operation . . . . . . . . . . . 17
3.4. Downward Routes and Destination Advertisement . . . . . 17 3.4. Downward Routes and Destination Advertisement . . . . . 17
3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 17 3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 18
3.6. Rank Properties . . . . . . . . . . . . . . . . . . . . 18 3.6. Rank Properties . . . . . . . . . . . . . . . . . . . . 18
3.6.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 19 3.6.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 19
3.6.2. Rank Relationships . . . . . . . . . . . . . . . . . 19 3.6.2. Rank Relationships . . . . . . . . . . . . . . . . . 20
3.7. Routing Metrics and Constraints Used By RPL . . . . . . 20 3.7. Routing Metrics and Constraints Used By RPL . . . . . . 20
3.8. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 21 3.8. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 22
3.8.1. Greediness and Instability . . . . . . . . . . . . . 21 3.8.1. Greediness and Instability . . . . . . . . . . . . . 22
3.8.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 23 3.8.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 24 3.8.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 24
4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 25 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 25
4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 25 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 25
4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 25 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 25
4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 25 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 25
5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 26 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 26 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 26
6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 28 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 28
6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 29 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 30
6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 34 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 35
6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 34 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 35
6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 34 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 35
6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 34 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 35
6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 35 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 36
6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 35 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 36
6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 37 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 38
6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 37 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 38
6.4. Destination Advertisement Object (DAO) . . . . . . . . . 37 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 38
6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 37 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 38
6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 39 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 40
6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 39 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 40
6.5. Destination Advertisement Object Acknowledgement 6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 39 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 40
6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 39 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 40
6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 41 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 42
6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 41 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 42
6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 41 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 42
6.6.1. Format of the CC Base Object . . . . . . . . . . . . 41 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 42
6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 42 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 43
6.7. RPL Control Message Options . . . . . . . . . . . . . . 43 6.7. RPL Control Message Options . . . . . . . . . . . . . . 43
6.7.1. RPL Control Message Option Generic Format . . . . . . 43 6.7.1. RPL Control Message Option Generic Format . . . . . . 43
6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 43 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 44
6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 44 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 44 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 45
6.7.5. Route Information . . . . . . . . . . . . . . . . . . 45 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 46
6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 47 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 48
6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 49 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 49
6.7.8. Transit Information . . . . . . . . . . . . . . . . . 50 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 51
6.7.9. Solicited Information . . . . . . . . . . . . . . . . 53 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 54
6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 55 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 56
6.7.11. RPL Target descriptor . . . . . . . . . . . . . . . . 57 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 58
7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 59 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 60
7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 59 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 60
7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 60 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 61
8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 62 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 62 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 63
8.2. Upward Route Discovery and Maintenance . . . . . . . . . 62 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 63
8.2.1. Neighbors and Parents within a DODAG Version . . . . 62 8.2.1. Neighbors and Parents within a DODAG Version . . . . 63
8.2.2. Neighbors and Parents across DODAG Versions . . . . . 63 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 64
8.2.3. DIO Message Communication . . . . . . . . . . . . . . 68 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 69
8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 69 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 70
8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 69 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 70
8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 71
8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 71
8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 72
9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 73
9.1. Destination Advertisement Parents . . . . . . . . . . . 73
9.2. Downward Route Discovery and Maintenance . . . . . . . . 74
9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 75
9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 75
9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 76
9.4. DAO Transmission Scheduling . . . . . . . . . . . . . . 76
9.5. Triggering DAO Messages . . . . . . . . . . . . . . . . 77
9.6. Structure of DAO Messages . . . . . . . . . . . . . . . 78
9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 79
9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 80
9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 81
9.9.1. Path Control Example . . . . . . . . . . . . . . . . 82
8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 70 9.10. Multicast Destination Advertisement Messages . . . . . . 84
8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 70 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 85
8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 71 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 85
9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 72 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 86
9.1. Destination Advertisement Parents . . . . . . . . . . . 72 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 87
9.2. Downward Route Discovery and Maintenance . . . . . . . . 73 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 87
9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 73 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 88
9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 74 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 89
9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 74 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 90
9.4. DAO Transmission Scheduling . . . . . . . . . . . . . . 75 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 91
9.5. Triggering DAO Messages . . . . . . . . . . . . . . . . 75 10.8. Coverage of Integrity and Confidentiality . . . . . . . 92
9.6. Structure of DAO Messages . . . . . . . . . . . . . . . 76 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 92
9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 78 10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 92
9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 79 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 93
9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 79 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 95
9.9.1. Path Control Example . . . . . . . . . . . . . . . . 81 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 95
9.10. Multicast Destination Advertisement Messages . . . . . . 83 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 96
10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 84 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 97
10.1. Security Overview . . . . . . . . . . . . . . . . . . . 84 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 97
10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 85 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 100
10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 86 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 102
10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 86 14. Guidelines for Objective Functions . . . . . . . . . . . . . 103
10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 87 14.1. Objective Function Behavior . . . . . . . . . . . . . . 103
10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 88 15. Suggestions for Interoperation with Neighbor Discovery . . . 105
10.7. Reception of Incoming Packets . . . . . . . . . . . . . 89 16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 106
10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 90 17. Manageability Considerations . . . . . . . . . . . . . . . . 108
10.8. Coverage of Integrity and Confidentiality . . . . . . . 91 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 108
10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 91 17.2. Configuration Management . . . . . . . . . . . . . . . . 109
10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 91 17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 109
10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 92 17.2.2. DIO and DAO Base Message and Options Configuration . 110
11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 94
11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 94
11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 95
11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 96
11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 96
12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 99
13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 101
14. Guidelines for Objective Functions . . . . . . . . . . . . . 102
14.1. Objective Function Behavior . . . . . . . . . . . . . . 102
15. Suggestions for Interoperation with Neighbor Discovery . . . 104
16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 105
17. Manageability Considerations . . . . . . . . . . . . . . . . 107
17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 107
17.2. Configuration Management . . . . . . . . . . . . . . . . 108
17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 108
17.2.2. DIO and DAO Base Message and Options Configuration . 109
17.2.3. Protocol Parameters to be configured on every 17.2.3. Protocol Parameters to be configured on every
router in the LLN . . . . . . . . . . . . . . . . . . 109 router in the LLN . . . . . . . . . . . . . . . . . . 110
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 . . . . . . . . . . 110 non-DODAG-root router in the LLN . . . . . . . . . . 111
17.2.5. Parameters to be configured on the DODAG root . . . . 110 17.2.5. Parameters to be configured on the DODAG root . . . . 111
17.2.6. Configuration of RPL Parameters related to 17.2.6. Configuration of RPL Parameters related to
DAO-based mechanisms . . . . . . . . . . . . . . . . 111 DAO-based mechanisms . . . . . . . . . . . . . . . . 112
17.2.7. Default Values . . . . . . . . . . . . . . . . . . . 112 17.2.7. Configuration of RPL Parameters related to
17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 112 Security mechanisms . . . . . . . . . . . . . . . . . 113
17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 112 17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 114
17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 114
17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 114
17.3.2. Monitoring a DODAG inconsistencies and loop 17.3.2. Monitoring a DODAG inconsistencies and loop
detection . . . . . . . . . . . . . . . . . . . . . . 113 detection . . . . . . . . . . . . . . . . . . . . . . 115
17.4. Monitoring of the RPL data structures . . . . . . . . . 114 17.4. Monitoring of the RPL data structures . . . . . . . . . 116
17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 114 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 116
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) 17.4.2. Destination Oriented Directed Acyclic Graph (DAG)
Table . . . . . . . . . . . . . . . . . . . . . . . . 114 Table . . . . . . . . . . . . . . . . . . . . . . . . 116
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 115
17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 116 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117
17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 116 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118
17.7. Liveness Detection and Monitoring . . . . . . . . . . . 118 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118
17.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 118 17.7. Liveness Detection and Monitoring . . . . . . . . . . . 119
17.9. Impact on Other Protocols . . . . . . . . . . . . . . . 118 17.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 120
17.10. Performance Management . . . . . . . . . . . . . . . . . 118 17.9. Impact on Other Protocols . . . . . . . . . . . . . . . 120
18. Security Considerations . . . . . . . . . . . . . . . . . . . 120 17.10. Performance Management . . . . . . . . . . . . . . . . . 120
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 120 18. Security Considerations . . . . . . . . . . . . . . . . . . . 122
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 122
19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 122 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 122 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 124
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 124
19.3. New Registry for the Mode of Operation (MOP) DIO 19.3. New Registry for the Mode of Operation (MOP) DIO
Control Field . . . . . . . . . . . . . . . . . . . . . 123 Control Field . . . . . . . . . . . . . . . . . . . . . 125
19.4. RPL Control Message Option . . . . . . . . . . . . . . . 123 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 126
19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 124 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 126
19.6. New Registry for the Security Section Flags . . . . . . 124 19.6. New Registry for the Security Section Algorithm . . . . 127
19.7. New Registry for the Key Identification Mode . . . . . . 125 19.7. New Registry for the Security Section Flags . . . . . . 127
19.8. New Registry for the KIM levels . . . . . . . . . . . . 125 19.8. New Registry for the Key Identification Mode . . . . . . 128
19.9. New Registry for the DIS (DODAG Informational 19.9. New Registry for the KIM levels . . . . . . . . . . . . 128
Solicitation) Flags . . . . . . . . . . . . . . . . . . 126 19.10. New Registry for the DIS (DODAG Informational
19.10. New Registry for the DODAG Information Object (DIO) Solicitation) Flags . . . . . . . . . . . . . . . . . . 129
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 127 19.11. New Registry for the DODAG Information Object (DIO)
19.11. New Registry for the Destination Advertisement Object
(DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 127
19.12. New Registry for the Destination Advertisement Object
(DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 128
19.13. New Registry for the Consistency Check (CC) Flags . . . 128
19.14. New Registry for the DODAG Configuration Option Flags . 129
19.15. New Registry for the RPL Target Option Flags . . . . . . 129
19.16. New Registry for the Transit Information Option Flags . 129
19.17. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 130 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 130
19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 131 19.12. New Registry for the Destination Advertisement Object
19.19. Link-Local Scope multicast address . . . . . . . . . . . 131 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 130
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 132 19.13. New Registry for the Destination Advertisement Object
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 133 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 131
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 19.14. New Registry for the Consistency Check (CC) Flags . . . 131
22.1. Normative References . . . . . . . . . . . . . . . . . . 135 19.15. New Registry for the DODAG Configuration Option Flags . 132
22.2. Informative References . . . . . . . . . . . . . . . . . 136 19.16. New Registry for the RPL Target Option Flags . . . . . . 132
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139 19.17. New Registry for the Transit Information Option Flags . 133
19.18. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 133
19.19. ICMPv6: Error in Source Routing Header . . . . . . . . . 134
19.20. Link-Local Scope multicast address . . . . . . . . . . . 134
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 135
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 136
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 137
22.1. Normative References . . . . . . . . . . . . . . . . . . 137
22.2. Informative References . . . . . . . . . . . . . . . . . 138
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141
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 9, line 38 skipping to change at page 9, line 38
outgoing edges. outgoing edges.
DODAG root: A DODAG root is the DAG root of a DODAG. DODAG root: A DODAG root is the DAG root of a DODAG.
Virtual DODAG root: A Virtual DODAG root is the result of two or Virtual DODAG root: A Virtual DODAG root is the result of two or
more RPL routers, most typically LBRs, coordinating to more RPL routers, most typically LBRs, coordinating to
synchronize DODAG state and act in concert as if they are a synchronize DODAG state and act in concert as if they are a
single DODAG root (with multiple interfaces), with respect to single DODAG root (with multiple interfaces), with respect to
the LLN. The coordination most likely occurs between powered the LLN. The coordination most likely occurs between powered
devices over a reliable transit link, and the details of that devices over a reliable transit link, and the details of that
scheme are beyond the scope of this specification. scheme are out of scope for this specification (to be defined
in future companion specifications).
Up: Up refers to the direction from leaf nodes towards DODAG roots, Up: Up refers to the direction from leaf nodes towards DODAG roots,
following DODAG edges. This follows the common terminology following DODAG edges. This follows the common terminology
used in graphs and depth-first-search, where vertices further used in graphs and depth-first-search, where vertices further
from the root are "deeper," or "down," and vertices closer to from the root are "deeper," or "down," and vertices closer to
the root are "shallower," or "up". the root are "shallower," or "up".
Down: Down refers to the direction from DODAG roots towards leaf Down: Down refers to the direction from DODAG roots towards leaf
nodes, in the reverse direction of DODAG edges. This follows nodes, in the reverse direction of DODAG edges. This follows
the common terminology used in graphs and depth-first-search, the common terminology used in graphs and depth-first-search,
skipping to change at page 10, line 17 skipping to change at page 10, line 17
increases in the Down direction and strictly decreases in the increases in the Down direction and strictly decreases in the
Up direction. The exact way Rank is computed depends on the Up direction. The exact way Rank is computed depends on the
DAG's Objective Function (OF). The Rank may analogously track DAG's Objective Function (OF). The Rank may analogously track
a simple topological distance, may be calculated as a function a simple topological distance, may be calculated as a function
of link metrics, and may consider other properties such as of link metrics, and may consider other properties such as
constraints. constraints.
Objective Function (OF): Defines how routing metrics, optimization Objective Function (OF): Defines how routing metrics, optimization
objectives, and related functions are used to compute Rank. objectives, and related functions are used to compute Rank.
Furthermore, the OF dictates how parents in the DODAG are Furthermore, the OF dictates how parents in the DODAG are
selected and thus the DODAG formation itself. selected and thus the DODAG formation.
Objective Code Point (OCP): An identifier that indicates which Objective Code Point (OCP): An identifier that indicates which
Objective Function the DODAG uses. Objective Function the DODAG uses.
RPLInstanceID: A unique identifier within a network. DODAGs with RPLInstanceID: A unique identifier within a network. DODAGs with
the same RPLInstanceID share the same Objective Function. the same RPLInstanceID share the same Objective Function.
RPL Instance: A set of one or more DODAGs that share a RPL Instance: A set of one or more DODAGs that share a
RPLInstanceID. A RPL node can belong to at most one DODAG in a RPLInstanceID. A RPL node can belong to at most one DODAG in a
RPL Instance. Each RPL Instance operates independently of RPL Instance. Each RPL Instance operates independently of
skipping to change at page 11, line 20 skipping to change at page 11, line 20
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.6.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 itself. sub-DODAG of a node have a greater Rank than that node. (See
(See Section 3.6.1). Section 3.6.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 withing 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).
DIO: DODAG Information Object (See Section 6.3)
DAO: Destination Advertisement Object (See Section 6.4)
DIS: DODAG Information Solicitation (See Section 6.2)
CC: Consistency Check (See Section 6.6)
As they form networks, LLN devices often mix the roles of 'host' and As they form networks, LLN devices often mix the roles of 'host' and
'router' when compared to traditional IP networks. In this document, 'router' when compared to traditional IP networks. In this document,
'host' refers to an LLN device that can generate but does not forward 'host' refers to an LLN device that can generate but does not forward
RPL traffic, 'router' refers to an LLN device that can forward as RPL traffic, 'router' refers to an LLN device that can forward as
well as generate RPL traffic, and 'node' refers to any RPL device, well as generate RPL traffic, and 'node' refers to any RPL device,
either a host or a router. either a host or a router.
3. Protocol Overview 3. Protocol Overview
skipping to change at page 13, line 33 skipping to change at page 13, line 33
* For example, multiple border routers operating with a reliable * For example, multiple border routers operating with a reliable
transit link, e.g. in support of a 6LowPAN application, that transit link, e.g. in support of a 6LowPAN application, that
are capable to act as logically equivalent interfaces to the are capable to act as logically equivalent interfaces to the
sink of the same DODAG. sink of the same DODAG.
o a combination of the above as suited to some application scenario. o a combination of the above as suited to some application scenario.
Each RPL packet is associated with a particular RPLInstanceID (see Each RPL packet is associated with a particular RPLInstanceID (see
Section 11.2) and therefore RPL Instance (Section 5). The Section 11.2) and therefore RPL Instance (Section 5). The
provisioning or automated discovery of a mapping between a provisioning or automated discovery of a mapping between a
RPLInstanceID and a type or service of application traffic is beyond RPLInstanceID and a type or service of application traffic is out of
the scope of this specification. scope for this specification (to be defined in future companion
specifications).
Figure 1 depicts an example of a RPL Instance comprising three DODAGs Figure 1 depicts an example of a RPL Instance comprising three DODAGs
with DODAG Roots R1, R2, and R3. Each of these DODAG Roots with DODAG Roots R1, R2, and R3. Each of these DODAG Roots
advertises the same RPLInstanceID. The lines depict connectivity advertises the same RPLInstanceID. The lines depict connectivity
between parents and children. Although tree-like DODAGs are depicted between parents and children.
for simplicity, the DODAG structure allows for each node to have
multiple parents when the connectivity supports it.
Figure 2 depicts how a DODAG Version number increment leads to a new Figure 2 depicts how a DODAG Version number increment leads to a new
DODAG Version. This depiction illustrates a DODAG Version number DODAG Version. This depiction illustrates a DODAG Version number
increment that results in a different DODAG topology. Note that a increment that results in a different DODAG topology. Note that a
new DODAG Version does not always imply a different DODAG topology. new DODAG Version does not always imply a different DODAG topology.
To accommodate certain topology changes requires a new DODAG Version, To accommodate certain topology changes requires a new DODAG Version,
as described later in this specification. as described later in this specification.
Please note that in the following examples tree-like structures are
depicted for simplicity, although the DODAG structure allows for each
node to have multiple parents when the connectivity supports it.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| | | |
| +--------------+ | | +--------------+ |
| | | | | | | |
| | (R1) | (R2) (R3) | | | (R1) | (R2) (R3) |
| | / \ | /| \ / | \ | | | / \ | /| \ / | \ |
| | / \ | / | \ / | \ | | | / \ | / | \ / | \ |
| | (A) (B) | (C) | (D) ... (F) (G) (H) | | | (A) (B) | (C) | (D) ... (F) (G) (H) |
| | /|\ |\ | / | |\ | | | | | | /|\ |\ | / | / |\ |\ | | |
| | : : : : : | : (E) : : : : : | | | : : : : : | : (E) : : : `: : |
| | | / \ | | | | / \ |
| +--------------+ : : | | +--------------+ : : |
| DODAG | | DODAG |
| | | |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
RPL Instance RPL Instance
Figure 1: RPL Instance Figure 1: RPL Instance
+----------------+ +----------------+ +----------------+ +----------------+
| | | | | | | |
| (R1) | | (R1) | | (R1) | | (R1) |
| / \ | | / | | / \ | | / |
| / \ | | / | | / \ | | / |
| (A) (B) | \ | (A) | | (A) (B) | \ | (A) |
| /|\ |\ | ------\ | /|\ | | /|\ / |\ | ------\ | /|\ |
| : : (C) : : | \ | : : (C) | | : : (C) : : | \ | : : (C) |
| | / | \ | | | / | \ |
| | ------/ | \ | | | ------/ | \ |
| | / | (B) | | | / | (B) |
| | | |\ | | | | |\ |
| | | : : | | | | : : |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
Version N Version N+1 Version N Version N+1
skipping to change at page 15, line 51 skipping to change at page 15, line 51
In the second, called "pre-installed," nodes joining a RPL Instance In the second, called "pre-installed," nodes joining a RPL Instance
have pre-installed keys that enable them to process and generate have pre-installed keys that enable them to process and generate
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 outside the scope of this specification. key is obtained is out of scope for this specification (to be defined
in future companion specifications).
3.3.4. Grounded and Floating DODAGs 3.3.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.
skipping to change at page 16, line 36 skipping to change at page 16, line 36
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.3.7. Datapath Validation and Loop Detection
RPL carries routing information in a RPL Option contained in an IPv6 RPL carries routing information in a RPL Option contained in an IPv6
Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-option]. Such Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-option]. Such
routing information is used, for example, for loop detection within a routing information is used, for example, for loop detection within a
DODAG as discussed in Section 11.2 and may be extended in future DODAG as discussed in Section 11.2 and may be extended in future
documents for additional features. specifications for additional features.
The low-power and lossy nature of LLNs motivates RPL's use of on-
demand loop detection using data packets. Because data traffic can
be infrequent, maintaining a routing topology that is constantly up
to date with the physical topology can waste energy. Typical LLNs
exhibit variations in physical connectivity that are transient and
innocuous to traffic, but that would be costly to track closely from
the control plane. Transient and infrequent changes in connectivity
need not be addressed by RPL until there is data to send. This
aspect of RPL's design draws from existing, highly used LLN protocols
as well as extensive experimental and deployment evidence on its
efficacy.
Each data packet includes the Rank of the transmitter. An Each data packet includes the Rank of the transmitter. An
inconsistency between the routing decision for a packet (upward or inconsistency between the routing decision for a packet (upward or
downward) and the Rank relationship between the two nodes indicates a downward) and the Rank relationship between the two nodes indicates a
possible loop. On receiving such a packet, a node institutes a local possible loop. On receiving such a packet, a node institutes a local
repair operation. 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
skipping to change at page 17, line 18 skipping to change at page 17, line 26
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, or to maintain an existing DODAG, according to the DODAG (thus selecting DODAG parents), or to maintain an existing
specified Objective Function and Rank of their neighbors. DODAG, according to the specified Objective Function and Rank of
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 MUST provision a DODAG
parent as a default route for the associated instance. It is up parent as a default route for the associated instance.
to the end-to-end application to select the RPL instance to be
associated to its traffic (should there be more than one instance)
and thus the default route upwards when no longer-match exists.
3.4. Downward Routes and Destination Advertisement 3.4. 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
skipping to change at page 18, line 12 skipping to change at page 18, line 19
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.6. 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, and may calculation of the rank is left to the Objective Function. Even
depend on parents, link metrics, node metrics, and the node though the specific computation of the rank is left to the Objective
configuration and policies. Function, the rank must implement generic properties regardless of
the Objective Function.
In particular, the rank of the nodes must monotonically decrease as
the DODAG version is followed towards the DODAG destination. In that
regard, the rank can be regarded as a scalar representation of the
location or radius of a node within a DODAG Version.
The details of how the Objective Function computes rank are out of
scope for this specification, although that computation may depend,
for example, on parents, link metrics, node metrics, and the node
configuration and policies. See Section 14 for more information.
The rank is not a path cost, although its value can be derived from The rank is not a path cost, although its value can be derived from
and influenced by path metrics. The rank has properties of its own and influenced by path metrics. The rank has properties of its own
that are not necessarily those of all metrics: that are not necessarily those of all metrics:
Type: The rank is an abstract numeric value. Type: The rank is an abstract numeric value.
Function: The rank is the expression of a relative position within a Function: The rank is the expression of a relative position within a
DODAG Version with regard to neighbors and is not necessarily DODAG Version with regard to neighbors and is not necessarily
a good indication or a proper expression of a distance or a a good indication or a proper expression of a distance or a
skipping to change at page 18, line 47 skipping to change at page 19, line 17
root. A metric, like bandwidth or jitter, does not root. A metric, like bandwidth or jitter, does not
necessarily exhibit this property. necessarily exhibit this property.
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
nodes 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.6.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
skipping to change at page 21, line 19 skipping to change at page 21, line 33
(constrained) path. Furthermore, nodes are configured to support a (constrained) path. Furthermore, nodes are configured to support a
set of metrics and constraints, and select their parents in the DODAG set of metrics and constraints, and select their parents in the DODAG
according the the metrics and constraints advertised in the DIO according the the metrics and constraints advertised in the DIO
messages. Upstream and Downstream metrics may be merged or messages. Upstream and Downstream metrics may be merged or
advertised separately depending on the OF and the metrics. When they advertised separately depending on the OF and the metrics. When they
are advertised separately, it may happen that the set of DIO parents are advertised separately, it may happen that the set of DIO parents
is different from the set of DAO parents (a DAO parent is a node to is different from the set of DAO parents (a DAO parent is a node to
which unicast DAO messages are sent). Yet, all are DODAG parents which unicast DAO messages are sent). Yet, all are DODAG parents
with regards to the rules for Rank computation. with regards to the rules for Rank computation.
The Objective Function itself is decoupled from the routing metrics The Objective Function is decoupled from the routing metrics and
and constraints used by RPL. Indeed, whereas the OF dictates rules constraints used by RPL. Indeed, whereas the OF dictates rules such
such as DODAG parents selection, load balancing and so on, the set of as DODAG parents selection, load balancing and so on, the set of
metrics and/or constraints used, and thus determine the preferred metrics and/or constraints used, and thus determine the preferred
path, are based on the information carried within the DAG container path, are based on the information carried within the DAG container
option in DIO messages. option in DIO messages.
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.
skipping to change at page 23, line 42 skipping to change at page 24, line 9
o This cycle can be averted through mechanisms in RPL: o This cycle can be averted through mechanisms in RPL:
* 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
3.8.2. DODAG Loops 3.8.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.8.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 may mitigate the impact of includes loop detection mechanisms that mitigate the impact of DAO
DAO loops and trigger their repair. loops and trigger their repair. (See Section 11.2.2.3).
4. Traffic Flows Supported by RPL 4. Traffic Flows Supported by RPL
RPL supports three basic traffic flows: Multipoint-to-Point (MP2P), RPL supports three basic traffic flows: Multipoint-to-Point (MP2P),
Point-to-Multipoint (P2MP), and Point-to-Point (P2P). Point-to-Multipoint (P2MP), and Point-to-Point (P2P).
4.1. Multipoint-to-Point Traffic 4.1. Multipoint-to-Point Traffic
Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN
applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). The applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). The
skipping to change at page 26, line 21 skipping to change at page 26, line 21
There are two types of RPL Instances: local and global. RPL divides There are two types of RPL Instances: local and global. RPL divides
the RPLInstanceID space between Global and Local instances to allow the RPLInstanceID space between Global and Local instances to allow
for both coordinated and unilateral allocation of RPLInstanceIDs. for both coordinated and unilateral allocation of RPLInstanceIDs.
Global RPL Instances are coordinated, have one or more DODAGs, and Global RPL Instances are coordinated, have one or more DODAGs, and
are typically long-lived. Local RPL Instances are always a single are typically long-lived. Local RPL Instances are always a single
DODAG whose singular root owns the corresponding DODAGID and DODAG whose singular root owns the corresponding DODAGID and
allocates the Local RPLInstanceID in a unilateral manner. Local RPL allocates the Local RPLInstanceID in a unilateral manner. Local RPL
Instances can be used, for example, for constructing DODAGs in Instances can be used, for example, for constructing DODAGs in
support of a future on-demand routing solution. The mode of support of a future on-demand routing solution. The mode of
operation of Local RPL Instances is outside of the scope of this operation of Local RPL Instances is out of scope for this
document and may be described in other companion specifications. specification and may be described in other companion specifications.
The definition and provisioning of RPL instances are beyond the scope The definition and provisioning of RPL instances are out of scope for
of this specification. Those operations are expected to be such that this specification. Guidelines may be application and implementation
data packets coming from the outside of the RPL network can specific, and are expected to be elaborated in future companion
unambiguously be associated to at least one RPL instance, and be specifications. Those operations are expected to be such that data
safely routed over any instance that would match the packet. packets coming from the outside of the RPL network can unambiguously
Information used to match a packet to a RPL instance can typically be be associated to at least one RPL instance, and be safely routed over
taken from fields in the IPv6 header, like the flow label, any instance that would match the packet.
differentiated services (DS) field, or destination address.
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 RP network expose the RPLInstanceID Data packets that flow within the RPL network expose the
in the RPL option that is specified in [I-D.ietf-6man-rpl-option], RPLInstanceID in the IPv6 Hop-by-Hop RPL Option that is specified in
and further described in Section 11.2. For data packets coming from [I-D.ietf-6man-rpl-option], and further described in Section 11.2.
outside the RPL network, the RPLInstanceID is determined by the RPL For data packets coming from outside the RPL network, the
network ingress router and placed in the RPL option that is added to RPLInstanceID is determined by the RPL network ingress router and
the packet. placed in the IPv6 Hop-by-Hop RPL Option that is added to the packet.
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 document. There can be up to 128 global instance in the for this specification. There can be up to 128 global instance in
whole network. Local instances are always used in conjunction with a the whole network. Local instances are always used in conjunction
DODAGID (which is either given explicitly or implicitly in some with a DODAGID (which is either given explicitly or implicitly in
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
DODAGID, without any explicit coordination with other nodes, as DODAGID, without any explicit coordination with other nodes, as
further detailed below. further detailed below.
A global RPLinstanceID is encoded in a RPLinstanceID field as A global RPLinstanceID is encoded in a RPLinstanceID field as
follows: follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| ID | Global RPLinstanceID in 0..127 |0| ID | Global RPLinstanceID in 0..127
skipping to change at page 28, line 7 skipping to change at page 28, line 7
all traffic traversing that local RPL Instance will either originate all traffic traversing that local RPL Instance will either originate
or terminate at node A. The DODAGID in this case will be the or terminate at node A. The DODAGID in this case will be the
reachable IPv6 address of node A, and all traffic will contain the reachable IPv6 address of node A, and all traffic will contain the
address of node A, thus the DODAGID, in either the source or address of node A, thus the DODAGID, in either the source or
destination address. Thus the Local RPLInstanceID may indicate that destination address. Thus the Local RPLInstanceID may indicate that
the DODAGID is equivalent to either the source address or the the DODAGID is equivalent to either the source address or the
destination address by setting the D flag appropriately. destination address by setting the D flag appropriately.
6. ICMPv6 RPL Control Message 6. ICMPv6 RPL Control Message
This document defines the RPL Control Message, a new ICMPv6 message. This document defines the RPL Control Message, a new ICMPv6 [RFC4443]
A RPL Control Message is identified by a code, and composed of a base message. A RPL Control Message is identified by a code, and composed
that depends on the code, and a series of options. of a base that depends on the code, and a series of options.
A RPL Control Message has the scope of a link. The source address is Most RPL Control Message have the scope of a link. The only
a link local address. The destination address is either the RPL exception is for the DAO / DAO-ACK messages in non-storing mode,
nodes multicast address or a unicast address. The all-RPL-nodes which are exchanged using a unicast address over multiple hops and
multicast address is a new address with a requested value of FF02::1A thus uses global or unique-local addresses for both the source and
(to be confirmed by IANA). destination addresses. For all other RPL Control messages, the
source address is a link-local address, and the destination address
is either the all-RPL-nodes multicast address or a link-local unicast
address of the destination. The all-RPL-nodes multicast address is a
new address with a requested value of FF02::1A (to be confirmed by
IANA).
In accordance with [RFC4443], the RPL Control Message consists of an In accordance with [RFC4443], the RPL Control Message consists of an
ICMPv6 header followed by a message body. The message body is ICMPv6 header followed by a message body. The message body is
comprised of a message base and possibly a number of options as comprised of a message base and possibly a number of options as
illustrated in Figure 6. illustrated in Figure 6.
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 | Code | Checksum | | Type | Code | Checksum |
skipping to change at page 29, line 18 skipping to change at page 29, 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)
The checksum is computed as specified in [RFC4443]. It is set to
zero for the RPL security operations specified below, and computed
once the rest of the content of the RPL message including the
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
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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 30, line 27 skipping to change at page 30, line 38
| | | |
. 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 ICMPv6 RPL message, while encryption starts after the Security
section. Use of the Security section is further detailed in section. Use of the Security section is further detailed in
Section 18. Section 18 and Section 10.
Security Control Field: The Security Control Field has one flag and Security Control Field: The Security Control Field has one flag and
three fields: three fields:
Counter is Time (T): If the Counter is Time flag is set then Counter is Time (T): If the Counter is Time flag is set then
the Counter field is a timestamp. If the flag is cleared the Counter field is a timestamp. If the flag is cleared
then the Counter is an incrementing counter. then the Counter is an incrementing counter.
Section 10.5 describes the details of the 'T' flag and Section 10.5 describes the details of the 'T' flag and
Counter field. Counter field.
Security Level (Level): The Security Level field indicates the Security Level (Level): The Security Level field indicates the
provided packet protection. This value can be adapted on provided packet protection. This value can be adapted on
a per-packet basis and allows for varying levels of data a per-packet basis and allows for varying levels of data
authenticity and, optionally, for data confidentiality. authenticity and, optionally, for data confidentiality.
The KIM field indicates whether signatures are used and The KIM field indicates whether signatures are used and
the meaning of the Level field. The Security Level is the meaning of the Level field. The Security Level is
set to one of the non-reserved values in the tables set to one of the values in the tables below:
below:
+---------------------------+ +---------------------------+
| KIM=0,1,2 | | KIM=0,1,2 |
+-------+--------------------+------+ +-------+--------------------+------+
| LVL | Attributes | MAC | | LVL | Attributes | MAC |
| | | Len | | | | Len |
+-------+--------------------+------+ +-------+--------------------+------+
| 0 | MAC-32 | 4 | | 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 | | 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 | | 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 | | 3 | ENC-MAC-64 | 8 |
| 4-127 | Reserved | N/A | | 4-127 | Unassigned | N/A |
+-------+--------------------+------+ +-------+--------------------+------+
+---------------------+ +---------------------+
| KIM=3 | | KIM=3 |
+-------+---------------+-----+ +-------+---------------+-----+
| LVL | Attributes | Sig | | LVL | Attributes | Sig |
| | | Len | | | | Len |
+-------+---------------+-----+ +-------+---------------+-----+
| 0 | Sign-3072 | 384 | | 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 | | 1 | ENC-Sign-3072 | 384 |
| 2-127 | Reserved | N/A | | 2-127 | Unassigned | N/A |
+-------+---------------+-----+ +-------+---------------+-----+
Figure 9: Security Level (LVL) Encoding Figure 9: Security Level (LVL) Encoding
The MAC attribute indicates that the message has a The MAC attribute indicates that the message has a
Message Authentication Code of the specified length. The Message Authentication Code of the specified length. The
ENC attribute indicates that the message is encrypted. ENC attribute indicates that the message is encrypted.
The Sign attribute indicates that the message has a The Sign attribute indicates that the message has a
signature of the specified length. 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 specifies the encryption, MAC, and signature scheme the
network uses. Supported values of this field are as network uses. Supported values of this field are as
follows: follows:
+-----------+-------------------+------------------------+ +-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature | | Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+ +-----------+-------------------+------------------------+
| 0 | CCM* with AES-128 | RSA with SHA2 | | 0 | CCM with AES-128 | RSA with SHA2 |
| 1-255 | Reserved | Reserved | | 1-255 | Unassigned | Unassigned |
+-------+-------------------+----------------------------+ +-------+-------------------+----------------------------+
Figure 10: Security Algorithm (Algorithm) Encoding Figure 10: 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 Key Identifier Mode (KIM): The Key Identifier Mode field
indicates whether the key used for packet protection is indicates whether the key used for packet protection is
determined implicitly or explicitly and indicates the determined implicitly or explicitly and indicates the
particular representation of the Key Identifier field. particular representation of the Key Identifier field.
The Key Identifier Mode is set one of the non-reserved The Key Identifier Mode is set one of the values from the
values from the table below: 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 35, line 22 skipping to change at page 36, line 18
to discover a RPL Instance, learn its configuration parameters, to discover a RPL Instance, learn its configuration parameters,
select a DODAG parent set, and maintain the DODAG. select a DODAG parent set, and maintain the DODAG.
6.3.1. Format of the DIO Base Object 6.3.1. Format of the DIO Base Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank | | RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved | |G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
skipping to change at page 36, line 8 skipping to change at page 37, line 8
identifies the mode of operation of the RPL Instance as identifies the mode of operation of the RPL Instance as
administratively provisioned at and distributed by the administratively provisioned at and distributed by the
DODAG Root. All nodes who join the DODAG must be able to DODAG Root. All nodes who join the DODAG must be able to
honor the MOP in order to fully participate as a router, honor the MOP in order to fully participate as a router,
or else they must only join as a leaf. MOP is encoded as or else they must only join as a leaf. MOP is encoded as
in the figure below: in the figure below:
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
| MOP | Meaning | | MOP | Meaning |
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
| 000 | No downward routes maintained by RPL | | 0 | No downward routes maintained by RPL |
| 001 | Non storing mode | | 1 | Non storing mode |
| 010 | Storing without multicast support | | 2 | Storing without multicast support |
| 011 | Storing with multicast support | | 3 | Storing with multicast support |
| | | | | |
| | All other values are reserved | | | All other values are unassigned |
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
A value of 000 indicates that destination advertisement A value of 0 indicates that destination advertisement
messages are disabled and the DODAG maintains only upward messages are disabled and the DODAG maintains only upward
routes routes
Figure 15: Mode of Operation (MOP) Encoding Figure 15: Mode of Operation (MOP) Encoding
DODAGPreference (Prf): A 3-bit unsigned integer that defines DODAGPreference (Prf): A 3-bit unsigned integer that defines
how preferable the root of this DODAG is compared to how preferable the root of this DODAG is compared to
other DODAG roots within the instance. DAGPreference other DODAG roots within the instance. DAGPreference
ranges from 0x00 (least preferred) to 0x07 (most ranges from 0x00 (least preferred) to 0x07 (most
preferred). The default is 0 (least preferred). preferred). The default is 0 (least preferred).
skipping to change at page 40, line 42 skipping to change at page 41, line 42
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.
DAOSequence: Incremented at each DAO message from a node, and echoed DAOSequence: Incremented at each DAO message from a node, and echoed
in the DAO-ACK by the recipient. The DAOSequence is used to in the DAO-ACK by the recipient. The DAOSequence is used to
correlate a DAO message and a DAO ACK message and is not to be correlate a DAO message and a DAO ACK message and is not to be
confused with the Transit Information option Path Sequence that confused with the Transit Information option Path Sequence that
is associated to a given target Down the DODAG. is associated to a given target Down the DODAG.
Status: Indicates the completion. Status 0 is unqualified Status: Indicates the completion. Status 0 is unqualified
acceptance, 1 to 127 are reserved and undetermined, and 128 and acceptance, 1 to 127 are unassigned and undetermined, and 128
greater are rejection codes used to indicate that the node and greater are rejection codes used to indicate that the node
should select an alternate parent. should select an alternate parent.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root DODAGID (optional): 128-bit unsigned integer set by a DODAG root
which uniquely identifies a DODAG. This field is only present which uniquely identifies a DODAG. This field is only present
when the 'D' flag is set. This field is typically only present when the 'D' flag is set. This field is typically only present
when a local RPLInstanceID is in use, in order to identify the when a local RPLInstanceID is in use, in order to identify the
DODAGID that is associated with the RPLInstanceID. When a DODAGID that is associated with the RPLInstanceID. When a
global RPLInstanceID is in use this field need not be present. global RPLInstanceID is in use this field need not be present.
Unassigned bits of the DAO-ACK Base are reserved. They MUST be set Unassigned bits of the DAO-ACK Base are reserved. They MUST be set
skipping to change at page 41, line 24 skipping to change at page 42, line 24
This specification does not define any options to be carried by the This specification does not define any options to be carried by the
DAO-ACK message. DAO-ACK message.
6.6. Consistency Check (CC) 6.6. Consistency Check (CC)
The CC message is used to check secure message counters and issue The CC message is used to check secure message counters and issue
challenge/responses. A CC message MUST be sent as a secured RPL challenge/responses. A CC message MUST be sent as a secured RPL
message. message.
A CC message (request or response) MUST NOT set the 'C' bit of the
security section: CC messages always have full counters.
6.6.1. Format of the CC Base Object 6.6.1. Format of the CC Base Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |R| Flags | Nonce | | RPLInstanceID |R| Flags | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
skipping to change at page 42, line 10 skipping to change at page 43, line 7
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 18: The CC Base Object Figure 18: The CC Base Object
RPLInstanceID: 8-bit field indicating the topology instance RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
R: The 'R' flag indicates whether the CC message is a response. A R: The 'R' flag indicates whether the CC message is a response. A
message with the 'R' flag cleared is a request; a message with message with the 'R' flag cleared is a request; a message with
the 'R' flag set is a response. A CC message with the R bit the 'R' flag set is a response.
set MUST NOT compress the security Counter field: the C bit of
the security section MUST be 0.
Flags: 7-bit unused field reserved for flags. The field MUST be Flags: 7-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.
Nonce: 16-bit unsigned integer set by a CC request. The Nonce: 16-bit unsigned integer set by a CC request. The
corresponding CC response includes the same nonce value as the corresponding CC response includes the same nonce value as the
request. request.
Destination Counter: 32-bit unsigned integer value indicating the Destination Counter: 32-bit unsigned integer value indicating the
skipping to change at page 42, line 44 skipping to change at page 43, line 39
loss of Counter state. For example, where a CC request or other RPL loss of Counter state. For example, where a CC request or other RPL
message is received with an initialized Counter within the message message is received with an initialized Counter within the message
security section, the provision of the Incoming Counter within the CC security section, the provision of the Incoming Counter within the CC
response message allows the requesting node to reset its Outgoing response message allows the requesting node to reset its Outgoing
Counter to a value greater than the last value received by the Counter to a value greater than the last value received by the
responding node; the Incoming Counter will also be updated from the responding node; the Incoming Counter will also be updated from the
received CC response. received CC response.
6.6.2. CC Options 6.6.2. CC Options
The CC message MAY carry valid options. In the scope of this
specification, there are no valid options for a CC message.
This specification allows for the CC message to carry the following This specification allows for the CC message to carry the following
options: options:
0x00 Pad1 0x00 Pad1
0x01 PadN 0x01 PadN
6.7. RPL Control Message Options 6.7. RPL Control Message Options
6.7.1. RPL Control Message Option Generic Format 6.7.1. RPL Control Message Option Generic Format
RPL Control Message Options all follow this format: RPL Control Message Options all follow this format:
skipping to change at page 43, line 44 skipping to change at page 44, line 38
RPL message options may have alignment requirements. Following the RPL message options may have alignment requirements. Following the
convention in IPv6, options with alignment requirements are aligned convention in IPv6, options with alignment requirements are aligned
in a packet such that multi-octet values within the Option Data field in a packet such that multi-octet values within the Option Data field
of each option fall on natural boundaries (i.e., fields of width n of each option fall on natural boundaries (i.e., fields of width n
octets are placed at an integer multiple of n octets from the start octets are placed at an integer multiple of n octets from the start
of the header, for n = 1, 2, 4, or 8). of the header, for n = 1, 2, 4, or 8).
6.7.2. Pad1 6.7.2. Pad1
The Pad1 option MAY be present in DIS, DIO, DAO, and DAO-ACK The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
messages, and its format is as follows: messages, and its format is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad 1 Option Figure 20: Format of the Pad 1 Option
The Pad1 option is used to insert one or two octets of padding into The Pad1 option is used to insert one or two octets of padding into
the message to enable options alignment. If more than one octet of the message to enable options alignment. If more than one octet of
padding is required, the PadN option should be used rather than padding is required, the PadN option should be used rather than
multiple Pad1 options. multiple Pad1 options.
NOTE! the format of the Pad1 option is a special case - it has NOTE! the format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields. neither Option Length nor Option Data fields.
6.7.3. PadN 6.7.3. PadN
The PadN option MAY be present in DIS, DIO, DAO, and DAO-ACK The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
messages, and its format is as follows: messages, and its format is as follows:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 1 | Option Length | 0x00 Padding... | Type = 1 | Option Length | 0x00 Padding...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 21: Format of the Pad N Option Figure 21: Format of the Pad N Option
skipping to change at page 49, line 25 skipping to change at page 50, line 8
identifies the OF and is managed by the IANA. identifies the OF and is managed by the IANA.
6.7.7. RPL Target 6.7.7. RPL Target
The RPL Target option MAY be present in DAO messages, and its format The RPL Target option MAY be present in DAO messages, and its format
is as follows: is 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 = 5 | Option Length | Flags | Prefix Length | | Type = 5 | Option Length | Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Target Prefix (Variable Length) | | Target Prefix (Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Format of the RPL Target Option Figure 25: Format of the RPL Target Option
skipping to change at page 57, line 34 skipping to change at page 58, line 25
advertising a prefix till it owns an address of that prefix, advertising a prefix till it owns an address of that prefix,
and then it SHOULD advertise its full address in this field, and then it SHOULD advertise its full address in this field,
with the 'R' flag set. The children of a node that so with the 'R' flag set. The children of a node that so
advertises a full address with the 'R' flag set may then use advertises a full address with the 'R' flag set may then use
that address to determine the content of the Parent Address that address to determine the content of the Parent Address
field of the Transit Information Option. field of the Transit Information Option.
Unassigned bits of the Prefix Information option are reserved. They Unassigned bits of the Prefix Information option are reserved. They
MUST be set to zero on transmission and MUST be ignored on reception. MUST be set to zero on transmission and MUST be ignored on reception.
6.7.11. RPL Target descriptor 6.7.11. RPL Target Descriptor
The RPL Target option MAY be immediately followed by one opaque The RPL Target option MAY be immediately followed by one opaque
descriptor that qualifies that specific target. descriptor that qualifies that specific target.
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 = 9 |Opt Length = 4 | Descriptor | | Type = 9 |Opt Length = 4 | Descriptor
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor (cont.) | Descriptor (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Format of the RPL Target Descriptor Option Figure 30: Format of the RPL Target Descriptor Option
The RPL Target Descriptor Option is used to qualify a target, The RPL Target Descriptor Option is used to qualify a target,
something that is sometimes called tagging. something that is sometimes called tagging.
There can be at most one descriptor per target. The descriptor is There can be at most one descriptor per target. The descriptor is
set by the node that injects the target in the RPL network. It MUST set by the node that injects the target in the RPL network. It MUST
be copied but not modified by routers that propagate the target Up be copied but not modified by routers that propagate the target Up
skipping to change at page 60, line 43 skipping to change at page 61, line 43
2. When a sequence counter increment would cause the sequence 2. When a sequence counter increment would cause the sequence
counter to increment beyond its maximum value, the sequence counter to increment beyond its maximum value, the sequence
counter MUST wrap back to zero. When incrementing a sequence counter MUST wrap back to zero. When incrementing a sequence
counter greater than or equal to 128, the maximum value is 255. counter greater than or equal to 128, the maximum value is 255.
When incrementing a sequence counter less than 128, the maximum When incrementing a sequence counter less than 128, the maximum
value is 127. value is 127.
3. When comparing two sequence counters, the following rules MUST be 3. When comparing two sequence counters, the following rules MUST be
applied: applied:
1. When a first sequence counter A is in the interval [0..127] 1. When a first sequence counter A is in the interval [128..255]
and a second sequence counter B is in [128..255]: and a second sequence counter B is in [0..127]:
1. If B-A is less than or equal to SEQUENCE_WINDOW, then B 1. If (256 + B - A) is less than or equal to
is greater than A, A is less than B, and the two are not SEQUENCE_WINDOW, then B is greater than A, A is less than
B, and the two are not equal.
2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A
is greater than B, B is less than A, and the two are not
equal. equal.
2. If B-A is greater than SEQUENCE_WINDOW, then A is greater For example, if A is 240, and B is 5, then (256 + 5 - 240) is
than B, B is less than A, and the two are not equal. 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is
greater than 16. As another example, if A is 250 and B is 5,
then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW
(16), thus 250 is less than 5.
2. In the case where both sequence counters to be compared are 2. In the case where both sequence counters to be compared are
less than or equal to 127, and in the case where both less than or equal to 127, and in the case where both
sequence counters to be compared are greater than or equal to sequence counters to be compared are greater than or equal to
128: 128:
1. If the absolute magnitude of difference between the two 1. If the absolute magnitude of difference between the two
sequence counters is less than or equal to sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in SEQUENCE_WINDOW, then a comparison as described in
[RFC1982] is used to determine the relationships greater [RFC1982] is used to determine the relationships greater
skipping to change at page 65, line 20 skipping to change at page 66, line 20
neighbor as a parent could cause a loop. If that candidate neighbor neighbor as a parent could cause a loop. If that candidate neighbor
in this case is observed to advertise a DODAGVersionNumber N+1, then in this case is observed to advertise a DODAGVersionNumber N+1, then
that candidate neighbor is certain to be safe, since it is certain that candidate neighbor is certain to be safe, since it is certain
not to be in that original node's sub-DODAG as it has been able to not to be in that original node's sub-DODAG as it has been able to
increment the DODAGVersionNumber by hearing from the DODAG root while increment the DODAGVersionNumber by hearing from the DODAG root while
that original node was detached. It is for this reason that it is that original node was detached. It is for this reason that it is
useful for the detached node to remember the original DODAG useful for the detached node to remember the original DODAG
information, including the DODAGVersionNumber N. information, including the DODAGVersionNumber N.
Exactly when a DODAG Root increments the DODAGVersionNumber is Exactly when a DODAG Root increments the DODAGVersionNumber is
implementation and application-dependent and outside the scope of implementation dependent and out of scope for this specification.
this document. Examples include incrementing the DODAGVersionNumber Examples include incrementing the DODAGVersionNumber periodically,
periodically, upon administrative intervention, or on application- upon administrative intervention, or on application-level detection
level detection of lost connectivity or DODAG inefficiency. of lost connectivity or DODAG inefficiency.
After a node transitions to and advertises a new DODAG Version, the After a node transitions to and advertises a new DODAG Version, the
rules above make it unable to advertise the previous DODAG Version rules above make it unable to advertise the previous DODAG Version
(prior DODAGVersionNumber) once it has committed to advertising the (prior DODAGVersionNumber) once it has committed to advertising the
new DODAG Version. new DODAG Version.
8.2.2.2. DODAG Roots 8.2.2.2. DODAG Roots
1. A DODAG root without possibility to satisfy the application- 1. A DODAG root without possibility to satisfy the application-
defined goal MUST NOT set the Grounded bit. defined goal MUST NOT set the Grounded bit.
skipping to change at page 65, line 50 skipping to change at page 66, line 50
In a deployment that uses non-RPL links to federate a number of LLN In a deployment that uses non-RPL links to federate a number of LLN
roots, it is possible to run RPL over those non-RPL links and use one roots, it is possible to run RPL over those non-RPL links and use one
router as a "backbone root". The backbone root is the virtual root router as a "backbone root". The backbone root is the virtual root
of the DODAG, and exposes a rank of BASE_RANK over the backbone. All of the DODAG, and exposes a rank of BASE_RANK over the backbone. All
the LLN roots that are parented to that backbone root, including the the LLN roots that are parented to that backbone root, including the
backbone root if it also serves as LLN root itself, expose a rank of backbone root if it also serves as LLN root itself, expose a rank of
ROOT_RANK to the LLN. These virtual roots are part of the same DODAG ROOT_RANK to the LLN. These virtual roots are part of the same DODAG
and advertise the same DODAGID. They coordinate DODAGVersionNumbers and advertise the same DODAGID. They coordinate DODAGVersionNumbers
and other DODAG parameters with the virtual root over the backbone. and other DODAG parameters with the virtual root over the backbone.
The method of coordination is outside the scope of this The method of coordination is out of scope for this specification (to
specification. be defined in future companion specifications).
8.2.2.3. DODAG Selection 8.2.2.3. DODAG Selection
The objective function and the set of advertised routing metrics and The objective function and the set of advertised routing metrics and
constraints of a DAG determines how a node selects its neighbor set, constraints of a DAG determines how a node selects its neighbor set,
parent set, and preferred parents. This selection implicitly also parent set, and preferred parents. This selection implicitly also
determines the DODAG within a DAG. Such selection can include determines the DODAG within a DAG. Such selection can include
administrative preference (Prf) as well as metrics or other administrative preference (Prf) as well as metrics or other
considerations. considerations.
skipping to change at page 67, line 38 skipping to change at page 68, line 38
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 RPL option ([I-D.ietf-6man-rpl-option]) includes a Rank that is whose IPv6 Hop-by-Hop RPL Option ([I-D.ietf-6man-rpl-option])
not INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs. includes a Rank that is not INFINITE_RANK, yet still advertise
INFINITE_RANK in its DIOs.
When a (former) parent is observed to advertise a Rank of When a (former) parent is observed to advertise a Rank of
INFINITE_RANK, that (former) parent has detached from the DODAG and INFINITE_RANK, that (former) parent has detached from the DODAG and
is no longer able to act as a parent, nor is there any why that is no longer able to act as a parent, nor is there any 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
1. A node unable to stay connected to a DODAG within a given DODAG 1. A node unable to stay connected to a DODAG within a given DODAG
Version, i.e. that cannot retain non-empty parent set without Version, i.e. that cannot retain non-empty parent set without
violating the rules of this specification, MAY detach from this violating the rules of this specification, MAY detach from this
DODAG Version. A node that detaches becomes root of its own DODAG Version. A node that detaches becomes root of its own
floating DODAG and SHOULD immediately advertise this new floating DODAG and SHOULD immediately advertise this new
situation in a DIO as an alternate to poisoning. situation in a DIO as an alternate to poisoning.
8.2.2.7. Following a Parent 8.2.2.7. Following a Parent
1. If a node receives a DIO from one of its DODAG parents, 1. If a node receives a DIO from one of its DODAG parents,
skipping to change at page 72, line 35 skipping to change at page 73, line 35
non-storing networks. A node may send a P2P packet destined to a non-storing networks. A node may send a P2P packet destined to a
one-hop neighbor directly to that node. one-hop neighbor directly to that node.
9.1. Destination Advertisement Parents 9.1. Destination Advertisement Parents
To establish downward routes, RPL nodes send DAO messages upwards. To establish downward routes, RPL nodes send DAO messages upwards.
The next hop destinations of these DAO messages are called DAO The next hop destinations of these DAO messages are called DAO
parents. The collection of a node's DAO parents is called the DAO parents. The collection of a node's DAO parents is called the DAO
parent set. parent set.
1. A node's DAO parent set MUST be a subset of its DODAG parent set. 1. A node MAY send DAO messages using the all-RPL-nodes multicast
address, which is an optimization to provision one-hop routing.
The 'K' bit MUST be cleared on transmission of the multicast DAO.
2. In storing mode operation, a node MUST NOT address unicast DAO 2. A node's DAO parent set MUST be a subset of its DODAG parent set.
messages to nodes that are not DAO parents.
3. In non-storing mode operation, a node MUST NOT address unicast 3. In storing mode operation, a node MUST NOT address unicast DAO
DAO messages to nodes that are not DODAG roots. messages to nodes that are not DAO parents.
4. A node MUST NOT forward unicast DAO messages to nodes that are 4. In storing mode operation, the IPv6 source and destination
not DAO parents. addresses of a DAO message MUST be link-local addresses.
5. A node MAY send DAO messages using the all-RPL-nodes multicast 5. In non-storing mode operation, a node MUST NOT address unicast
address, which is an optimization to provision on-hop routing. DAO messages to nodes that are not DODAG roots.
The 'K' bit MUST be cleared on transmission of the multicast DAO.
6. The IPv6 Source Address of a DAO message MUST be the link local 6. In non-storing mode operation, the IPv6 source and destination
address of the sending node. addresses of a DAO message MUST be a unique-local or a global
addresses.
The selection of DAO parents is implementation and objective function The selection of DAO parents is implementation and objective function
specific. specific.
9.2. Downward Route Discovery and Maintenance 9.2. Downward Route Discovery and Maintenance
Destination Advertisement may be configured to be entirely disabled, Destination Advertisement may be configured to be entirely disabled,
or operate in either a storing or non-storing mode, as reported in or operate in either a storing or non-storing mode, as reported in
the MOP in the DIO message. the MOP in the DIO message.
1. All nodes who join a DODAG MUST abide by the MOP setting from the 1. All nodes who join a DODAG MUST abide by the MOP setting from the
root. Nodes that do not have the capability to fully participate root. Nodes that do not have the capability to fully participate
as a router, e.g. that does not match the advertised MOP, MAY as a router, e.g. that does not match the advertised MOP, MAY
join the DODAG as a leaf. join the DODAG as a leaf.
2. If the MOP is 000, indicating no downward routing, nodes MUST NOT 2. If the MOP is 0, indicating no downward routing, nodes MUST NOT
transmit DAO messages, and MAY ignore DAO messages. transmit DAO messages, and MAY ignore DAO messages.
3. In non-storing mode, the DODAG Root SHOULD store source routing 3. In non-storing mode, the DODAG Root SHOULD store source routing
table entries for destinations learned from DAOs. table entries for destinations learned from DAOs.
4. In storing mode, all non-root, non-leaf nodes MUST store routing 4. In storing mode, all non-root, non-leaf nodes MUST store routing
table entries for destinations learned from DAOs. table entries for destinations learned from DAOs.
A DODAG can have one of several possible modes of operation, as A DODAG can have one of several possible modes of operation, as
defined by the MOP field. Either it does not support downward defined by the MOP field. Either it does not support downward
routes, it supports downward routes through source routing from DODAG routes, it supports downward routes through source routing from DODAG
Roots, or it supports downward routes through in-network routing Roots, or it supports downward routes through in-network routing
tables. When downward routes are supported through in-network tables.
routing tables, the multicast operation defined in this specification
may or may not be supported, also as indicated by the MOP field. As When downward routes are supported through in-network routing tables,
of this specification RPL does not support mixed-mode operation, the multicast operation defined in this specification may or may not
be supported, also as indicated by the MOP field.
When downward routes are supported through in-network routing tables
as described in this specification, it is expected that nodes acting
as routers have been provisioned sufficiently to hold the required
routing table state. If a node acting as a router is unable to hold
the full routing table state then the routing state is not complete,
messages may be dropped as a consequence, and a fault may be logged
(Section 17.5). Future extensions to RPL may elaborate on refined
actions/behaviors to manage this case.
As of this specification RPL does not support mixed-mode operation,
where some nodes source route and other store routing tables: future where some nodes source route and other store routing tables: future
extensions to RPL may support this mode of operation. extensions to RPL may support this mode of operation.
9.2.1. Maintenance of Path Sequence 9.2.1. Maintenance of Path Sequence
For each Target that is associated with (owned by) a node, that node For each Target that is associated with (owned by) a node, that node
is responsible to emit DAO messages in order to provision the is responsible to emit DAO messages in order to provision the
downward routes. The Target+Transit information contained in those downward routes. The Target+Transit information contained in those
DAO messages subsequently propagates Up the DODAG. The Path Sequence DAO messages subsequently propagates Up the DODAG. The Path Sequence
counter in the Transit information option is used to indicate counter in the Transit information option is used to indicate
skipping to change at page 83, line 24 skipping to change at page 84, line 34
A special case of DAO operation, distinct from unicast DAO operation, A special case of DAO operation, distinct from unicast DAO operation,
is multicast DAO operation which may be used to populate '1-hop' is multicast DAO operation which may be used to populate '1-hop'
routing table entries. routing table entries.
1. A node MAY multicast a DAO message to the link-local scope all- 1. A node MAY multicast a DAO message to the link-local scope all-
RPL-nodes multicast address. RPL-nodes multicast address.
2. A multicast DAO message MUST be used only to advertise 2. A multicast DAO message MUST be used only to advertise
information about the node itself, i.e. prefixes directly information about the node itself, i.e. prefixes directly
connected to or owned by this node, such as a multicast group connected to or owned by the node, such as a multicast group that
that the node is subscribed to or a global address owned by the the node is subscribed to or a global address owned by the node.
node.
3. A multicast DAO message MUST NOT be used to relay connectivity 3. A multicast DAO message MUST NOT be used to relay connectivity
information learned (e.g. through unicast DAO) from another node. information learned (e.g. through unicast DAO) from another node.
4. A node MUST NOT perform any other DAO related processing on a 4. A node MUST NOT perform any other DAO related processing on a
received multicast DAO message, in particular a node MUST NOT received multicast DAO message, in particular a node MUST NOT
perform the actions of a DAO parent upon receipt of a multicast perform the actions of a DAO parent upon receipt of a multicast
DAO. DAO.
o The multicast DAO may be used to enable direct P2P communication, o The multicast DAO may be used to enable direct P2P communication,
without needing the DODAG to relay the packets. without needing the DODAG to relay the packets.
10. Security Mechanisms 10. Security Mechanisms
This section describes the generation and processing of secure RPL This section describes the generation and processing of secure RPL
messages. The high order bit of the RPL message code identifies messages. The high order bit of the RPL message code identifies
whether a RPL message is secure or not. In addition to secure whether a RPL message is secure or not. In addition to secure
versions of basic control messages (DIS, DIO, DAO, DAO-Ack), RPL has versions of basic control messages (DIS, DIO, DAO, DAO-ACK), RPL has
several messages which are relevant only in networks with security several messages which are relevant only in networks with security
enabled. enabled.
Implementation complexity and size is a core concern for LLNs such Implementation complexity and size is a core concern for LLNs such
that it may be economically or physically impossible to include that it may be economically or physically impossible to include
sophisticated security provisions in a RPL implementation. sophisticated security provisions in a RPL implementation.
Furthermore, many deployments can utilize link-layer or other Furthermore, many deployments can utilize link-layer or other
security mechanisms to meet their security requirements without security mechanisms to meet their security requirements without
requiring the use of security in RPL itself. requiring the use of security in RPL.
Therefore, the security features described in this document are Therefore, the security features described in this document are
OPTIONAL to implement. A given implementation MAY support a subset OPTIONAL to implement. A given implementation MAY support a subset
(including the empty set) of the described security features, for (including the empty set) of the described security features, for
example it could support integrity and confidentiality, but not example it could support integrity and confidentiality, but not
signatures. An implementation SHOULD clearly specify which security signatures. An implementation SHOULD clearly specify which security
mechanisms are supported, and deployers are RECOMMENDED to carefully mechanisms are supported, and it is RECOMMENDED that implementers
consider their security requirements and the availability of security carefully consider security requirements and the availability of
mechanisms in their network. security mechanisms in their network.
10.1. Security Overview 10.1. Security Overview
RPL supports three security modes: RPL supports three security modes:
o Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO, o Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO,
and DAO-Ack messages, which do not have security sections. As a and DAO-ACK messages, which do not have security sections. As a
network could be using other security mechanisms, such as link- network could be using other security mechanisms, such as link-
layer security, unsecured mode does not imply all messages are layer security, unsecured mode does not imply all messages are
sent without any protection. sent without any protection.
o Pre-installed. In this security mode, RPL uses secure messages. o Pre-installed. In this security mode, RPL uses secure messages.
To join a RPL Instance, a node must have a pre-installed key. To join a RPL Instance, a node must have a pre-installed key.
Nodes use this to provide message confidentiality, integrity, and Nodes use this to provide message confidentiality, integrity, and
authenticity. A node may, using this preinstalled key, join the authenticity. A node may, using this preinstalled key, join the
RPL network as either a host or a router. RPL network as either a host or a router.
o Authenticated. In this security mode, RPL uses secure messages. o Authenticated. In this security mode, RPL uses secure messages.
To join a RPL Instance, a node must have a pre-installed key. To join a RPL Instance, a node must have a pre-installed key.
Node use this key to provide message confidentiality, integrity, Nodes use this key to provide message confidentiality, integrity,
and authenticity. Using this preinstalled key, a node may join and authenticity. Using this preinstalled key, a node may join
the network as a host only. To join the network as a router, a the network as a host only. To join the network as a router, a
node must obtain a second key from a key authority. This key node must obtain a second key from a key authority. This key
authority can authenticate that the requester is allowed to be a authority can authenticate that the requester is allowed to be a
router before providing it with the second key. router before providing it with the second key. Authenticated
mode cannot be supported by symmetric algorithms. As of this
specification, RPL supports only symmetric algorithms:
authenticated mode is included for the benefit of potential future
cryptographic primitives.
Whether or not the RPL Instance uses unsecured mode is signaled by Whether or not the RPL Instance uses unsecured mode is signaled by
whether it uses secure RPL messages. Whether a secured network uses whether it uses secure RPL messages. Whether a secured network uses
the pre-installed or authenticated mode is signaled by the 'A' bit of the pre-installed or authenticated mode is signaled by the 'A' bit of
the DAG Configuration option. the DAG Configuration option.
This specification specifies CCM* -- Counter with CBC-MAC (Cipher This specification specifies CCM -- Counter with CBC-MAC (Cipher
Block Chaining Message Authentication Code) -- as the cryptographic Block Chaining Message Authentication Code) -- as the cryptographic
basis for RPL security[RFC3610]. In this specification, CCM uses basis for RPL security[RFC3610]. In this specification, CCM uses
AES-128 as its underlying cryptographic algorithm. There are bits AES-128 as its underlying cryptographic algorithm. There are bits
reserved in the security section to specify other algorithms in the reserved in the security section to specify other algorithms in the
future. future.
All secured RPL messages have either a message authentication code All secured RPL messages have either a message authentication code
(MAC) or a signature. Secured RPL messages optionally also have (MAC) or a signature. Secured RPL messages optionally also have
encryption protection for confidentiality. Secured RPL message encryption protection for confidentiality. Secured RPL message
formats support both integrated encryption/authentication schemes formats support both integrated encryption/authentication schemes
(e.g., CCM*) as well as schemes that separately encrypt and (e.g., CCM) as well as schemes that separately encrypt and
authenticate packets. authenticate packets.
10.2. Joining a Secure Network 10.2. Joining a Secure Network
RPL security assumes that a node wishing to join a secured network RPL security assumes that a node wishing to join a secured network
has been preconfigured with a shared key for communicating with has been preconfigured with a shared key for communicating with
neighbors and the RPL root. To join a secure RPL network, a node neighbors and the RPL root. To join a secure RPL network, a node
either listens for secure DIOs or triggers secure DIOs by sending a either listens for secure DIOs or triggers secure DIOs by sending a
secure DIS. In addition to the DIO/DIS rules in Section 8, secure secure DIS. In addition to the DIO/DIS rules in Section 8, secure
DIO and DIS messages have these rules: DIO and DIS messages have these rules:
skipping to change at page 86, line 36 skipping to change at page 87, line 40
not a router. A node must communicate with a key authority to obtain not a router. A node must communicate with a key authority to obtain
a key that will enable it to act as a router. a key that will enable it to act as a router.
10.3. Installing Keys 10.3. Installing Keys
Authenticated mode requires a would-be router to dynamically install Authenticated mode requires a would-be router to dynamically install
new keys once they have joined a network as a host. Having joined as new keys once they have joined a network as a host. Having joined as
a host, the node uses standard IP messaging to communicate with an a host, the node uses standard IP messaging to communicate with an
authorization server, which can provide new keys. authorization server, which can provide new keys.
The protocol to obtain such keys is the subject of a future standard. The protocol to obtain such keys is out of scope for this
specification and to be elaborated in future specifications.
10.4. Consistency Checks 10.4. Consistency Checks
RPL nodes send Consistency Check (CC) messages to protect against RPL nodes send Consistency Check (CC) messages to protect against
replay attacks and synchronize counters. replay attacks and synchronize counters.
1. If a node receives a unicast CC message with the R bit cleared, 1. If a node receives a unicast CC message with the R bit cleared,
and it is a member of or is in the process of joining the and it is a member of or is in the process of joining the
associated DODAG, it SHOULD respond with a unicast CC message to associated DODAG, it SHOULD respond with a unicast CC message to
the sender. This response MUST have the R bit set, and MUST have the sender. This response MUST have the R bit set, and MUST have
skipping to change at page 89, line 25 skipping to change at page 90, line 30
describes how RPL generates an unencrypted variant of the packet and describes how RPL generates an unencrypted variant of the packet and
validates its integrity. validates its integrity.
The receiver uses the RPL security control fields to determine the The receiver uses the RPL security control fields to determine the
necessary packet security processing. If the described level of necessary packet security processing. If the described level of
security for the message type and originator does not meet locally security for the message type and originator does not meet locally
maintained security policies, a node MAY discard the packet without maintained security policies, a node MAY discard the packet without
further processing. These policies can include security levels, keys further processing. These policies can include security levels, keys
used, source identifiers, or the lack of timestamp-based counters (as used, source identifiers, or the lack of timestamp-based counters (as
indicated by the 'T' flag). The configuration of the security policy indicated by the 'T' flag). The configuration of the security policy
database for incoming packet processing is outside the scope of this database for incoming packet processing is out of scope for this
specification (it may, for example, be defined through DIO specification (it may, for example, be defined through DIO
Configuration or through out-of-band administrative router Configuration or through out-of-band administrative router
configuration). configuration).
Where the message security level (LVL) indicates an encrypted RPL Where the message security level (LVL) indicates an encrypted RPL
message, the node uses the key information identified through the KIM message, the node uses the key information identified through the KIM
field as well as the Nonce as input to the message payload decryption field as well as the Nonce as input to the message payload decryption
processing. The Nonce shall be derived from the message Counter processing. The Nonce shall be derived from the message Counter
field and other received and locally maintained information (see field and other received and locally maintained information (see
Section 10.9.1). The plaintext message contents shall be obtained by Section 10.9.1). The plaintext message contents shall be obtained by
skipping to change at page 91, line 11 skipping to change at page 92, line 13
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. MAC and signature calculations are performed the entire IPv6 packet. When computing MACs and signatures, mutable
before any compression that lower layers may apply. IPv6 fields are considered to be filled with zeroes, following the
rules in Section 3.3.3.1 of [RFC4302] (IPSec Authenticated Header).
MAC and signature calculations are performed before any compression
that lower layers may apply.
When a RPL ICMPv6 message is encrypted, encryption starts at the 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[CCMStar] 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
MAC. The block cipher key is determined by the Key Index; the Nonce MAC. The block cipher key is determined by the Key Index; the Nonce
is computed as described in Section 10.9.1; the message to is computed as described in Section 10.9.1; the message to
authenticate and encrypt is the RPL message starting at the first authenticate and encrypt is the RPL message starting at the first
byte after the security section and ends with the last byte of the byte after the security section and ends with the last byte of the
packet; the additional authentication data starts with the beginning packet; the additional authentication data starts with the beginning
of the IPv6 header and ends with the last byte of the RPL security of the IPv6 header and ends with the last byte of the RPL security
section. section.
10.9. Cryptographic Mode of Operation 10.9. Cryptographic Mode of Operation
The cryptographic mode of operation described in this specification The cryptographic mode of operation described in this specification
(Algorithm = 0) is based on CCM and the block-cipher AES- (Algorithm = 0) is based on CCM and the block-cipher AES-
128[RFC3610]. This mode of operation is widely supported by existing 128[RFC3610]. This mode of operation is widely supported by existing
implementations and coincides with the CCM* mode of implementations. CCM mode requires a nonce.
operation[CCMStar]. CCM mode requires a nonce.
10.9.1. Nonce 10.9.1. Nonce
A RPL node constructs a CCM nonce as follows: A RPL node constructs a CCM nonce 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Source Identifier + + Source Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter | | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved | LVL | |Reserved | LVL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 31: CCM* Nonce Figure 31: CCM Nonce
Source Identifier: 8 bytes. Source Identifier is set to the logical Source Identifier: 8 bytes. Source Identifier is set to the logical
identifier of the originator of the protected packet. identifier of the originator of the protected packet.
Counter: 4 bytes. Counter is set to the (uncompressed) value of the Counter: 4 bytes. Counter is set to the (uncompressed) value of the
corresponding field in the Security option of the RPL control corresponding field in the Security option of the RPL control
message. message.
Security Level (LVL): 3 bits. Security Level is set to the value of Security Level (LVL): 3 bits. Security Level is set to the value of
the corresponding field in the Security option of the RPL the corresponding field in the Security option of the RPL
skipping to change at page 92, line 46 skipping to change at page 93, line 46
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 [RFC3447]. It uses as public key the pair
(n,e), where n is a 3072-bit RSA modulus and where e=2^{16}+1. It (n,e), where n is a 3072-bit RSA modulus and where e=2^{16}+1. It
uses CCM* mode[CCMStar] as the encryption scheme with M=0 (as a uses CCM mode[RFC3610] as the encryption scheme with M=0 (as a
stream-cipher). It uses the SHA-2 hash function [sha2]. It uses the stream-cipher). It uses the SHA-256 hash function specified in
message encoding rule of [RFC3447]. Section 6.2 of [SHA2]. It uses the message encoding rule 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
networks. If needed, alternative signature schemes which produce networks. If needed, alternative signature schemes which produce
more concise signatures may be the subject of a future work. more concise signatures is out of scope for this specification and
may be the subject of a future specification.
11. Packet Forwarding and Loop Avoidance/Detection 11. Packet Forwarding and Loop Avoidance/Detection
11.1. Suggestions for Packet Forwarding 11.1. Suggestions for Packet Forwarding
This document specifies a routing protocol. These non-normative
suggestions are provided to aid in the design of a forwarding
implementation by illustrating how such an implementation could work
with RPL
When forwarding a packet to a destination, precedence is given to When forwarding a packet to a destination, precedence is given to
selection of a next-hop successor as follows: selection of a next-hop successor as follows:
1. This specification only covers how a successor is selected from 1. This specification only covers how a successor is selected from
the DODAG Version that matches the RPLInstanceID marked in the the DODAG Version that matches the RPLInstanceID marked in the
IPv6 header of the packet being forwarded. Routing outside the IPv6 header of the packet being forwarded. Routing outside the
instance can be done as long as additional rules are put in place instance can be done as long as additional rules are put in place
such as strict ordering of instances and routing protocols to such as strict ordering of instances and routing protocols to
protect against loops. Such rules may be defined in a separate protect against loops. Such rules may be defined in a separate
document. document.
2. If a local administrative preference favors a route that has been 2. If a local administrative preference favors a route that has been
learned from a different routing protocol than RPL, then use that learned from a different routing protocol than RPL, then use that
successor. successor.
3. If the packet header specifies a source route by including a RH4 3. If the packet header specifies a source route by including a RH4
header as specified in [I-D.ietf-6man-rpl-routing-header], then header as specified in [I-D.ietf-6man-rpl-routing-header], then
use that route. If the node fails to forward the packet with use that route. If the node fails to forward the packet with
that specified source route, then that packet SHOULD be dropped. that specified source route, then that packet should be dropped.
The node MAY log an error. The node MAY send an ICMPv6 Error in The node MAY log an error. The node may send an ICMPv6 Error in
Source Routing Header message to the source of the packet (See Source Routing Header message to the source of the packet (See
Section 19.18). Section 19.19).
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 95, line 14 skipping to change at page 96, line 21
exists. exists.
8. Finally the packet is dropped. ICMP Destination Unreachable MAY 8. Finally the packet is dropped. ICMP Destination Unreachable MAY
be invoked (an inconsistency is detected). be invoked (an inconsistency is detected).
Hop Limit MUST be decremented when forwarding as per [RFC2460]. Hop Limit MUST be decremented when forwarding as per [RFC2460].
Note that the chosen successor MUST NOT be the neighbor that was the Note that the chosen successor MUST NOT be the neighbor that was the
predecessor of the packet (split horizon), except in the case where predecessor of the packet (split horizon), except in the case where
it is intended for the packet to change from an upward to a downward it is intended for the packet to change from an upward to a downward
flow, as determined by the routing table of the node making the direction, as determined by the routing table of the node making the
change, such as switching from DIO routes to DAO routes as the change, such as switching from DIO routes to DAO routes as the
destination is neared in order to continue traveling toward the destination is neared in order to continue traveling toward the
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 information that contained within the data
packet using the RPL Option [I-D.ietf-6man-rpl-option]) in an IPv6 packet using the RPL Option [I-D.ietf-6man-rpl-option]) in an IPv6
Hop-by-Hop Option header. The RPL Option is a generic container for Hop-by-Hop Option header. The RPL Option contains RPL Packet
a list of TLVs. This specification defines a new RPL Option type, Information (Figure 32) and [I-D.ietf-6man-rpl-option] defines the
called the RPL Loop Detection. The RPL Loop Detection TLV is placed details of how that RPL Packet Information is carried within the RPL
in the RPL Option with Option Type = 1 (to be confirmed by IANA), Option.
Option Data Length = 4 octets, and the Value has the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: RPL Packet Information Figure 32: RPL Packet Information
Down 'O': 1-bit flag indicating whether the packet is expected to Down 'O': 1-bit flag indicating whether the packet is expected to
skipping to change at page 96, line 33 skipping to change at page 97, line 40
If the source is aware of the RPLInstanceID that is preferred for the If the source is aware of the RPLInstanceID that is preferred for the
packet, then it MUST set the RPLInstanceID field associated with the packet, 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
RPLInstanceIDs are used to avoid loops between DODAGs from different
origins. DODAGs that are constructed for antagonistic constraints
might contain paths that, if mixed together, would yield loops.
Those loops are avoided by forwarding a packet along the DODAG that
is associated to a given instance.
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.
For a packet that is originated from outside the RPL network, the
source of the packet might be aware of the RPL network, of the
constraints imposed on OFs, and of associated RPLInstanceIDs. In
that case, the source of the packet MAY tag the flow label with the
RPLInstanceID.
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 the RPL Loop Detection TLV in a RPL Option within the packet includes an IPv6 Hop-by-Hop RPL Option, and that the RPL
the IPv6 Hop-by-Hop Option header. If one does not exist, the RPL Option contains RPL Packet Information (Figure 32). If not, then the
router MUST insert a RPL Loop Detection type as specified in 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
[I-D.ietf-6man-rpl-option]. If the router is an ingress router that router that injects the packet into the RPL network, the router MUST
injects the packet into the RPL network, the router MUST set the set the RPLInstanceID field in the RPL Packet Information. The
RPLInstanceID field in the RPL Loop Detection TLV. details of how that router determines the mapping to a RPLInstanceID
are out of scope for this specification and left to future
specification.
A router that forwards a packet to outside the RPL network MUST 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 Option as specified in [I-D.ietf-6man-rpl-option].
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
skipping to change at page 98, line 7 skipping to change at page 99, line 5
One inconsistency along the path is not considered a critical error One inconsistency along the path is not considered a critical error
and the packet may continue. But a second detection along the path and the packet may continue. But a second detection along the path
of a same packet should not occur and the packet MUST be dropped. of a same packet should not occur and the packet MUST be dropped.
This process is controlled by the Rank-Error bit associated with the This process is controlled by the Rank-Error bit associated with the
packet. When an inconsistency is detected on a packet, if the Rank- packet. When an inconsistency is detected on a packet, if the Rank-
Error bit was not set then the Rank-Error bit is set. If it was set Error bit was not set then the Rank-Error bit is set. If it was set
the packet MUST be discarded and the trickle timer MUST be reset. the packet MUST be discarded and the trickle timer MUST be reset.
11.2.2.3. DAO Inconsistency Loop Detection and Recovery 11.2.2.3. DAO Inconsistency Detection and Recovery
DAO inconsistency loop recovery is a mechanism that applies to
storing mode of operation only.
In non-storing mode, the packets are source routed to the destination
and DAO inconsistencies are not corrected locally. Instead, an ICMP
error with a new code "Error in Source Routing Header" is sent back
to the root. The "Error in Source Routing Header" message has the
same format as the "Destination Unreachable Message" as specified in
[RFC4443]. The portion of the invoking packet that is sent back in
the ICMP message should record at least up to the routing header, and
the routing header should be consumed by this node so that the
destination in the IPv6 header is the next hop that this node could
not reach.
A DAO inconsistency happens when a router has a downward route that A DAO inconsistency happens when a router has a downward route that
was previously learned from a DAO message via a child, but that was previously learned from a DAO message via a child, but that
downward route is not longer valid in the child, e.g. because that downward route is not longer valid in the child, e.g. because that
related state in the child has been cleaned up. With DAO related state in the child has been cleaned up. With DAO
inconsistency loop recovery, a packet can be used to recursively inconsistency loop recovery, a packet can be used to recursively
explore and cleanup the obsolete DAO states along a sub-DODAG. explore and cleanup the obsolete DAO states along a sub-DODAG.
In a general manner, a packet that goes Down should never go Up In a general manner, a packet that goes Down should never go Up
again. If DAO inconsistency loop recovery is applied, then the again. If DAO inconsistency loop recovery is applied, then the
router SHOULD send the packet back to the parent that passed it with router SHOULD send the packet back to the parent that passed it with
the Forwarding-Error 'F' bit set and the 'O' bit left untouched. the Forwarding-Error 'F' bit set and the 'O' bit left untouched.
Otherwise the router MUST silently discard the packet. Otherwise the router MUST silently discard the packet.
11.2.2.4. Forward Path Recovery
Upon receiving a packet with a Forwarding-Error bit set, the node Upon receiving a packet with a Forwarding-Error bit set, the node
MUST remove the routing states that caused forwarding to that MUST remove the routing states that caused forwarding to that
neighbor, clear the Forwarding-Error bit and attempt to send the neighbor, clear the Forwarding-Error bit and attempt to send the
packet again. The packet may be sent to an alternate neighbor, after packet again. The packet may be sent to an alternate neighbor, after
the expiration of a user-configurable implementation specific timer. the expiration of a user-configurable implementation specific timer.
If that alternate neighbor still has an inconsistent DAO state via If that alternate neighbor still has an inconsistent DAO state via
this node, the process will recurse, this node will set the this node, the process will recurse, this node will set the
Forwarding-Error 'F' bit and the routing state in the alternate Forwarding-Error 'F' bit and the routing state in the alternate
neighbor will be cleaned up as well. neighbor will be cleaned up as well.
skipping to change at page 100, line 6 skipping to change at page 101, line 6
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
the way from the listeners to the DODAG root, enabling the root to the way from the listeners to the DODAG root, enabling the root to
copy a multicast packet to all its children routers that had issued a copy a multicast packet to all its children routers that had issued a
DAO message including a Target option for that multicast group, as DAO message including a Target option for that multicast group, as
well as all the attached nodes that registered over MLD. well as all the attached nodes that registered over MLD.
For unicast traffic, it is expected that the grounded DODAG root acts For unicast traffic, it is expected that the grounded DODAG root acts
as an LBR and MAY redistribute the RPL routes over the external as a Low power and lossy network Border Router (LBR) and MAY
infrastructure using whatever routing protocol is used in the other redistribute the RPL routes over the external infrastructure using
routing domain. For multicast traffic, the root MAY proxy MLD for whatever routing protocol is used in the other routing domain. For
all the nodes attached to the RPL domain (this would be needed if the multicast traffic, the root MAY proxy MLD for all the nodes attached
multicast source is located in the external infrastructure). For to the RPL domain (this would be needed if the multicast source is
such a source, the packet will be replicated as it flows Down the located in the external infrastructure). For such a source, the
DODAG based on the multicast routing table entries installed from the packet will be replicated as it flows Down the DODAG based on the
DAO message. multicast routing table entries installed from the DAO message.
For a multicast packet sourced from inside the DODAG, the packet is For a multicast packet sourced from inside the DODAG, the packet is
passed to the preferred parents, and if that fails then to the passed to the preferred parents, and if that fails then to the
alternates in the DODAG. The packet is also copied to all the alternates in the DODAG. The packet is also copied to all the
registered children, except for the one that passed the packet. registered children, except for the one that passed the packet.
Finally, if there is a listener in the external infrastructure then Finally, if there is a listener in the external infrastructure then
the DODAG root has to further propagate the packet into the external the DODAG root has to further propagate the packet into the external
infrastructure. infrastructure.
As a result, the DODAG Root acts as an automatic proxy Rendezvous As a result, the DODAG Root acts as an automatic proxy Rendezvous
skipping to change at page 102, line 21 skipping to change at page 103, line 21
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
Objective Code Point (OCP), and indicates the method that must be Objective Code Point (OCP), and indicates the method that must be
used to construct the DODAG. The Objective Code Points are specified used to construct the DODAG. The Objective Code Points are specified
in [I-D.ietf-roll-of0], and related companion specifications. in [I-D.ietf-roll-of0], and related companion specifications.
14.1. Objective Function Behavior 14.1. Objective Function Behavior
Most Objective Functions are expected to follow the same abstract Most Objective Functions are expected to follow the same abstract
behavior: behavior at a node:
o The parent selection is triggered each time an event indicates o The parent selection is triggered each time an event indicates
that a potential next hop information is updated. This might that a potential next hop information is updated. This might
happen upon the reception of a DIO message, a timer elapse, all happen upon the reception of a DIO message, a timer elapse, all
DODAG parents are unavailable, or a trigger indicating that the DODAG parents are unavailable, or a trigger indicating that the
state of a candidate neighbor has changed. state of a candidate neighbor has changed.
o An OF scans all the interfaces on the device. Although there may o An OF scans all the interfaces on the node. Although there may
typically be only one interface in most application scenarios, typically be only one interface in most application scenarios,
there might be multiple of them and an interface might be there might be multiple of them and an interface might be
configured to be usable or not for RPL operation. An interface configured to be usable or not for RPL operation. An interface
can also be configured with a preference or dynamically learned to can also be configured with a preference or dynamically learned to
be better than another by some heuristics that might be link-layer be better than another by some heuristics that might be link-layer
dependent and are out of scope. Finally an interface might or not dependent and are out of scope for this specification. Finally an
match a required criterion for an Objective Function, for instance interface might or not match a required criterion for an Objective
a degree of security. As a result, some interfaces might be Function, for instance a degree of security. As a result, some
completely excluded from the computation, for example if those interfaces might be completely excluded from the computation, for
interfaces cannot satisfy some advertised constraints, while example if those interfaces cannot satisfy some advertised
others might be more or less preferred. constraints, while others might be more or less preferred.
o An OF scans all the candidate neighbors on the possible interfaces o An OF scans all the candidate neighbors on the possible interfaces
to check whether they can act as a router for a DODAG. There to check whether they can act as a router for a DODAG. There
might be multiple of them and a candidate neighbor might need to might be multiple of them and a candidate neighbor might need to
pass some validation tests before it can be used. In particular, pass some validation tests before it can be used. In particular,
some link layers require experience on the activity with a router some link layers require experience on the activity with a router
to enable the router as a next hop. to enable the router as a next hop.
o An OF computes self's rank by adding to the rank of the candidate o An OF computes rank of a node for comparison by adding to the rank
a value representing the relative locations of self and the of the candidate a value representing the relative locations of
candidate in the DODAG Version. the node and the candidate in the DODAG Version.
* The increase in rank must be at least MinHopRankIncrease. * The increase in rank must be at least MinHopRankIncrease.
* To keep loop avoidance and metric optimization in alignment, * To keep loop avoidance and metric optimization in alignment,
the increase in rank should reflect any increase in the metric the increase in rank should reflect any increase in the metric
value. For example, with a purely additive metric such as ETX, value. For example, with a purely additive metric such as ETX,
the increase in rank can be made proportional to the increase the increase in rank can be made proportional to the increase
in the metric. in the metric.
* Candidate neighbors that would cause self's rank to increase * Candidate neighbors that would cause the rank of the node to
are not considered for parent selection. increase are not considered for parent selection.
o Candidate neighbors that advertise an OF incompatible with the set o Candidate neighbors that advertise an OF incompatible with the set
of OF specified by the policy functions are ignored. of OF specified by the policy functions are ignored.
o As it scans all the candidate neighbors, the OF keeps the current o As it scans all the candidate neighbors, the OF keeps the current
best parent and compares its capabilities with the current best parent and compares its capabilities with the current
candidate neighbor. The OF defines a number of tests that are candidate neighbor. The OF defines a number of tests that are
critical to reach the objective. A test between the routers critical to reach the objective. A test between the routers
determines an order relation. determines an order relation.
* If the routers are equal for that relation then the next test * If the routers are equal for that relation then the next test
is attempted between the routers, is attempted between the routers,
* Else the best of the two routers becomes the current best * Else the best of the two routers becomes the current best
parent and the scan continues with the next candidate neighbor. parent and the scan continues with the next candidate neighbor.
* Some OFs may include a test to compare the ranks that would * Some OFs may include a test to compare the ranks that would
result if the node joined either router. result if the node joined either router.
o When the scan is complete, the preferred parent is elected and o When the scan is complete, the preferred parent is elected and the
self's rank is computed as the preferred parent rank plus the step node's rank is computed as the preferred parent rank plus the step
in rank with that parent. in rank with that parent.
o Other rounds of scans might be necessary to elect alternate o Other rounds of scans might be necessary to elect alternate
parents. In the next rounds: parents. In the next rounds:
* Candidate neighbors that are not in the same DODAG are ignored. * Candidate neighbors that are not in the same DODAG are ignored.
* Candidate neighbors that are of greater rank than self are * Candidate neighbors that are of greater rank than the node are
ignored. ignored.
* Candidate neighbors of an equal rank to self are ignored for * Candidate neighbors of an equal rank to the node are ignored
parent selection. for parent selection.
* Candidate neighbors of a lesser rank than self are preferred. * Candidate neighbors of a lesser rank than the node are
preferred.
15. Suggestions for Interoperation with Neighbor Discovery 15. Suggestions for Interoperation with Neighbor Discovery
This specification directly borrows the Prefix Information Option This specification directly borrows the Prefix Information Option
(PIO) and the Routing Information Option (RIO) from IPv6 ND. It is (PIO) and the Routing Information Option (RIO) from IPv6 ND. It is
envisioned that, as future specifications build on this base, there envisioned that, as future specifications build on this base, there
may be additional cause to leverage parts of IPv6 ND. This section may be additional cause to leverage parts of IPv6 ND. This section
provides some suggestions for future specifications. provides some suggestions for future specifications.
First and foremost RPL is a routing protocol. One should take great First and foremost RPL is a routing protocol. One should take great
skipping to change at page 108, line 22 skipping to change at page 109, line 22
protocol parameters for which configuration management is relevant. protocol parameters for which configuration management is relevant.
Some of the RPL parameters are optional. The requirements for Some of the RPL parameters are optional. The requirements for
configuration are only applicable for the options that are used. configuration are only applicable for the options that are used.
17.2.1. Initialization Mode 17.2.1. Initialization Mode
"Architectural Principles of the Internet" [RFC1958], Section 3.8, "Architectural Principles of the Internet" [RFC1958], Section 3.8,
states: "Avoid options and parameters whenever possible. Any options states: "Avoid options and parameters whenever possible. Any options
and parameters should be configured or negotiated dynamically rather and parameters should be configured or negotiated dynamically rather
than manually. This is especially true in LLNs where the number of than manually." This is especially true in LLNs where the number of
devices may be large and manual configuration is infeasible. This devices may be large and manual configuration is infeasible. This
has been taken into account in the design of RPL whereby the DODAG has been taken into account in the design of RPL whereby the DODAG
root provides a number of parameters to the devices joining the root provides a number of parameters to the devices joining the
DODAG, thus avoiding cumbersome configuration on the routers and DODAG, thus avoiding cumbersome configuration on the routers and
potential sources of misconfiguration (e.g. values of trickle timers, potential sources of misconfiguration (e.g. values of trickle timers,
...). Still there are additional RPL parameters that a RPL ...). Still there are additional RPL parameters that a RPL
implementation should allow to be configured, which are discussed in implementation should allow to be configured, which are discussed in
this section. this section.
17.2.1.1. DIS mode of operation upon boot-up 17.2.1.1. DIS mode of operation upon boot-up
skipping to change at page 110, line 22 skipping to change at page 111, line 22
Information option] Information option]
17.2.4. Protocol Parameters to be configured on every non-DODAG-root 17.2.4. Protocol Parameters to be configured on every non-DODAG-root
router in the LLN router in the LLN
A RPL implementation MUST allow configuring the Target prefix [DAO A RPL implementation MUST allow configuring the Target prefix [DAO
message, in RPL Target option]. message, in RPL Target option].
Furthermore, there are circumstances where a node may want to Furthermore, there are circumstances where a node may want to
designate a Target to allow for specific processing of the Target designate a Target to allow for specific processing of the Target
(prioritization, ...). Such processing rules are out of the scope of (prioritization, ...). Such processing rules are out of scope for
this document. When used, a RPL implementation SHOULD allow this specification. When used, a RPL implementation SHOULD allow
configuring the Target Descriptor on a per-Target basis (for example configuring the Target Descriptor on a per-Target basis (for example
using access lists). using access lists).
A node whose DODAG parent set is empty may become the DODAG root of a A node whose DODAG parent set is empty may become the DODAG root of a
floating DODAG. It may also set its DAGPreference such that it is floating DODAG. It may also set its DAGPreference such that it is
less preferred. Thus a RPL implementation MUST allow configuring the less preferred. Thus a RPL implementation MUST allow configuring the
set of actions that the node should initiate in this case: set of actions that the node should initiate in this case:
o Start its own (floating) DODAG: the new DODAGID must be configured o Start its own (floating) DODAG: the new DODAGID must be configured
in addition to its DAGPreference. in addition to its DAGPreference.
skipping to change at page 112, line 15 skipping to change at page 113, line 15
A RPL implementation MAY allow for configuring a set of rules A RPL implementation MAY allow for configuring a set of rules
specifying the triggers for DTSN increment (manual or event-based). specifying the triggers for DTSN increment (manual or event-based).
When a DAO entry times out or is invalidated, a node SHOULD make a When a DAO entry times out or is invalidated, a node SHOULD make a
reasonable attempt to report a No-Path to each of the DAO parents. reasonable attempt to report a No-Path to each of the DAO parents.
That number of attempts MAY be configurable. That number of attempts MAY be configurable.
An implementation should support rate-limiting the sending of DAO An implementation should support rate-limiting the sending of DAO
messages. The related parameters MAY be configurable. messages. The related parameters MAY be configurable.
17.2.7. Default Values 17.2.7. Configuration of RPL Parameters related to Security mechanisms
As described in Section 10, the security features described in this
document are optional to implement and a given implementation may
support a subset (including the empty set) of the described security
features.
To this end an implementation supporting described security features
may conceptually implement a security policy database. In support of
the security mechanisms, a RPL implementation SHOULD allow for
configuring a subset of the following parameters:
o Security Modes accepted [Unsecured mode, Pre-Installed mode,
Authenticated mode]
o KIM values accepted [Secure RPL Control messages, in Security
Section]
o Level values accepted [Secure RPL Control messages, in Security
section]
o Algorithm values accepted [Secure RPL Control messages, in
Security section]
o Key material in support of Authenticated or Pre-Installed key
modes.
In addition, a RPL implementation SHOULD allow for configuring a
DODAG root with a subset of the following parameters:
o Level values advertised [Secure DIO message, in Security Section]
o KIM value advertised [Secure DIO message, in Security Section]
o Algorithm value advertised [Secure DIO message, in Security
Section]
17.2.8. Default Values
This document specifies default values for the following set of RPL This document specifies default values for the following set of RPL
variables: variables:
DEFAULT_PATH_CONTROL_SIZE DEFAULT_PATH_CONTROL_SIZE
DEFAULT_DIO_INTERVAL_MIN DEFAULT_DIO_INTERVAL_MIN
DEFAULT_DIO_INTERVAL_DOUBLINGS DEFAULT_DIO_INTERVAL_DOUBLINGS
DEFAULT_DIO_REDUNDANCY_CONSTANT DEFAULT_DIO_REDUNDANCY_CONSTANT
DEFAULT_MIN_HOP_RANK_INCREASE DEFAULT_MIN_HOP_RANK_INCREASE
It is recommended to specify default values in protocols; that being It is recommended to specify default values in protocols; that being
skipping to change at page 119, line 9 skipping to change at page 120, line 48
and required bandwidth. Still, RPL implementation MAY support some and required bandwidth. Still, RPL implementation MAY support some
of these, and other parameters of interest are listed below: of these, and other parameters of interest are listed below:
o Number of repairs and time to repair in seconds (average, o Number of repairs and time to repair in seconds (average,
variance) variance)
o Number of times and duration during which a devices could not o Number of times and duration during which a devices could not
forward a packet because of a lack of reachable neighbor in its forward a packet because of a lack of reachable neighbor in its
routing table routing table
o Monitoring of resources consumption by RPL itself in terms of o Monitoring of resources consumption by RPL in terms of bandwidth
bandwidth and required memory and required memory
o Number of RPL control messages sent and received o Number of RPL control messages sent and received
18. Security Considerations 18. Security Considerations
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
skipping to change at page 120, line 30 skipping to change at page 122, line 30
fixed infrastructure and might involve short-term relationships fixed infrastructure and might involve short-term relationships
between devices that may never have communicated before. These between devices that may never have communicated before. These
constraints might severely limit the choice of cryptographic constraints might severely limit the choice of cryptographic
algorithms and protocols and influence the design of the security algorithms and protocols and influence the design of the security
architecture because the establishment and maintenance of trust architecture because the establishment and maintenance of trust
relationships between devices need to be addressed with care. In relationships between devices need to be addressed with care. In
addition, battery lifetime and cost constraints put severe limits on addition, battery lifetime and cost constraints put severe limits on
the security overhead these networks can tolerate, something that is the security overhead these networks can tolerate, something that is
of far less concern with higher bandwidth networks. Most of these of far less concern with higher bandwidth networks. Most of these
security architectural elements can be implemented at higher layers security architectural elements can be implemented at higher layers
and may, therefore, be considered to be outside the scope of this and may, therefore, be considered to be out of scope for this
standard. Special care, however, needs to be exercised with respect specification. Special care, however, needs to be exercised with
to interfaces to these higher layers. respect to 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 outside the scope of this standard. The mechanisms assume a keys are out of scope for this specification. The mechanisms assume
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:
Data confidentiality: Assurance that transmitted information is only Data confidentiality: Assurance that transmitted information is only
disclosed to parties for which it is intended. disclosed to parties for which it is intended.
Data authenticity: Assurance of the source of transmitted Data authenticity: Assurance of the source of transmitted
information (and, hereby, that information was not information (and, hereby, that information was not
skipping to change at page 122, line 22 skipping to change at page 124, line 22
RPL operation. RPL operation.
IANA has defined an ICMPv6 Type Number Registry. The suggested type IANA has defined an ICMPv6 Type Number Registry. The suggested type
value for the RPL Control Message is 155, to be confirmed by IANA. value for the RPL Control Message is 155, to be confirmed by IANA.
19.2. New Registry for RPL Control Codes 19.2. New Registry for RPL Control Codes
IANA is requested to create a registry, RPL Control Codes, for the IANA is requested to create a registry, RPL Control Codes, for the
Code field of the ICMPv6 RPL Control Message. Code field of the ICMPv6 RPL Control Message.
New codes may be allocated only by an IETF Consensus action. Each New codes may be allocated only by an IETF Review. Each code should
code should be tracked with the following qualities: be tracked with the following qualities:
o Code o Code
o Description o Description
o Defining RFC o Defining RFC
Three codes are currently defined: Three codes are currently defined:
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
skipping to change at page 123, line 15 skipping to change at page 125, line 15
| | | document | | | | document |
| | | | | | | |
| 0x83 | Secure Destination Advertisement Object | This | | 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document | | | Acknowledgment | document |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
RPL Control Codes RPL Control Codes
19.3. New Registry for the Mode of Operation (MOP) DIO Control Field 19.3. New Registry for the Mode of Operation (MOP) DIO Control Field
IANA is requested to create a registry for the Mode of Operation IANA is requested to create a registry for the 3-bit Mode of
(MOP) DIO Control Field, which is contained in the DIO Base. Operation (MOP) DIO Control Field, which is contained in the DIO
Base.
New fields may be allocated only by an IETF Consensus action. Each New values may be allocated only by an IETF Review. Each value
field should be tracked with the following qualities: should be tracked with the following qualities:
o Mode of Operation o Mode of Operation Value
o Capability description o Capability description
o Defining RFC o Defining RFC
Three values are currently defined: Four values are currently defined:
+-----+----------------------------------------------+--------------+ +----------+------------------------------------------+-------------+
| MOP | Description | Reference | | MOP | Description | Reference |
+-----+----------------------------------------------+--------------+ | value | | |
| 000 | No downward routes maintained by RPL | This | +----------+------------------------------------------+-------------+
| | | document | | 0 | No downward routes maintained by RPL | This |
| | | | | | | document |
| 001 | Non-Storing mode of operation | This | | | | |
| | | document | | 1 | Non-Storing mode of operation | This |
| | | | | | | document |
| 010 | Storing mode of operation with no multicast | This | | | | |
| | support | document | | 2 | Storing mode of operation with no | This |
| | | | | | multicast support | document |
| 011 | Storing mode of operation with multicast | This | | | | |
| | support | document | | 3 | Storing mode of operation with multicast | This |
+-----+----------------------------------------------+--------------+ | | support | document |
+----------+------------------------------------------+-------------+
DIO Mode of operation DIO Mode of operation
The rest of the range, decimal 4 to 7, is currently unassigned.
19.4. RPL Control Message Option 19.4. RPL Control Message Option
IANA is requested to create a registry for the RPL Control Message IANA is requested to create a registry for the RPL Control Message
Options Options
New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities:
o Value
o Meaning
o Defining RFC
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| 0 | Pad1 | This document | | 0 | Pad1 | This document |
| | | | | | | |
| 1 | PadN | This document | | 1 | PadN | This document |
| | | | | | | |
| 2 | DAG Metric Container | This Document | | 2 | DAG Metric Container | This Document |
| | | | | | | |
| 3 | Routing Information | This Document | | 3 | Routing Information | This Document |
skipping to change at page 124, line 37 skipping to change at page 126, line 52
RPL Control Message Options RPL Control Message Options
19.5. Objective Code Point (OCP) Registry 19.5. Objective Code Point (OCP) Registry
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a registry to manage the codespace of the
Objective Code Point (OCP) field. Objective Code Point (OCP) field.
No OCP codepoints are defined in this specification. No OCP codepoints are defined in this specification.
19.6. New Registry for the Security Section Flags New codes may be allocated only by an IETF Review. Each code should
be tracked with the following qualities:
o OCP code
o Description
o Defining RFC
19.6. New Registry for the Security Section Algorithm
IANA is requested to create a registry for the values of 8-bit
Algorithm field in the Security Section.
New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities:
o Value
o Encryption/MAC
o Signature
o Defining RFC
The following value is currently defined:
+-------+------------------+---------------+---------------+
| Value | Encryption/MAC | Signature | Reference |
+-------+------------------+---------------+---------------+
| 0 | CCM with AES-128 | RSA with SHA2 | This document |
+-------+------------------+---------------+---------------+
Security Section Algorithm
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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
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.7. New Registry for the Key Identification Mode 19.8. New Registry for the Key Identification Mode
IANA is requested to create a registry for the 3-bit Key IANA is requested to create a registry for the 3-bit Key
Identification Mode Field. Identification Mode Field.
New values may be allocated only by an IETF Consensus action. Each New values may be allocated only by an IETF Review. Each value
value should be tracked with the following qualities: should be tracked with the following qualities:
o Value o Value
o Description o Description
o Defining RFC o Defining RFC
The following values are currently defined: The following values are currently defined:
+-------+---------------+---------------+ +-------+---------------+---------------+
skipping to change at page 125, line 35 skipping to change at page 128, line 36
| | | | | | | |
| 1 | See Figure 11 | This document | | 1 | See Figure 11 | This document |
| | | | | | | |
| 2 | See Figure 11 | This document | | 2 | See Figure 11 | This document |
| | | | | | | |
| 3 | See Figure 11 | This document | | 3 | See Figure 11 | This document |
+-------+---------------+---------------+ +-------+---------------+---------------+
Key Identification Mode Key Identification Mode
19.8. New Registry for the KIM levels 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 7-bit KIM level
Field per allocated KIM value. 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
Consensus action. Each level should be tracked with the following Review. Each level should be tracked with the following qualities:
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 9 | This document |
| | | | | | | | | |
| 1 | 0 | See Figure 9 | This document | | 1 | 0 | See Figure 9 | This document |
skipping to change at page 126, line 39 skipping to change at page 129, line 42
| | | | | | | | | |
| 3 | 2 | See Figure 9 | This document | | 3 | 2 | See Figure 9 | This document |
| | | | | | | | | |
| 0 | 3 | See Figure 9 | This document | | 0 | 3 | See Figure 9 | This document |
| | | | | | | | | |
| 1 | 3 | See Figure 9 | This document | | 1 | 3 | See Figure 9 | This document |
+-------+-----------+--------------+---------------+ +-------+-----------+--------------+---------------+
KIM levels KIM levels
19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags 19.10. New Registry for the DIS (DODAG Informational Solicitation)
Flags
IANA is requested to create a registry for the DIS (DODAG IANA is requested to create a registry for the DIS (DODAG
Informational Solicitation) Flag Field. Informational Solicitation) Flag Field.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
Each bit should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the DIS (DODAG Informational No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags. Solicitation) Flags.
19.10. New Registry for the DODAG Information Object (DIO) Flags 19.11. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
Each bit should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the DIS (DODAG Informational No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags. Solicitation) Flags.
19.11. New Registry for the Destination Advertisement Object (DAO) 19.12. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
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
The following bits are currently defined: The following bits are currently defined:
+------------+--------------------------+---------------+ +------------+--------------------------+---------------+
| 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.12. New Registry for the Destination Advertisement Object (DAO) 19.13. New Registry for the Destination Advertisement Object (DAO)
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) Flag Field. Advertisement Object (DAO) Acknowledgement Flag Field.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
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
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.13. New Registry for the Consistency Check (CC) Flags 19.14. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
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
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 |
+------------+-------------+---------------+ +------------+-------------+---------------+
skipping to change at page 129, line 5 skipping to change at page 132, line 16
The following bit is currently defined: The following bit is currently defined:
+------------+-------------+---------------+ +------------+-------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-------------+---------------+ +------------+-------------+---------------+
| 0 | CC Response | This document | | 0 | CC Response | This document |
+------------+-------------+---------------+ +------------+-------------+---------------+
Consistency Check Base Flags Consistency Check Base Flags
19.14. New Registry for the DODAG Configuration Option Flags 19.15. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
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
The following bits are currently defined: The following bits are currently defined:
+------------+------------------------+---------------+ +------------+------------------------+---------------+
| 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.15. New Registry for the RPL Target Option Flags 19.16. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
Each bit should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
No bit is currently defined for the RPL Target Option Flags. No bit is currently defined for the RPL Target Option Flags.
19.16. New Registry for the Transit Information Option Flags 19.17. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities:
Each bit 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
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.17. New Registry for the Solicited Information Option Flags 19.18. 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 Consensus action. New bit numbers may be allocated only by an IETF Review. Each bit
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
The following bits are currently defined: The following bits are currently defined:
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
skipping to change at page 131, line 5 skipping to change at page 134, line 17
+------------+----------------------------+---------------+ +------------+----------------------------+---------------+
| 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.18. ICMPv6: Error in Source Routing Header 19.19. ICMPv6: Error in Source Routing Header
In some cases RPL will return an ICMPv6 error message when a message In some cases RPL will return an ICMPv6 error message when a message
cannot be delivered as specified by its source routing header. This cannot be delivered as specified by its source routing header. This
ICMPv6 error message is "Error in Source Routing Header". ICMPv6 error message is "Error in Source Routing Header".
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
Types. ICMPv6 Message Type 1 describes "Destination Unreachable" Types. ICMPv6 Message Type 1 describes "Destination Unreachable"
codes. The "Error in Source Routing Header" code is suggested to be codes. The "Error in Source Routing Header" code is suggested to be
allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message
Type 1, with a suggested code value of 7, to be confirmed by IANA. Type 1, with a suggested code value of 7, to be confirmed by IANA.
19.19. Link-Local Scope multicast address 19.20. 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
comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel, comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel,
Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Mischa Dohler, Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa
Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar
Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Ajay Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko,
Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru
Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep
Tripathi, and Nicolas Tsiftes. Tripathi, and Nicolas Tsiftes.
The authors would like to acknowledge the guidance and input provided The authors would like to acknowledge the guidance and input provided
by the ROLL Chairs, David Culler and JP Vasseur. by the ROLL Chairs, David Culler and JP Vasseur, and the Area
Director Adrian Farrel.
The authors would like to acknowledge prior contributions of Robert The authors would like to acknowledge prior contributions of Robert
Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon,
Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom
have provided useful design considerations to RPL. have provided useful design considerations to RPL.
RPL Security Design, found in Section 10, Section 18, and elsewhere RPL Security Design, found in Section 10, Section 18, and elsewhere
throughout the document, is primarily the contribution of the throughout the document, is primarily the contribution of the
Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
Levis, Kris Pister, and Rene Struik. Levis, Kris Pister, Rene Struik, and Adrian Farrel.
21. Contributors 21. Contributors
RPL is the result of the contribution of the following members of the
RPL Author Team, including the editors, and additional contributors
as listed below in alphabetical order:
Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen, DK-2100
Denmark
Email: abr@sdesigns.dk
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Stephen Dawson-Haggerty Stephen Dawson-Haggerty
UC Berkeley UC Berkeley
Soda Hall, UC Berkeley Soda Hall, UC Berkeley
Berkeley, CA 94720 Berkeley, CA 94720
USA USA
Email: stevedh@cs.berkeley.edu Email: stevedh@cs.berkeley.edu
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, CA 94107
USA
Email: jhui@archrock.com
Richard Kelsey
Ember Corporation
Boston, MA
USA
Phone: +1 617 951 1225
Email: kelsey@ember.com
Philip Levis
Stanford University
358 Gates Hall, Stanford University
Stanford, CA 94305-9030
USA
Email: pal@cs.stanford.edu
Kris Pister
Dust Networks
30695 Huntwood Ave.
Hayward, 94544
USA
Email: kpister@dustnetworks.com
R. Struik
Email: rstruik.ext@gmail.com
JP Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782
France
Email: jpv@cisco.com
22. References 22. References
22.1. Normative References 22.1. Normative References
[I-D.ietf-6man-rpl-option] [I-D.ietf-6man-rpl-option]
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
Information in Data-Plane Datagrams", Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-00 (work in progress), draft-ietf-6man-rpl-option-00 (work in progress),
July 2010. July 2010.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing
Header for Source Routes with RPL", Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-00 (work in progress), draft-ietf-6man-rpl-routing-header-00 (work in progress),
July 2010. July 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Networks, D., Dejean, N., and D. Vasseur, J., Kim, M., Networks, D., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-08 (work in progress), draft-ietf-roll-routing-metrics-09 (work in progress),
July 2010. September 2010.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Gnawali, O., Clausen, T., Hui, J., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", draft-ietf-roll-trickle-02 (work "The Trickle Algorithm", draft-ietf-roll-trickle-04 (work
in progress), July 2010. in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
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.
22.2. Informative References 22.2. Informative References
[CCMStar] IEEE, "IEEE Std. 802.15.4-2006, IEEE Standard for
Information Technology - Telecommunications and
Information Exchange between Systems - Local and
Metropolitan Area Networks - Specific requirements Part
15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs)", IEEE Press Revision of IEEE Std
802.15.4-2003, 2006.
[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]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-03 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), March 2010. progress), September 2010.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks 7: 395-405, Information", North-Holland Computer Networks 7: 395-405,
1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/ 1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/
readings/p83.pdf>. readings/p83.pdf>.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
skipping to change at page 137, line 26 skipping to change at page 139, line 23
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.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[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.
skipping to change at page 138, line 16 skipping to change at page 140, line 9
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 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, June 2010.
[sha2] "FIPS Pub 180-3, Secure Hash Standard (SHS)", , [SHA2] National Institute of Standards and Technology, "FIPS Pub
February 2008. 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 Cisco Systems, Inc
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
RPL Author Team Anders Brandt
IETF ROLL WG Sigma Designs
Emdrupvej 26A, 1.
Copenhagen DK-2100
Denmark
Email: rpl-authors@external.cisco.com Email: abr@sdesigns.dk
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, CA 94107
USA
Email: jhui@archrock.com
Richard Kelsey
Ember Corporation
Boston, MA
USA
Phone: +1 617 951 1225
Email: kelsey@ember.com
Philip Levis
Stanford University
358 Gates Hall, Stanford University
Stanford, CA 94305-9030
USA
Email: pal@cs.stanford.edu
Kris Pister
Dust Networks
30695 Huntwood Ave.
Hayward, CA 94544
USA
Email: kpister@dustnetworks.com
Rene Struik
Email: rstruik.ext@gmail.com
JP Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
Issy Les Moulineaux 92782
France
Email: jpv@cisco.com
 End of changes. 181 change blocks. 
546 lines changed or deleted 658 lines changed or added

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