< draft-ietf-roll-rpl-09.txt   draft-ietf-roll-rpl-10.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: December 13, 2010 Cisco Systems Expires: December 30, 2010 Cisco Systems
RPL Author Team RPL Author Team
IETF ROLL WG IETF ROLL WG
Jun 11, 2010 Jun 28, 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-09 draft-ietf-roll-rpl-10
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 (any subset of) processing
power, memory and energy (battery), and their interconnects are power, memory and energy (battery), and their interconnects are
characterized by (any subset of) high loss rates, low data rates and characterized by (any subset of) high loss rates, low data rates and
instability. LLNs are comprised of anything from a few dozen and up instability. LLNs are comprised of anything from a few dozen and up
to thousands of routers, and support point-to-point traffic (between to thousands of routers, and support point-to-point traffic (between
skipping to change at page 1, line 35 skipping to change at page 1, line 35
to-point traffic (from devices inside the LLN towards a central to-point traffic (from devices inside the LLN towards a central
control point). This document specifies the IPv6 Routing Protocol control point). This document specifies the IPv6 Routing Protocol
for LLNs (RPL), which provides a mechanism whereby multipoint-to- for LLNs (RPL), which provides a mechanism whereby multipoint-to-
point traffic from devices inside the LLN towards a central control point traffic from devices inside the LLN towards a central control
point, as well as point-to-multipoint traffic from the central point, as well as point-to-multipoint traffic from the central
control point to the devices inside the LLN, is supported. Support control point to the devices inside the LLN, is supported. Support
for point-to-point traffic is also available. for point-to-point traffic is also available.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 30, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Design Principles . . . . . . . . . . . . . . . . . . . 6 1.1. Design Principles . . . . . . . . . . . . . . . . . . . 6
1.2. Expectations of Link Layer Type . . . . . . . . . . . . 7 1.2. Expectations of Link Layer Type . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Topology Identifiers . . . . . . . . . . . . . . . . 9 3.1.1. Topology Identifiers . . . . . . . . . . . . . . . . 11
3.2. Instances, DODAGs, and DODAG Versions . . . . . . . . . 10 3.2. Instances, DODAGs, and DODAG Versions . . . . . . . . . 11
3.3. Upward Routes and DODAG Construction . . . . . . . . . . 12 3.3. Upward Routes and DODAG Construction . . . . . . . . . . 13
3.3.1. Objective Function (OF) . . . . . . . . . . . . . . . 12 3.3.1. Objective Function (OF) . . . . . . . . . . . . . . . 14
3.3.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 3.3.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 14
3.3.3. Security . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Security . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Grounded and Floating DODAGs . . . . . . . . . . . . 13 3.3.4. Grounded and Floating DODAGs . . . . . . . . . . . . 14
3.3.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 13 3.3.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 14
3.3.6. Administrative Preference . . . . . . . . . . . . . . 13 3.3.6. Administrative Preference . . . . . . . . . . . . . . 15
3.3.7. Datapath Validation and Loop Detection . . . . . . . 13 3.3.7. Datapath Validation and Loop Detection . . . . . . . 15
3.3.8. Distributed Algorithm Operation . . . . . . . . . . . 13 3.3.8. Distributed Algorithm Operation . . . . . . . . . . . 15
3.4. Downward Routes and Destination Advertisement . . . . . 14 3.4. Downward Routes and Destination Advertisement . . . . . 15
3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 14 3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 16
3.6. Routing Metrics and Constraints Used By RPL . . . . . . 14 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 16
3.6.1. Loop Avoidance . . . . . . . . . . . . . . . . . . . 15 3.6.1. Loop Avoidance . . . . . . . . . . . . . . . . . . . 17
3.6.2. Rank Properties . . . . . . . . . . . . . . . . . . . 17 3.6.2. Rank Properties . . . . . . . . . . . . . . . . . . . 18
3.7. Traffic Flows Supported by RPL . . . . . . . . . . . . . 19 3.7. Traffic Flows Supported by RPL . . . . . . . . . . . . . 20
3.7.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . 19 3.7.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . 21
3.7.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . 19 3.7.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . 21
3.7.3. Point-to-Point Traffic . . . . . . . . . . . . . . . 20 3.7.3. Point-to-Point Traffic . . . . . . . . . . . . . . . 21
4. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 20 4. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 20 4.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 22
5. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 21 5. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 24
5.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 23 5.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 25
5.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 28 5.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 30
5.2.1. Format of the DIS Base Object . . . . . . . . . . . . 28 5.2.1. Format of the DIS Base Object . . . . . . . . . . . . 30
5.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 29 5.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 31
5.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 29 5.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 31
5.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 29 5.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 31
5.3.1. Format of the DIO Base Object . . . . . . . . . . . . 29 5.3.1. Format of the DIO Base Object . . . . . . . . . . . . 31
5.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 31 5.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 33
5.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 31 5.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 33
5.4. Destination Advertisement Object (DAO) . . . . . . . . . 32 5.4. Destination Advertisement Object (DAO) . . . . . . . . . 33
5.4.1. Format of the DAO Base Object . . . . . . . . . . . . 32 5.4.1. Format of the DAO Base Object . . . . . . . . . . . . 34
5.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 33 5.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 34
5.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 33 5.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 35
5.5. Destination Advertisement Object Acknowledgement 5.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 33 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 33 5.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 35
5.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 34 5.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 36
5.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 35 5.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 36
5.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 35 5.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 36
5.6.1. Format of the CC Base Object . . . . . . . . . . . . 35 5.6.1. Format of the CC Base Object . . . . . . . . . . . . 36
5.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 36 5.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 38
5.7. RPL Control Message Options . . . . . . . . . . . . . . 36 5.7. RPL Control Message Options . . . . . . . . . . . . . . 38
5.7.1. RPL Control Message Option Generic Format . . . . . . 36 5.7.1. RPL Control Message Option Generic Format . . . . . . 38
5.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 37 5.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 37 5.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7.4. Metric Container . . . . . . . . . . . . . . . . . . 38 5.7.4. Metric Container . . . . . . . . . . . . . . . . . . 40
5.7.5. Route Information . . . . . . . . . . . . . . . . . . 38 5.7.5. Route Information . . . . . . . . . . . . . . . . . . 40
5.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 40 5.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 42
5.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 41 5.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 43
5.7.8. Transit Information . . . . . . . . . . . . . . . . . 42 5.7.8. Transit Information . . . . . . . . . . . . . . . . . 45
5.7.9. Solicited Information . . . . . . . . . . . . . . . . 44 5.7.9. Solicited Information . . . . . . . . . . . . . . . . 46
5.7.10. Prefix Information . . . . . . . . . . . . . . . . . 45 5.7.10. Prefix Information . . . . . . . . . . . . . . . . . 48
6. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 47 6. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 51
7. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 53
7.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 48 7.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 53
7.2. Upward Route Discovery and Maintenance . . . . . . . . . 49 7.2. Upward Route Discovery and Maintenance . . . . . . . . . 53
7.2.1. Neighbors and Parents within a DODAG Version . . . . 49 7.2.1. Neighbors and Parents within a DODAG Version . . . . 53
7.2.2. Neighbors and Parents across DODAG Versions . . . . . 50 7.2.2. Neighbors and Parents across DODAG Versions . . . . . 54
7.2.3. DIO Message Communication . . . . . . . . . . . . . . 54 7.2.3. DIO Message Communication . . . . . . . . . . . . . . 58
7.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 54 7.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 59
7.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 55 7.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 60
7.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 56 7.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 60
7.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 56 7.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 60
7.6. Administrative Rank . . . . . . . . . . . . . . . . . . 57 7.6. Administrative Rank . . . . . . . . . . . . . . . . . . 61
8. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 57 8. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Destination Advertisement Parents . . . . . . . . . . . 57 8.1. Destination Advertisement Parents . . . . . . . . . . . 62
8.2. Downward Route Discovery and Maintenance . . . . . . . . 58 8.2. Downward Route Discovery and Maintenance . . . . . . . . 62
8.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 58 8.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 63
8.4. DAO Transmission Scheduling . . . . . . . . . . . . . . 59 8.4. DAO Transmission Scheduling . . . . . . . . . . . . . . 64
8.5. Triggering DAO Messages . . . . . . . . . . . . . . . . 59 8.5. Triggering DAO Messages . . . . . . . . . . . . . . . . 64
8.6. Structure of DAO Messages . . . . . . . . . . . . . . . 60 8.6. Structure of DAO Messages . . . . . . . . . . . . . . . 65
8.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 60 8.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 65
8.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 61 8.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 66
8.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 62 8.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 67
8.10. Multicast Destination Advertisement Messages . . . . . . 63 8.10. Multicast Destination Advertisement Messages . . . . . . 68
9. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 64 9. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 69
9.1. Security Overview . . . . . . . . . . . . . . . . . . . 64 9.1. Security Overview . . . . . . . . . . . . . . . . . . . 69
9.2. Installing Keys . . . . . . . . . . . . . . . . . . . . 65 9.2. Installing Keys . . . . . . . . . . . . . . . . . . . . 70
9.3. Joining a Secure Network . . . . . . . . . . . . . . . . 65 9.3. Joining a Secure Network . . . . . . . . . . . . . . . . 70
9.4. Counter and Counter Compression . . . . . . . . . . . . 66 9.4. Counter and Counter Compression . . . . . . . . . . . . 71
9.4.1. Timestamp Counters . . . . . . . . . . . . . . . . . 67 9.4.1. Timestamp Counters . . . . . . . . . . . . . . . . . 72
9.5. Functional Description of Packet Protection . . . . . . 67 9.5. Functional Description of Packet Protection . . . . . . 72
9.5.1. Transmission of Outgoing Packets . . . . . . . . . . 67 9.5.1. Transmission of Outgoing Packets . . . . . . . . . . 72
9.5.2. Reception of Incoming Packets . . . . . . . . . . . . 68 9.5.2. Reception of Incoming Packets . . . . . . . . . . . . 74
9.5.3. Cryptographic Mode of Operation . . . . . . . . . . . 69 9.5.3. Cryptographic Mode of Operation . . . . . . . . . . . 76
9.6. Coverage of Integrity and Confidentiality . . . . . . . 77
9.6. Coverage of Integrity and Confidentiality . . . . . . . 70 10. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 78
10. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 70 10.1. Suggestions for Packet Forwarding . . . . . . . . . . . 78
10.1. Suggestions for Packet Forwarding . . . . . . . . . . . 70 10.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 79
10.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 72 10.2.1. Source Node Operation . . . . . . . . . . . . . . . . 80
10.2.1. Source Node Operation . . . . . . . . . . . . . . . . 73 10.2.2. Router Operation . . . . . . . . . . . . . . . . . . 80
10.2.2. Router Operation . . . . . . . . . . . . . . . . . . 73 11. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 83
11. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 75 12. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 85
12. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 76 13. Guidelines for Objective Functions . . . . . . . . . . . . . 86
13. Guidelines for Objective Functions . . . . . . . . . . . . . 76 13.1. Objective Function Behavior . . . . . . . . . . . . . . 86
13.1. Objective Function Behavior . . . . . . . . . . . . . . 77 14. Suggestions for Interoperation with Neighbor Discovery . . . 88
14. RPL Constants and Variables . . . . . . . . . . . . . . . . . 78 15. RPL Constants and Variables . . . . . . . . . . . . . . . . . 89
15. Manageability Considerations . . . . . . . . . . . . . . . . 79 16. Manageability Considerations . . . . . . . . . . . . . . . . 91
15.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 80 16.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 91
15.2. Configuration Management . . . . . . . . . . . . . . . . 81 16.2. Configuration Management . . . . . . . . . . . . . . . . 92
15.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 81 16.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 92
15.2.2. DIO and DAO Base Message and Options Configuration . 81 16.2.2. DIO and DAO Base Message and Options Configuration . 92
15.2.3. Protocol Parameters to be configured on every 16.2.3. Protocol Parameters to be configured on every
router in the LLN . . . . . . . . . . . . . . . . . . 82 router in the LLN . . . . . . . . . . . . . . . . . . 93
15.2.4. Protocol Parameters to be configured on every 16.2.4. Protocol Parameters to be configured on every
non-root router in the LLN . . . . . . . . . . . . . 82 non-root router in the LLN . . . . . . . . . . . . . 93
15.2.5. Parameters to be configured on the DODAG root . . . . 83 16.2.5. Parameters to be configured on the DODAG root . . . . 94
15.2.6. Configuration of RPL Parameters related to 16.2.6. Configuration of RPL Parameters related to
DAO-based mechanisms . . . . . . . . . . . . . . . . 84 DAO-based mechanisms . . . . . . . . . . . . . . . . 95
15.2.7. Default Values . . . . . . . . . . . . . . . . . . . 84 16.2.7. Default Values . . . . . . . . . . . . . . . . . . . 96
15.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 85 16.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 96
15.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 85 16.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 96
15.3.2. Monitoring a DODAG inconsistencies and loop 16.3.2. Monitoring a DODAG inconsistencies and loop
detection . . . . . . . . . . . . . . . . . . . . . . 86 detection . . . . . . . . . . . . . . . . . . . . . . 97
15.4. Monitoring of the RPL data structures . . . . . . . . . 86 16.4. Monitoring of the RPL data structures . . . . . . . . . 98
15.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 86 16.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 98
15.4.2. Destination Oriented Directed Acyclic Graph (DAG) 16.4.2. Destination Oriented Directed Acyclic Graph (DAG)
Table . . . . . . . . . . . . . . . . . . . . . . . . 86 Table . . . . . . . . . . . . . . . . . . . . . . . . 98
15.4.3. Routing Table and DAO Routing Entries . . . . . . . . 87 16.4.3. Routing Table and DAO Routing Entries . . . . . . . . 99
15.5. Fault Management . . . . . . . . . . . . . . . . . . . . 88 16.5. Fault Management . . . . . . . . . . . . . . . . . . . . 100
15.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 89 16.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 100
15.7. Liveness Detection and Monitoring . . . . . . . . . . . 90 16.7. Liveness Detection and Monitoring . . . . . . . . . . . 101
15.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 90 16.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 102
15.9. Impact on Other Protocols . . . . . . . . . . . . . . . 90 16.9. Impact on Other Protocols . . . . . . . . . . . . . . . 102
15.10. Performance Management . . . . . . . . . . . . . . . . . 90 16.10. Performance Management . . . . . . . . . . . . . . . . . 102
16. Security Considerations . . . . . . . . . . . . . . . . . . . 91 17. Security Considerations . . . . . . . . . . . . . . . . . . . 104
16.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 91 17.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 104
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
17.1. RPL Control Message . . . . . . . . . . . . . . . . . . 93 18.1. RPL Control Message . . . . . . . . . . . . . . . . . . 106
17.2. New Registry for RPL Control Codes . . . . . . . . . . . 93 18.2. New Registry for RPL Control Codes . . . . . . . . . . . 106
17.3. New Registry for the Mode of Operation (MOP) DIO 18.3. New Registry for the Mode of Operation (MOP) DIO
Control Field . . . . . . . . . . . . . . . . . . . . . 94 Control Field . . . . . . . . . . . . . . . . . . . . . 107
17.4. RPL Control Message Option . . . . . . . . . . . . . . . 95 18.4. RPL Control Message Option . . . . . . . . . . . . . . . 107
17.5. Objective Code Point (OCP) Registry . . . . . . . . . . 95 18.5. Objective Code Point (OCP) Registry . . . . . . . . . . 108
17.6. ICMPv6: Error in Source Routing Header . . . . . . . . . 95 18.6. ICMPv6: Error in Source Routing Header . . . . . . . . . 108
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 18.7. Link-Local Scope multicast address . . . . . . . . . . . 108
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 111
20.1. Normative References . . . . . . . . . . . . . . . . . . 98 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
20.2. Informative References . . . . . . . . . . . . . . . . . 98 21.1. Normative References . . . . . . . . . . . . . . . . . . 113
Appendix A. Outstanding Issues . . . . . . . . . . . . . . . . . 101 21.2. Informative References . . . . . . . . . . . . . . . . . 113
A.1. Additional Support for P2P Routing . . . . . . . . . . . 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
A.2. Address / Header Compression . . . . . . . . . . . . . . 101
A.3. Managing Multiple Instances . . . . . . . . . . . . . . 101
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101
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). These routers are interconnected by when they are battery operated). These routers are interconnected by
lossy links, typically supporting only low data rates, that are lossy links, typically supporting only low data rates, that are
usually unstable with relatively low packet delivery rates. Another usually unstable with relatively low packet delivery rates. Another
characteristic of such networks is that the traffic patterns are not characteristic of such networks is that the traffic patterns are not
simply point-to-point, but in many cases point-to-multipoint or simply point-to-point, but in many cases point-to-multipoint or
multipoint-to-point. Furthermore such networks may potentially multipoint-to-point. Furthermore such networks may potentially
comprise up to thousands of nodes. These characteristics offer comprise up to thousands of nodes. These characteristics offer
unique challenges to a routing solution: the IETF ROLL Working Group unique challenges to a routing solution: the IETF ROLL Working Group
has defined application-specific routing requirements for a Low power has defined application-specific routing requirements for a Low power
and Lossy Network (LLN) routing protocol, specified in and Lossy Network (LLN) routing protocol, specified in [RFC5867],
[I-D.ietf-roll-building-routing-reqs], [RFC5826], [RFC5673], and [RFC5826], [RFC5673], and [RFC5548].
[RFC5548].
This document specifies the IPv6 Routing Protocol for Low power and This document specifies the IPv6 Routing Protocol for Low power and
lossy networks (RPL). Note that although RPL was specified according lossy networks (RPL). Note that although RPL was specified according
to the requirements set forth in the aforementioned requirement to the requirements set forth in the aforementioned requirement
documents, its use is in no way limited to these applications. documents, its use is in no way limited to these applications.
1.1. Design Principles 1.1. Design Principles
RPL was designed with the objective to meet the requirements spelled RPL was designed with the objective to meet the requirements spelled
out in [I-D.ietf-roll-building-routing-reqs], [RFC5826], [RFC5673], out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].
and [RFC5548].
A network may run multiple instances of RPL concurrently. Each such A network may run multiple instances of RPL concurrently. Each such
instance may serve different and potentially antagonistic constraints instance may serve different and potentially antagonistic constraints
or performance criteria. This document defines how a single instance or performance criteria. This document defines how a single instance
operates. operates.
In order to be useful in a wide range of LLN application domains, RPL In order to be useful in a wide range of LLN application domains, RPL
separates packet processing and forwarding from the routing separates packet processing and forwarding from the routing
optimization objective. Examples of such objectives include optimization objective. Examples of such objectives include
minimizing energy, minimizing latency, or satisfying constraints. minimizing energy, minimizing latency, or satisfying constraints.
skipping to change at page 8, line 34 skipping to change at page 8, line 22
Additionally, this document uses terminology from Additionally, this document uses terminology from
[I-D.ietf-roll-terminology], and introduces the following [I-D.ietf-roll-terminology], and introduces the following
terminology: terminology:
DAG: Directed Acyclic Graph. A directed graph having the property DAG: Directed Acyclic Graph. A directed graph having the property
that all edges are oriented in such a way that no cycles exist. that all edges are oriented in such a way that no cycles exist.
All edges are contained in paths oriented toward and All edges are contained in paths oriented toward and
terminating at one or more root nodes. terminating at one or more root nodes.
DAG root: A DAG root is a node within the DAG that has no outgoing DAG root: A DAG root is a node within the DAG that has no outgoing
edges. Because the graph is acyclic, by definition all DAGs edge. Because the graph is acyclic, by definition all DAGs
must have at least one DAG root and all paths terminate at a must have at least one DAG root and all paths terminate at a
DAG root. DAG root.
Destination Oriented DAG (DODAG): A DAG rooted at a single Destination Oriented DAG (DODAG): A DAG rooted at a single
destination, i.e. at a single DAG root (the DODAG root) with no destination, i.e. at a single DAG root (the DODAG root) with no
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.
Up: Up refers to the direction from leaf nodes towards DODAG roots, Up: Up refers to the direction from leaf nodes towards DODAG roots,
skipping to change at page 9, line 11 skipping to change at page 8, line 44
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,
where vertices further from the root are "deeper," or "down," where vertices further from the root are "deeper," or "down,"
and vertices closer to the root are "shallower," or "up." and vertices closer to the root are "shallower," or "up."
Rank: A node's Rank identifies its distance from a DODAG root. Rank Rank: A node's Rank defines the node's individual position relative
strictly increases in the down direction and strictly decreases to other nodes with respect to a DODAG root. Rank strictly
in the up direction. The exact way Rank is computed depends on increases in the down direction and strictly decreases in the
the DAG's Objective Function (OF). Rank can be a simple up direction. The exact way Rank is computed depends on the
topological distance, may be calculated as a function of link DAG's Objective Function (OF). The Rank may analogously track
metrics, and may consider other properties such as contraints. a simple topological distance, may be calculated as a function
of link metrics, and may consider other properties such as
constraints.
Objective Function (OF): Defines which routing metrics, optimization Objective Function (OF): Defines which routing metrics, optimization
objectives, and related functions a DAG uses to compute Rank. objectives, and related functions a DAG uses to compute Rank.
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. Two DODAGs RPLInstanceID: A unique identifier within a network. Two DODAGs
with the same RPLInstanceID share the same Objective Function. with the same RPLInstanceID share the same Objective Function.
skipping to change at page 10, line 9 skipping to change at page 9, line 45
not. A typical Goal is to construct the DODAG according to a not. A typical Goal is to construct the DODAG according to a
specific objective function and to keep connectivity to a set specific objective function and to keep connectivity to a set
of hosts (e.g. to use an objective function that minimizes ETX of hosts (e.g. to use an objective function that minimizes ETX
and to be connected to a specific database host to store the and to be connected to a specific database host to store the
collected data). collected data).
Grounded: A DODAG is grounded when the DODAG root can satisfy the Grounded: A DODAG is grounded when the DODAG root can satisfy the
Goal. Goal.
Floating: A DODAG is floating if is not Grounded. A floating DODAG Floating: A DODAG is floating if is not Grounded. A floating DODAG
is not expected to have IP connectivity to the Goal. It may, is not expected to have the properties required to satisfy the
however, provide connectivity to other nodes within the DODAG. goal. It may, however, provide connectivity to 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.2.1). Section 3.6.2.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 itself.
(See Section 3.6.2.1) (See Section 3.6.2.1)
skipping to change at page 12, line 8 skipping to change at page 12, line 30
o a single DODAG with a single virtual root coordinating LLN sinks o a single DODAG with a single virtual root coordinating LLN sinks
(with the same DODAGID) over some non-LLN backbone (with the same DODAGID) over some non-LLN backbone
* For example, multiple border routers operating with a reliable * For example, multiple border routers operating with a reliable
backbone, e.g. in support of a 6LowPAN application, that are backbone, e.g. in support of a 6LowPAN application, that are
capable to act as logically equivalent sinks to the same DODAG. capable to act as logically equivalent sinks to 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 has meta-data that associates it with a particular Each RPL packet has meta-data that associates it with a particular
RPLInstanceID and therefore RPL Instance.(Section 10.2). The RPLInstanceID and therefore RPL Instance.(Section 4). 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 beyond
the scope of this specification. the scope of this specification.
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. Figure 2 depicts how a DODAG with DODAG Roots R1, R2, and R3. Figure 2 depicts how a DODAG
version number increment leads to a new DODAG Version. version number increment leads to a new DODAG Version.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| | | |
skipping to change at page 14, line 17 skipping to change at page 14, line 39
3.3.3. Security 3.3.3. Security
RPL supports message confidentiality and integrity. It is designed RPL supports message confidentiality and integrity. It is designed
such that link-layer mechanisms can be used when available and such that link-layer mechanisms can be used when available and
appropriate, yet in their absence RPL can use its own mechanisms. appropriate, yet in their absence RPL can use its own mechanisms.
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
application-level goals. A floating DODAG offers no such required for satisfying the application-defined goal. A floating
connectivity, and provides routes only to nodes within the DODAG. DODAG is not expected to satisfy the goal and in most cases only
Floating DODAGs may be used, for example, to preserve inner provides routes to nodes within the DODAG. Floating DODAGs may be
connectivity during repair. used, for example, to preserve inner connectivity during repair.
3.3.5. Local DODAGs 3.3.5. Local DODAGs
RPL nodes can optimize routes to a destination within an LLN by RPL nodes can optimize routes to a destination within an LLN by
forming a local DODAG whose DODAG Root is the desired destination. forming a local DODAG whose DODAG Root is the desired destination.
Unlike global DAGs, which can consist of multiple DODAGs, local DAGs Unlike global DAGs, which can consist of multiple DODAGs, local DAGs
have one and only one DODAG and therefore one DODAG Root. Local have one and only one DODAG and therefore one DODAG Root. Local
DODAGs can be constructed on-demand. DODAGs can be constructed on-demand.
3.3.6. Administrative Preference 3.3.6. Administrative Preference
An implementation/deployment may specify that some DODAG roots should An implementation/deployment may specify that some DODAG roots should
be used over others through an administrative preference. be used over others through an administrative preference.
Administrative preference offers a way to control traffic and Administrative preference offers a way to control traffic and
engineer DODAG formation in order to better support application engineer DODAG formation in order to better support application
requirements or needs. requirements or needs.
3.3.7. Datapath Validation and Loop Detection 3.3.7. Datapath Validation and Loop Detection
RPL uses a hop-by-hop IPv6 header to detect possible loops within a RPL uses a hop-by-hop IPv6 header to detect possible loops within a
DODAG. Each data packet includes the Rank of the transmitter. If a DODAG. Each data packet includes the Rank of the transmitter. An
node receives a data packet with a Rank less than or equal to its inconsistency between the routing decision for a packet (upward or
own, this indicates a possible loop. On receiving such a packet, a downward) and the Rank relationship between the two nodes indicates a
node institutes a local repair operation. possible loop. On receiving such a packet, a node institutes a local
repair operation.
3.3.8. Distributed Algorithm Operation 3.3.8. Distributed Algorithm Operation
A high level overview of the distributed algorithm, which constructs A high level overview of the distributed algorithm, which constructs
the DODAG, is as follows: the DODAG, is as follows:
o Some nodes are configured to be DODAG roots, with associated DODAG o Some nodes are configured to be DODAG roots, with associated DODAG
configurations. configurations.
o Nodes advertise their presence, affiliation with a DODAG, routing o Nodes advertise their presence, affiliation with a DODAG, routing
skipping to change at page 17, line 48 skipping to change at page 18, line 25
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 may mitigate the impact of
DAO loops and trigger their repair. DAO loops and trigger their repair.
In the case where stateless DAO operation is used, i.e. source
routing specifies the down routes, then DAO Loops should not occur on
the stateless portions of the path.
3.6.2. Rank Properties 3.6.2. 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, and may
depend on parents, link metrics, and the node configuration and depend on parents, link metrics, and the node configuration and
policies. policies.
The rank is not a cost metric, although its value can be derived from The rank is not a cost metric, although its value can be derived from
and influenced by metrics. The rank has properties of its own that and influenced by metrics. The rank has properties of its own that
are not necessarily those of all metrics: are not necessarily those of all metrics:
Type: The rank is an abstract decimal 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
cost to the root. cost to the root.
Stability: The stability of the rank determines the stability of the Stability: The stability of the rank determines the stability of the
routing topology. Some dampening or filtering might be routing topology. Some dampening or filtering might be
applied to keep the topology stable, and thus the rank does applied to keep the topology stable, and thus the rank does
not necessarily change as fast as some physical metrics not necessarily change as fast as some physical metrics
skipping to change at page 18, line 51 skipping to change at page 19, line 23
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 nodes 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.2.1. Rank Comparison (DAGRank()) 3.6.2.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 decimal 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. When increase in rank between a node and any of its DODAG parents. When
an objective function computes rank, the objective function operates an objective function computes rank, the objective function operates
on the entire (i.e. 16-bit) rank quantity. When rank is compared, on the entire (i.e. 16-bit) rank quantity. When rank is compared,
e.g. for determination of parent relationships or loop detection, the e.g. for determination of parent relationships or loop detection, the
integer portion of the rank is to be used. The integer portion of integer portion of the rank is to be used. The integer portion of
the Rank is computed by the DAGRank() macro as follows, where the Rank is computed by the DAGRank() macro as follows, where
floor(x) is the function that evaluates to the greatest integer less floor(x) is the function that evaluates to the greatest integer less
than or equal to x: than or equal to x:
DAGRank(rank) = floor(rank/MinHopRankIncrease) DAGRank(rank) = floor(rank/MinHopRankIncrease)
MinHopRankIncrease is provisioned at the DODAG Root and propagated in MinHopRankIncrease is provisioned at the DODAG Root and propagated in
the DIO message. For efficient implementation the MinHopRankIncrease the DIO message. The default value of MinHopRankIncrease is
MUST be a power of 2. An implementation may configure a value DEFAULT_MIN_HOP_RANK_INCREASE. For efficient implementation the
MinHopRankIncrease as appropriate to balance between the loop MinHopRankIncrease MUST be a power of 2. An implementation may
avoidance logic of RPL (i.e. selection of eligible parents) and the configure a value MinHopRankIncrease as appropriate to balance
metrics in use. between the loop avoidance logic of RPL (i.e. selection of eligible
parents) and the metrics in use. A further effect of
MinHopRankIncrease is to impact the number increments that are
allowed before INFINITE_RANK is reached, i.e. to control how long it
may take to count-to-infinity.
By convention in this document, using the macro DAGRank(node) may be By convention in this document, using the macro DAGRank(node) may be
interpreted as DAGRank(node.rank), where node.rank is the rank value interpreted as DAGRank(node.rank), where node.rank is the rank value
as maintained by the node. as maintained by the node.
A node A has a rank less than the rank of a node B if DAGRank(A) is A node A has a rank less than the rank of a node B if DAGRank(A) is
less than DAGRank(B). less than DAGRank(B).
A node A has a rank equal to the rank of a node B if DAGRank(A) is A node A has a rank equal to the rank of a node B if DAGRank(A) is
equal to DAGRank(B). equal to DAGRank(B).
skipping to change at page 20, line 34 skipping to change at page 21, line 8
function being used within the DODAG. function being used within the DODAG.
3.7. Traffic Flows Supported by RPL 3.7. 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).
3.7.1. Multipoint-to-Point Traffic 3.7.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 ([I-D.ietf-roll-building-routing-reqs], [RFC5826], applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). The
[RFC5673], [RFC5548]). The destinations of MP2P flows are designated destinations of MP2P flows are designated nodes that have some
nodes that have some application significance, such as providing application significance, such as providing connectivity to the
connectivity to the larger Internet or core private IP network. RPL larger Internet or core private IP network. RPL supports MP2P
supports MP2P traffic by allowing MP2P destinations to be reached via traffic by allowing MP2P destinations to be reached via DODAG roots.
DODAG roots.
3.7.2. Point-to-Multipoint Traffic 3.7.2. Point-to-Multipoint Traffic
Point-to-multipoint (P2MP) is a traffic pattern required by several Point-to-multipoint (P2MP) is a traffic pattern required by several
LLN applications ([I-D.ietf-roll-building-routing-reqs], [RFC5826], LLN applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). RPL
[RFC5673], [RFC5548]). RPL supports P2MP traffic by using a supports P2MP traffic by using a destination advertisement mechanism
destination advertisement mechanism that provisions routes toward that provisions routes toward destinations (prefixes, addresses, or
destination prefixes and away from roots. Destination advertisements multicast groups), and away from roots. Destination advertisements
can update routing tables as the underlying DODAG topology changes. can update routing tables as the underlying DODAG topology changes.
3.7.3. Point-to-Point Traffic 3.7.3. Point-to-Point Traffic
RPL DODAGs provide a basic structure for point-to-point (P2P) RPL DODAGs provide a basic structure for point-to-point (P2P)
traffic. For a RPL network to support P2P traffic, a root must be traffic. For a RPL network to support P2P traffic, a root must be
able to route packets to a destination. Nodes within the network may able to route packets to a destination. Nodes within the network may
also have routing tables to destinations. A packet flows towards a also have routing tables to destinations. A packet flows towards a
root until it reaches an ancestor that has a known route to the root until it reaches an ancestor that has a known route to the
destination. As pointed out later in this document, in the most destination. As pointed out later in this document, in the most
skipping to change at page 21, line 27 skipping to change at page 22, line 8
RPL also supports the case where a P2P destination is a 'one-hop' RPL also supports the case where a P2P destination is a 'one-hop'
neighbor. neighbor.
RPL neither specifies nor precludes additional mechanisms for RPL neither specifies nor precludes additional mechanisms for
computing and installing potentially more optimal routes to support computing and installing potentially more optimal routes to support
arbitrary P2P traffic. arbitrary P2P traffic.
4. RPL Instance 4. RPL Instance
Within a given LLN, there may be multiple, logically independent RPL Within a given LLN, there may be multiple, logically independent RPL
instances. This document describes how a single instance behaves. instances. A RPL node may belong to multiple RPL instances, and may
act as a router in some and as a leaf in others. This document
A node may belong to multiple RPL Instances. describes how a single instance behaves.
Control and data packets in RPL network MUST be tagged to
unambiguously identify what RPL Instance they are part of. The
identifiers include the RPLInstanceID and, for local instances, the
DODAGID. In some uses the DODAGID is implicit, in other uses it must
be given explicitly. Every RPL control message has a RPLInstanceID
field. Some RPL control messages may optionally include a DODAGID.
Data messages routed with RPL have a RPL Hop-by-hop option
([I-D.hui-6man-rpl-option]).
There are two types of RPL Instances: local and global. Local RPL There are two types of RPL Instances: local and global. Local RPL
Instances are always a single DODAG whose singular root owns the Instances are always a single DODAG whose singular root owns the
corresponding DODAGID. Local RPL Instances are intended for corresponding DODAGID. Local RPL Instances can be used for
constructing temporary DODAGs to support on-demand P2P traffic. constructing DODAGs that may be used by future on-demand routing
Global RPL Instances have one or more DODAGs and are typically long- solutions that are outside of the scope of this document. Global RPL
lived. RPL divides the RPLInstanceID space between global and local Instances have one or more DODAGs and are typically long-lived. RPL
instances to prevent identifier collisions. divides the RPLInstanceID space between global and local instances to
allow for both coordinated and unilateral allocation of
RPLInstanceIDs.
The definition and provisioning of RPL instances are beyond the scope
of this specification. Those operations are expected to be such that
data packets coming from the outside of the RPL network can
unambiguously be associated to at least one RPL instance, and be
safely routed over any instance that would match the packet.
Information used to match a packet to a RPL instance can typically be
taken from fields in the IPv6 header, like the flow label, TOS bits,
or destination address.
Control and data packets within RPL network are tagged to
unambiguously identify what RPL Instance they are part of.
Every RPL control message has a RPLInstanceID field. Some RPL
control messages, when referring to a local RPLInstanceID as defined
below, may also include a DODAGID.
For data packets, the RPLInstanceID may be indicated in the flow
label by the source of the packet. If it is not, then it is inferred
and added by the RPL network ingress router in the RPL Hop-by-hop
option ([I-D.hui-6man-rpl-option]) as further described in
Section 10.2
4.1. RPL Instance ID 4.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 document. There can be up to 128 global instance in the
whole network, and up 64 local instances per DODAGID. whole network, and up 64 local instances per DODAGID.
A global RPLinstanceID is encoded in a RPLinstanceID field as A global RPLinstanceID is encoded in a RPLinstanceID field as
follows: follows:
skipping to change at page 22, line 45 skipping to change at page 24, line 12
DODAGID. If the D flag is clear then the source address of the IPv6 DODAGID. If the D flag is clear then the source address of the IPv6
packet MUST be the DODAGID. packet MUST be the DODAGID.
5. ICMPv6 RPL Control Message 5. 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 message.
A RPL Control Message is identified by a code, and composed of a base A RPL Control Message is identified by a code, and composed of a base
that depends on the code, and a series of options. that depends on the code, and a series of options.
A RPL Control Message has the scope of a link. The source address is A RPL Control Message has the scope of a link. The source address is
a link local address. The destination address is either all routers a link local address. The destination address is either the RPL
multicast address (FF02::2) or a link local address. routers multicast address or a link local address. The RPL routers
multicast address is a new address with a requested value of
FF02::1:A (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 5. illustrated in Figure 5.
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 23, line 28 skipping to change at page 24, line 43
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: RPL Control Message Figure 5: RPL Control Message
The RPL Control message is an ICMPv6 information message with a The RPL Control message is an ICMPv6 information message with a
requested Type of 155 (to be confirmed by IANA). requested Type of 155 (to be confirmed by IANA).
The Code field identifies the type of RPL Control Message. This The Code field identifies the type of RPL Control Message. This
document defines codes for the following RPL Control Message types document defines codes for the following RPL Control Message types
(all codes are to be confirmed by the IANA Section 17.2): (all codes are to be confirmed by the IANA Section 18.2):
o 0x00: DODAG Information Solicitation (Section 5.2) o 0x00: DODAG Information Solicitation (Section 5.2)
o 0x01: DODAG Information Object (Section 5.3) o 0x01: DODAG Information Object (Section 5.3)
o 0x02: Destination Advertisement Object (Section 5.4) o 0x02: Destination Advertisement Object (Section 5.4)
o 0x03: Destination Advertisement Object Acknowledgment o 0x03: Destination Advertisement Object Acknowledgment
(Section 5.5) (Section 5.5)
o 0x80: Secure DODAG Information Solicitation (Section 5.2.2) o 0x80: Secure DODAG Information Solicitation (Section 5.2.2)
o 0x81: Secure DODAG Information Object (Section 5.3.2) o 0x81: Secure DODAG Information Object (Section 5.3.2)
o 0x82: Secure Destination Advertisement Object (Section 5.4.2) o 0x82: Secure Destination Advertisement Object (Section 5.4.2)
o 0x83: Secure Destination Advertisement Object Acknowledgment o 0x83: Secure Destination Advertisement Object Acknowledgment
skipping to change at page 24, line 34 skipping to change at page 25, line 49
Figure 6: Secure RPL Control Message Figure 6: Secure RPL Control Message
The remainder of this section describes the currently defined RPL The remainder of this section describes the currently defined RPL
Control Message Base formats followed by the currently defined RPL Control Message Base formats followed by the currently defined RPL
Control Message Options. Control Message Options.
5.1. RPL Security Fields 5.1. RPL Security Fields
Each RPL message has a secure version. The secure versions provide Each RPL message has a secure version. The secure versions provide
integrity and confidentiality. Because security covers the base integrity and replay protection as well as optional confidentiality
message as well as options, in secured messages the security and delay protection. Because security covers the base message as
information lies between the checksum and base, as shown in Figure well as options, in secured messages the security information lies
Figure 6. between the checksum and base, as shown in Figure Figure 6.
The format of the security section is as follows: The format of the security section 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|T| Rsrvd |Sec|KIM|Rsrvd| LVL | | |C|T| Rsrvd |Sec|KIM|Rsrvd| LVL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Counter | | Counter |
. . . .
skipping to change at page 25, line 28 skipping to change at page 26, line 32
. Key Identifier . . Key Identifier .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Security Section Figure 7: Security Section
All fields are considered as packet payload from a security All fields are considered as packet payload from a security
processing perspective. The exact placement and format of message processing perspective. The exact placement and format of message
integrity/authentication codes has not yet been determined. integrity/authentication codes has not yet been determined.
Use of the Security section is further detailed in Section 16. Use of the Security section is further detailed in Section 17.
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 Compression (C): If the Counter Compression flag is Counter Compression (C): If the Counter Compression flag is
set then the Counter field is compressed from 4 bytes set then the Counter field is compressed from 4 bytes
into 1 byte. If the Counter Compression flag is clear into 1 byte. If the Counter Compression flag is clear
then the Counter field is 4 bytes and uncompressed. then the Counter field is 4 bytes and uncompressed.
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
skipping to change at page 30, line 22 skipping to change at page 31, line 22
base format is the DIS message shown in Figure Figure 9. base format is the DIS message shown in Figure Figure 9.
5.2.3. DIS Options 5.2.3. DIS Options
The DIS message MAY carry valid options. The DIS message MAY carry valid options.
This specification allows for the DIS message to carry the following This specification allows for the DIS message to carry the following
options: options:
0x00 Pad1 0x00 Pad1
0x01 PadN 0x01 PadN
0x05 RPL Target
0x07 Solicited Information 0x07 Solicited Information
5.3. DODAG Information Object (DIO) 5.3. DODAG Information Object (DIO)
The DODAG Information Object carries information that allows a node The DODAG Information Object carries information that allows a node
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 upward routing topology. select a DODAG parent set, and maintain the upward routing topology.
5.3.1. Format of the DIO Base Object 5.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 | Rank | | RPLInstanceID | Version | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|A|T|MOP| Prf | DTSN | Reserved | |G|0| MOP | Prf | DTSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
skipping to change at page 31, line 4 skipping to change at page 31, line 49
| | | |
+ + + +
| | | |
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 10: The DIO Base Object Figure 10: The DIO Base Object
Control Field: The DAG Control Field has three flags and two fields: Control Field: The DAG Control Field has three flags and two fields:
Grounded (G): The Grounded (G) flag indicates whether the Grounded (G): The Grounded (G) flag indicates whether the
upward routes this node advertises provide connectivity DODAG advertised can satisfy the application-defined
to the set of addresses which are application-defined goal. If the flag is set, the DODAG is grounded. If the
goals. If the flag is set, the DODAG is grounded and flag is cleared, the DODAG is floating.
provides such connectivity. If the flag is cleared, the
DODAG is floating and may not provide such connectivity.
Destination Advertisement Supported (A): The Destination
Advertisement Supported (A) flag indicates whether the
root of this DODAG can collect and use downward route
state. If the flag is set, nodes in the network are
enabled to exchange destination advertisements messages
to build downward routes (Section 8). If the flag is
cleared, destination advertisement messages are disabled
and the DODAG maintains only upward routes.
Destination Advertisement Trigger (T): The Destination
Advertisement Trigger (T) flag indicates a complete
refresh of downward routes. If the flag is set, then a
refresh of downward route state is to take place over the
entire DODAG. If the flag is cleared, the downward route
maintenance is in its normal mode of operation. The
further details of this process are described in
Section 8.
Mode of Operation (MOP): The Mode of Operation (MOP) field Mode of Operation (MOP): The Mode of Operation (MOP) field
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 table below: in the table below:
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
| MOP | Meaning | | MOP | Meaning |
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
| 00 | Non-storing | | 000 | No downward routes maintained by RPL |
| 01 | Storing | | 001 | Non storing mode |
| 10 | Reserved | | 010 | Storing without multicast support |
| 11 | Reserved | | 011 | Storing with multicast support |
| | |
| | All other values are reserved |
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
A value of 000 indicates that destination advertisement
messages are disabled and the DODAG maintains only upward
routes
Mode of Operation (MOP) Encoding 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).
Section 7.2 describes how DAGPreference affects DIO Section 7.2 describes how DAGPreference affects DIO
processing. processing.
skipping to change at page 33, line 6 skipping to change at page 33, line 41
The DIO message MAY carry valid options. The DIO message MAY carry valid options.
This specification allows for the DIO message to carry the following This specification allows for the DIO message to carry the following
options: options:
0x00 Pad1 0x00 Pad1
0x01 PadN 0x01 PadN
0x02 Metric Container 0x02 Metric Container
0x03 Routing Information 0x03 Routing Information
0x04 DODAG Configuration 0x04 DODAG Configuration
0x09 Prefix Information 0x08 Prefix Information
5.4. Destination Advertisement Object (DAO) 5.4. Destination Advertisement Object (DAO)
The Destination Advertisement Object (DAO) is used to propagate The Destination Advertisement Object (DAO) is used to propagate
destination information upwards along the DODAG. The DAO message is destination information upwards along the DODAG. The DAO message is
unicast by the child to the selected parent(s). The DAO message may unicast by the child to the selected parent(s). The DAO message may
optionally, upon explicit request or error, be acknowledged by the optionally, upon explicit request or error, be acknowledged by the
parent with a Destination Advertisement Acknowledgement (DAO-ACK) parent with a Destination Advertisement Acknowledgement (DAO-ACK)
message back to the child. message back to the child.
skipping to change at page 33, line 44 skipping to change at page 34, line 32
Figure 11: The DAO Base Object Figure 11: The DAO 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.
K: The 'K' flag indicates that the parent is expected to send a K: The 'K' flag indicates that the parent is expected to send a
DAO-ACK back. DAO-ACK back.
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
would typically only be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
DAOSequence: Incremented at each unique DAO message, echoed in the DAOSequence: Incremented at each unique DAO message, echoed in the
DAO-ACK message. DAO-ACK message.
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.
skipping to change at page 36, line 13 skipping to change at page 36, line 41
the base format is the DAO-ACK message shown in Figure Figure 12. the base format is the DAO-ACK message shown in Figure Figure 12.
5.5.3. DAO-ACK Options 5.5.3. DAO-ACK Options
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.
5.6. Consistency Check (CC) 5.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. challenge/responses. A CC message MUST be sent as a secured RPL
message.
5.6.1. Format of the CC Base Object A CC message (request or response) MUST NOT set the 'C' bit of the
security section: CC messages always have full counters.
5.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| Reserved | Nonce | | RPLInstanceID |R| Reserved | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 13: The CC Base Object Figure 13: 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. A CC message with the R bit
set MUST NOT compress the security Counter field: the C bit of set MUST NOT compress the security Counter field: the C bit of
the security section MUST be 0. the security section MUST be 0.
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
sender's estimate of the destination's current security Counter
value. If the sender does not have an estimate, it SHOULD set
the Destination Counter field to zero.
Unassigned bits of the CC Base are reserved. They MUST be set to Unassigned bits of the CC Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception. zero on transmission and MUST be ignored on reception.
The Destination Counter value allows new or recovered nodes to
resynchronize through CC message exchanges. This is important to
ensure that a Counter value is not repeated for a given security key
even in the event of devices recovering from a failure that created a
loss of Counter state. For example, where a CC request or other RPL
message is received with an initialized Counter within the message
security section, the provision of the Incoming Counter within the CC
response message allows the requesting node to reset its Outgoing
Counter to a value greater than the last value received by the
responding node; the Incoming Counter will also be updated from the
received CC response.
5.6.2. CC Options 5.6.2. CC Options
The CC message MAY carry valid options. In the scope of this The CC message MAY carry valid options. In the scope of this
specification, there are no valid options for a CC message. 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
skipping to change at page 37, line 30 skipping to change at page 38, line 34
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Option Type | Option Length | Option Data | Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 14: RPL Option Generic Format Figure 14: RPL Option Generic Format
Option Type: 8-bit identifier of the type of option. The Option Option Type: 8-bit identifier of the type of option. The Option
Type values are to be confirmed by the IANA Section 17.4. Type values are to be confirmed by the IANA Section 18.4.
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields. fields.
Option Data: A variable length field that contains data specific to Option Data: A variable length field that contains data specific to
the option. the option.
When processing a RPL message containing an option for which the When processing a RPL message containing an option for which the
Option Type value is not recognized by the receiver, the receiver Option Type value is not recognized by the receiver, the receiver
skipping to change at page 39, line 47 skipping to change at page 41, line 4
of the Metric Data. of the Metric Data.
Metric Data: The order, content, and coding of the Metric Container Metric Data: The order, content, and coding of the Metric Container
data is as specified in [I-D.ietf-roll-routing-metrics]. data is as specified in [I-D.ietf-roll-routing-metrics].
5.7.5. Route Information 5.7.5. Route Information
The Route Information option may be present in DIO messages, and is The Route Information option may be present in DIO messages, and is
equivalent in function to the IPv6 ND Route Information option as equivalent in function to the IPv6 ND Route Information option as
defined in [RFC4191]. The format of the option is modified slightly defined in [RFC4191]. The format of the option is modified slightly
(Type, Length) in order to be carried as a RPL option as follows: (Type, Length, Prefix) in order to be carried as a RPL option as
follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd| | Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime | | Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Prefix (Variable Length) . . Prefix (Variable Length) .
skipping to change at page 40, line 38 skipping to change at page 41, line 40
transcribed here for convenience: transcribed here for convenience:
Option Type: 0x03 (to be confirmed by IANA) Option Type: 0x03 (to be confirmed by IANA)
Option Length: Variable, length of the option in octets excluding Option Length: Variable, length of the option in octets excluding
the Type and Length fields. Note that this length is expressed the Type and Length fields. Note that this length is expressed
in units of single-octets, unlike in IPv6 ND. in units of single-octets, unlike in IPv6 ND.
Prefix Length 8-bit unsigned integer. The number of leading bits in Prefix Length 8-bit unsigned integer. The number of leading bits in
the Prefix that are valid. The value ranges from 0 to 128. the Prefix that are valid. The value ranges from 0 to 128.
The Prefix field is 0, 8, or 16 octets depending on Length. The Prefix field has the number of bytes inferred from the
Option Length field, that must be at least the Prefix Length.
Note that in RPL this means that the Prefix field may have
lengths other than 0, 8, or 16.
Prf: 2-bit signed integer. The Route Preference indicates whether Prf: 2-bit signed integer. The Route Preference indicates whether
to prefer the router associated with this prefix over others, to prefer the router associated with this prefix over others,
when multiple identical prefixes (for different routers) have when multiple identical prefixes (for different routers) have
been received. If the Reserved (10) value is received, the been received. If the Reserved (10) value is received, the
Route Information Option MUST be ignored. Route Information Option MUST be ignored.
Resvd: Two 3-bit unused fields. They MUST be initialized to zero by Resvd: Two 3-bit unused fields. They MUST be initialized to zero by
the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
Route Lifetime 32-bit unsigned integer. The length of time in Route Lifetime 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the seconds (relative to the time the packet is sent) that the
prefix is valid for route determination. A value of all one prefix is valid for route determination. A value of all one
bits (0xffffffff) represents infinity. bits (0xffffffff) represents infinity.
Prefix Variable-length field containing an IP address or a prefix of Prefix Variable-length field containing an IP address or a prefix of
an IP address. The Prefix Length field contains the number of an IP address. The Prefix Length field contains the number of
valid leading bits in the prefix. The bits in the prefix after valid leading bits in the prefix. The bits in the prefix after
the prefix length (if any) are reserved and MUST be initialized the prefix length (if any) are reserved and MUST be initialized
to zero by the sender and ignored by the receiver. to zero by the sender and ignored by the receiver. Note that
in RPL this field may have lengths other than 0, 8, or 16.
Unassigned bits of the Route Information option are reserved. They Unassigned bits of the Route 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.
5.7.6. DODAG Configuration 5.7.6. DODAG Configuration
The DODAG Configuration option may be present in DIO messages, and The DODAG Configuration option may be present in DIO messages, and
its format is as follows: its format is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 42, line 7 skipping to change at page 43, line 16
Option Length: 8 bytes Option Length: 8 bytes
Authentication Enabled (A): One bit describing the security mode of Authentication Enabled (A): One bit describing the security mode of
the network. The bit describe whether a node must authenticate the network. The bit describe whether a node must authenticate
with a key authority before joining the network as a router. with a key authority before joining the network as a router.
If the DIO is not a secure DIO, the 'A' bit MUST be zero. If the DIO is not a secure DIO, the 'A' bit MUST be zero.
Path Control Size (PCS): 3-bit unsigned integer used to configure Path Control Size (PCS): 3-bit unsigned integer used to configure
the number of bits that may be allocated to the Path Control the number of bits that may be allocated to the Path Control
field (see Section 8.9). field (see Section 8.9). Note that as used a value of 1 is
added to this field, i.e. a PCS value of 0 results in 1 active
bit in the Path Control field. The default value of PCS is
DEFAULT_PATH_CONTROL_SIZE.
DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax
of the DIO trickle timer (see Section 7.3.1). of the DIO trickle timer (see Section 7.3.1).
DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the
DIO trickle timer (see Section 7.3.1). DIO trickle timer (see Section 7.3.1).
DIORedundancyConstant: 8-bit unsigned integer used to configure k of DIORedundancyConstant: 8-bit unsigned integer used to configure k of
the DIO trickle timer (see Section 7.3.1). the DIO trickle timer (see Section 7.3.1).
skipping to change at page 46, line 49 skipping to change at page 48, line 29
Unassigned bits of the Solicited Information option are reserved. Unassigned bits of the Solicited Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on They MUST be set to zero on transmission and MUST be ignored on
reception. reception.
5.7.10. Prefix Information 5.7.10. Prefix Information
The Prefix Information option may be present in DIO messages, and is The Prefix Information option may be present in DIO messages, and is
equivalent in function to the IPv6 ND Prefix Information option as equivalent in function to the IPv6 ND Prefix Information option as
defined in [RFC4861]. The format of the option is modified slightly defined in [RFC4861]. The format of the option is modified slightly
(Type, Length) in order to be carried as a RPL option as follows: (Type, Length, Prefix) in order to be carried as a RPL option as
follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Option Length | Prefix Length |L|A| Reserved1 | | Type = 8 | Option Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime | | Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 24 skipping to change at page 50, line 4
seconds (relative to the time the packet is sent) that the seconds (relative to the time the packet is sent) that the
prefix is valid for the purpose of on-link determination. A prefix is valid for the purpose of on-link determination. A
value of all one bits (0xffffffff) represents infinity. The value of all one bits (0xffffffff) represents infinity. The
Valid Lifetime is also used by [RFC4862]. Valid Lifetime is also used by [RFC4862].
Preferred Lifetime 32-bit unsigned integer. The length of time in Preferred Lifetime 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that seconds (relative to the time the packet is sent) that
addresses generated from the prefix via stateless address addresses generated from the prefix via stateless address
autoconfiguration remain preferred [RFC4862]. A value of all autoconfiguration remain preferred [RFC4862]. A value of all
one bits (0xffffffff) represents infinity. See [RFC4862]. one bits (0xffffffff) represents infinity. See [RFC4862].
Note that the value of this field MUST NOT exceed the Valid Note that the value of this field MUST NOT exceed the Valid
Lifetime field to avoid preferring addresses that are no longer Lifetime field to avoid preferring addresses that are no longer
valid. valid.
Reserved2 This field is unused. It MUST be initialized to zero by Reserved2 This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
Prefix An IP address or a prefix of an IP address. The Prefix Prefix An IP address or a prefix of an IP address. The Prefix
Length field contains the number of valid leading bits in the Length field contains the number of valid leading bits in the
prefix. The bits in the prefix after the prefix length are prefix. The bits in the prefix after the prefix length are
reserved and MUST be initialized to zero by the sender and reserved and MUST be initialized to zero by the sender and
ignored by the receiver. A router SHOULD NOT send a prefix ignored by the receiver. A router SHOULD NOT send a prefix
option for the link-local prefix and a host SHOULD ignore such option for the link-local prefix and a host SHOULD ignore such
a prefix option. a prefix option. A non-storing node SHOULD refrain from
advertising a prefix till it owns an address of that prefix,
and then it SHOULD advertise its full address in this field, to
be used by its children in the Parent Address 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. Sequence Counters 6. Sequence Counters
RPL makes use of sequence counters for the DODAGVersionNumber in the This section describes the general scheme for bootstrap and operation
of sequence counters in RPL, such as the DODAGVersionNumber in the
DIO message, the DAOSequence in the DAO message, and the Path- DIO message, the DAOSequence in the DAO message, and the Path-
Sequence in the Transit Information option. Sequence in the Transit Information option.
This section describes the general scheme for bootstrap and operation
of sequence counters in RPL. The general operations described here
are to applied to RPL's various sequence counters as enumerated
above.
RPL sequence counters are subdivided in a 'lollipop' fashion RPL sequence counters are subdivided in a 'lollipop' fashion
([Perlman83]), where the values from 0 to 15 are used as a short ([Perlman83]), where the values from 128 and greater are used as a
linear sequence to indicate a restart and bootstrap the counter, and linear sequence to indicate a restart and bootstrap the counter, and
the remaining values are used as a circular sequence number space as the values less than or equal to 127 used as a circular sequence
in [RFC1982]. number space of size 128 as in [RFC1982]. Consideration is given to
the mode of operation when transitioning from the linear region to
the circular region. Finally, when operating in the circular region,
if sequence numbers are detected to be too far apart then they are
not comparable, as detailed below.
When a sequence counter is initialized, if the node has no other A window of comparison, SEQUENCE_WINDOW = 16, is configured based on
basis of persistence for that counter, then the sequence counter is a value of 2^N, where N=4.
initialized to zero.
When a sequence counter increments past its maximum value, the For a given sequence counter,
sequence counter wraps back to 16 instead of zero.
When two sequence counters to be compared are both in [0..15] (the 1. The sequence counter SHOULD be initialized to an implementation
'straight' part of the lollipop), a normal arithmetic comparison is defined value which is 128 or greater prior to use. A
applied for greater than, less than, and equal. recommended value is 240 (256 - SEQUENCE_WINDOW).
When a first sequence counter is in [0..15], and a second sequence 2. When a sequence counter increment would cause the sequence
counter to be compared is >15, then the first sequence counter is counter to increment beyond its maximum value, the sequence
taken to be fresher, and thus greater, than the second. The second counter MUST wrap back to zero. When incrementing a sequence
sequence counter is less than the first, and the two are not equal. counter greater than or equal to 128, the maximum value is 255.
When incrementing a sequence counter less than 128, the maximum
value is 127.
When two sequence counters to be compared are both outside of [0..15] 3. When comparing two sequence counters, the following rules MUST be
(the 'circular' part of the lollipop), a comparison as described in applied:
[RFC1982] may be used to determine the relationships greater than,
less than, and equal, with the modification that the sequence 1. When a first sequence counter A is in the interval [0..127]
counters should be compared as if the minimum value is 16 and not 0. and a second sequence counter B is in [128..255]:
1. If B-A is less than or equal to SEQUENCE_WINDOW, then B
is greater than A, A is less than B, and the two are not
equal.
2. If B-A is greater than SEQUENCE_WINDOW, then A is greater
than B, B is less than A, and the two are not equal.
2. In the case where both sequence counters to be compared are
less than or equal to 127, and in the case where both
sequence counters to be compared are greater than or equal to
128:
1. If the absolute magnitude of difference between the two
sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in
[RFC1982] is used to determine the relationships greater
than, less than, and equal
2. If the absolute magnitude of difference of the two
sequence counters is greater than SEQUENCE_WINDOW, then a
desynchronization has occurred and the two sequence
numbers are not comparable.
4. If two sequence numbers are determined to be not comparable, i.e.
the results of the comparison are not defined, then a node should
consider the comparison as if it has evaluated in such a way so
as to give precedence to the sequence number that has most
recently been observed to increment. Failing this, the node
should consider the comparison as if it has evaluated in such a
way so as to minimize the resulting changes to its own state.
7. Upward Routes 7. Upward Routes
This section describes how RPL discovers and maintains upward routes. This section describes how RPL discovers and maintains upward routes.
It describes the use of DODAG Information Objects (DIOs), the It describes the use of DODAG Information Objects (DIOs), the
messages used to discover and maintain these routes. It specifies messages used to discover and maintain these routes. It specifies
how RPL generates and responds to DIOs. It also describes DODAG how RPL generates and responds to DIOs. It also describes DODAG
Information Solicitation (DIS) messages, which are used to trigger Information Solicitation (DIS) messages, which are used to trigger
DIO transmissions. DIO transmissions.
7.1. DIO Base Rules 7.1. DIO Base Rules
1. If the 'A' flag of a DIO Base is cleared, the 'T' flag MUST also 1. For the following DIO Base fields, a node that is not a DODAG
be cleared.
2. For the following DIO Base fields, a node that is not a DODAG
root MUST advertise the same values as its preferred DODAG parent root MUST advertise the same values as its preferred DODAG parent
(defined in Section 7.2.1). Therefore, if a DODAG root does not (defined in Section 7.2.1). Therefore, if a DODAG root does not
change these values, every node in a route to that DODAG root change these values, every node in a route to that DODAG root
eventually advertises the same values for these fields. These eventually advertises the same values for these fields. These
fields are: fields are:
1. Grounded (G) 1. Grounded (G)
2. Destination Advertisement Supported (A) 2. Mode of Operation (MOP)
3. Destination Advertisement Trigger (T) 3. DAGPreference (Prf)
4. Mode of Operation (MOP) 4. Version
5. DAGPreference (Prf) 5. RPLInstanceID
6. Version 6. DODAGID
7. RPLInstanceID
8. DODAGID
3. A node MAY update the following fields at each hop: 2. A node MAY update the following fields at each hop:
1. Rank 1. Rank
2. DTSN 2. DTSN
4. The DODAGID field each root sets MUST be unique within the RPL 3. The DODAGID field each root sets MUST be unique within the RPL
Instance. Instance.
7.2. Upward Route Discovery and Maintenance 7.2. Upward Route Discovery and Maintenance
Upward route discovery allows a node to join a DODAG by discovering Upward route discovery allows a node to join a DODAG by discovering
neighbors that are members of the DODAG of interest and identifying a neighbors that are members of the DODAG of interest and identifying a
set of parents. The exact policies for selecting neighbors and set of parents. The exact policies for selecting neighbors and
parents is implementation-dependent and driven by the OF. This parents is implementation-dependent and driven by the OF. This
section specifies the set of rules those policies must follow for section specifies the set of rules those policies must follow for
interoperability. interoperability.
skipping to change at page 52, line 46 skipping to change at page 56, line 10
periodically, upon administrative intervention, or on application- periodically, upon administrative intervention, or on application-
level detection of lost connectivity or DODAG inefficiency. level detection 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.
7.2.2.2. DODAG Roots 7.2.2.2. DODAG Roots
1. A DODAG root without connectivity to the set of application-level 1. A DODAG root without possibility to satisfy the application-
Goals MUST NOT set the Grounded bit. defined goal MUST NOT set the Grounded bit.
2. A DODAG root MUST advertise a rank of ROOT_RANK. 2. A DODAG root MUST advertise a rank of ROOT_RANK.
3. A node whose DODAG parent set is empty MAY become the DODAG Root 3. 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 of a floating DODAG. It MAY also set its DAGPreference such that
it is less preferred. it is less preferred.
In a deployment that uses a backbone link to federate a number of LLN In a deployment that uses a backbone link to federate a number of LLN
roots, it is possible to run RPL over that backbone and use one roots, it is possible to run RPL over that backbone 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
skipping to change at page 56, line 35 skipping to change at page 59, line 46
consider other messages or events to be inconsistencies. consider other messages or events to be inconsistencies.
A node SHOULD NOT reset its DIO trickle timer in response to unicast A node SHOULD NOT reset its DIO trickle timer in response to unicast
DIS messages. When a node receives a unicast DIS without a Solicited DIS messages. When a node receives a unicast DIS without a Solicited
Information option, it MUST unicast a DIO to the sender in response. Information option, it MUST unicast a DIO to the sender in response.
This DIO MUST include a DODAG Configuration option. When a node This DIO MUST include a DODAG Configuration option. When a node
receives a unicast DIS message with a Solicited Information option, receives a unicast DIS message with a Solicited Information option,
if it satisfies the predicates of the Solicited Information option it if it satisfies the predicates of the Solicited Information option it
MUST unicast a DIO to the sender in response. This unicast DIO MUST MUST unicast a DIO to the sender in response. This unicast DIO MUST
include a DODAG Configuration Option. Thus a node may transmit a include a DODAG Configuration Option. Thus a node may transmit a
unicast DIS message to a potential DAO parent in order to probe for unicast DIS message to a potential DODAG parent in order to probe for
DODAG Configuration and other parameters. DODAG Configuration and other parameters.
7.3.1. Trickle Parameters 7.3.1. Trickle Parameters
The configuration parameters of the trickle timer are specified as The configuration parameters of the trickle timer are specified as
follows: follows:
Imin: learned from the DIO message as (2^DIOIntervalMin)ms. The Imin: learned from the DIO message as (2^DIOIntervalMin)ms. The
default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.
skipping to change at page 57, line 35 skipping to change at page 60, line 47
LLN. LLN.
A node SHOULD verify that bidirectional connectivity and adequate A node SHOULD verify that bidirectional connectivity and adequate
link quality is available with a candidate neighbor before it link quality is available with a candidate neighbor before it
considers that candidate as a DODAG parent. considers that candidate as a DODAG parent.
7.5. Operation as a Leaf Node 7.5. Operation as a Leaf Node
In some cases a RPL node may attach to a DODAG as a leaf node only. In some cases a RPL node may attach to a DODAG as a leaf node only.
One example of such a case is when a node does not understand the RPL One example of such a case is when a node does not understand the RPL
Instance's OF or advertised path metric. A leaf node does not extend Instance's OF or advertised metric/constraint. As specified in
DODAG connectivity but still needs to advertise its presence using Section 16.6 related to policy function, the node may either join the
DIOs. A node operating as a leaf node must obey the following rules: DODAG as a leaf node or may not join the DODAG. As mentioned in
Section 16.5, it is then recommended to log a fault.
A leaf node does not extend DODAG connectivity but in some cases the
leaf node may still need to transmit DIOs on occasion, in particular
when the leaf node may not have always been acting as a leaf node and
an inconsistency is detected.
A node operating as a leaf node must obey the following rules:
1. It MUST NOT transmit DIOs containing the DAG Metric Container. 1. It MUST NOT transmit DIOs containing the DAG Metric Container.
2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK. 2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK.
3. It MAY transmit unicast DAOs as described in Section 8.2. 3. It MAY suppress DIO transmission, except DIO transmission MUST
NOT be suppressed when DIO transmission has been triggered due to
detection of inconsistency when a packet is being forwarded or in
response to a unicast DIS message.
4. It MAY transmit multicast DAOs to the '1 hop' neighborhood as 4. It MAY transmit unicast DAOs as described in Section 8.2.
5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as
described in Section 8.10. described in Section 8.10.
In some cases it is necessary for a leaf node to send a DIO, for A particular case that requires a leaf node to send a DIO is if that
example if that leaf node was a prior member of another DODAG and leaf node was a prior member of another DODAG and another node
another node forwards a message assuming the old topology, triggering forwards a message assuming the old topology, triggering an
an inconsistency. The leaf node needs to transmit a DIO in order to inconsistency. The leaf node needs to transmit a DIO in order to
participate in the repair. It is not expected that such a leaf node repair the inconsistency. Note that due to the lossy nature of LLNs,
would advertise itself as a router. even though the leaf node may have optimistically poisoned its routes
by advertising a rank of INFINITE_RANK in the old DODAG prior to
becoming a leaf node, that advertisement may have become lost and a
leaf node must be capable to send a DIO later in order to repair the
inconsistency.
In general it is not expected that such a leaf node would advertise
itself as a router.
7.6. Administrative Rank 7.6. Administrative Rank
In some cases it might be beneficial to adjust the rank advertised by In some cases it might be beneficial to adjust the rank advertised by
a node beyond that computed by the OF based on some implementation a node beyond that computed by the OF based on some implementation
specific policy and properties of the node. For example, a node that specific policy and properties of the node. For example, a node that
has limited battery should be a leaf unless there is no other choice, has limited battery should be a leaf unless there is no other choice,
and may then augment the rank computation specified by the OF in and may then augment the rank computation specified by the OF in
order to expose an exaggerated rank. order to expose an exaggerated rank.
skipping to change at page 58, line 44 skipping to change at page 62, line 34
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.
8.1. Destination Advertisement Parents 8.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.
o A node's DAO parent set MUST be a subset of its parent set. o A node's DAO parent set MUST be a subset of its DODAG parent set.
o A node MUST NOT unicast DAOs to nodes that are not DAO parents. o A node MUST NOT unicast DAOs to nodes that are not DAO parents.
o A node MAY link-local multicast DAO messages. o A node MAY link-local multicast DAO messages.
o The IPv6 Source Address of a DAO message MUST be the link local o The IPv6 Source Address of a DAO message MUST be the link local
address of the sending node. address of the sending node.
o If a node sends a DAO to one DAO parent, it MUST send a DAO with o If a node sends a DAO to one DAO parent, it MUST send a DAO with
the same DAOSequence to all other DAO parents. the same DAOSequence to all other DAO parents.
The selection of DAO parents is implementation and objective function The selection of DAO parents is implementation and objective function
specific. specific.
8.2. Downward Route Discovery and Maintenance 8.2. Downward Route Discovery and Maintenance
Destination Advertisement may be configured to operate in either a Destination Advertisement may be configured to be entirely disabled,
storing or non-storing mode, as reported in the MOP in the DIO or operate in either a storing or non-storing mode, as reported in
message. the MOP in the DIO message.
1. If the 'A' (Destination Advertisement Supported) flag of DIO 1. All nodes who join a DODAG MUST abide by the MOP setting from the
messages for the RPL Version is not set, nodes MUST NOT transmit root. Nodes that do not have the capability to fully participate
DAO messages, MAY ignore DAO messages, and MAY ignore the MOP as a router MAY join the DODAG as a leaf.
field of DIOs.
2. All nodes who join a DODAG with the 'A' flag set MUST follow the 2. If the MOP is 000, indicating no downward routing, nodes MUST NOT
MOP setting from the root. Nodes that do not have the capability transmit DAO messages, and MAY ignore DAO messages.
to fully participate as a router MAY join the DODAG as a leaf.
3. In storing mode, all non-root, non-leaf nodes MUST store routing 3. In non-storing mode, the DODAG Root MUST store source routing
table entries for all destinations learned from DAOs. table entries for all destinations learned from DAOs.
4. In non-storing mode, the DODAG Root MUST store source routing 4. In storing mode, all non-root, non-leaf nodes MUST store routing
table entries for all destinations learned from DAOs. table entries for all destinations learned from DAOs.
A DODAG can have one of three settings. Either it does not support A DODAG can have one of several possible modes of operation, as
downward routes (the 'A' flag in DIOs is cleared), it supports defined by the MOP field. Either it does not support downward
downward routes through source routing from DODAG Roots (the 'A' flag routes, it supports downward routes through source routing from DODAG
is set and the MOP indicates non-storing), or it supports downward Roots, or it supports downward routes through in-network routing
routes through in-network routing tables (the 'A' flag is set and the tables. When downward routes are supported through in-network
MOP indicates storing). As of this specification RPL does not routing tables, the multicast operation defined in this specification
support mixed-mode operation, where some nodes source route and other may or may not be supported, also as indicated by the MOP field. As
store routing tables: future extensions to RPL may support this mode of this specification RPL does not support mixed-mode operation,
of operation. where some nodes source route and other store routing tables: future
extensions to RPL may support this mode of operation.
8.3. DAO Base Rules 8.3. DAO Base Rules
1. Each time a node generates a new DAO, the DAOSequence field MUST 1. Each time a node generates a new DAO, the DAOSequence field MUST
increment by at least one since the last generated DAO. increment by at least one since the last generated DAO.
2. Each time a node link-local multicasts a DAO, the DAOSequence 2. Each time a node link-local multicasts a DAO, the DAOSequence
field MUST increment by one since the last link local multicast field MUST increment by one since the last link local multicast
DAO. DAO.
skipping to change at page 61, line 5 skipping to change at page 64, line 40
8.5. Triggering DAO Messages 8.5. Triggering DAO Messages
Nodes can trigger their sub-DODAG to send DAO messages. Each node Nodes can trigger their sub-DODAG to send DAO messages. Each node
maintains a DAO Trigger Sequence Number (DTSN), which it communicates maintains a DAO Trigger Sequence Number (DTSN), which it communicates
through DIO messages. through DIO messages.
1. If a node hears one of its DAO parents increment its DTSN, the 1. If a node hears one of its DAO parents increment its DTSN, the
node MUST schedule a DAO transmission using rules in Section 8.3 node MUST schedule a DAO transmission using rules in Section 8.3
and Section 8.4. and Section 8.4.
2. If a node hears one of its parents send a DIO with the 'T' bit 2. In non-storing mode, if a node hears one of its DAO parents
set and a newly incremented DTSN, the node MUST increment its own increment its DTSN, the node MUST increment its own DTSN.
DTSN, MUST set the 'T' bit in its own DIOs, and MUST schedule a
DAO transmission using rules in Section 8.3 and Section 8.4.
A node may increment DTSN in order to reliably trigger a set of DAO In a storing mode of operation, a storing node MAY increment DTSN in
updates from its immediate children, as part of a routine routing order to reliably trigger a set of DAO updates from its immediate
table update. A node may increment DTSN and set the 'T' bit in order children, as part of routine routing table updates and maintenance.
to trigger a set of DAO updates from its entire sub-DODAG. In a storing mode of operation it is not necessary to trigger DAO
updates from the entire sub-DODAG, since that state information will
percolate hop-by-hop up the DODAG in the storing mode of operation.
In a non-storing mode of operation, a DTSN increment will also cause
the immediate children of a node to increment their DTSN in turn,
triggering a set of DAO updates from the entire sub-DODAG. In a non-
storing mode of operation typically only the root would independently
increment the DTSN when a DAO refresh is needed but a global repair
(such as by incrementing DODAGVersionNumber) is not desired. In a
non-storing mode of operation typically all non-root nodes would only
increment their DTSN when their parent(s) are observed to do so.
In the case of triggered DAOs, selecting a proper DAODelay can In the case of triggered DAOs, selecting a proper DAODelay can
greatly reduce the number of DAOs transmitted. The trigger flows greatly reduce the number of DAOs transmitted. The trigger flows
down the DODAG; in the best case the DAOs flow up the DODAG such that down the DODAG; in the best case the DAOs flow up the DODAG such that
leaves send DAOs first, with each node sending a DAO only once. Such leaves send DAOs first, with each node sending a DAO only once. Such
a scheduling could be approximated by setting DAODelay inversely a scheduling could be approximated by setting DAODelay inversely
proportional to Rank. Note that this suggestion is intended as an proportional to Rank. Note that this suggestion is intended as an
optimization to allow efficient aggregation -- it is not required for optimization to allow efficient aggregation -- it is not required for
correct operation in the general case. correct operation in the general case.
8.6. Structure of DAO Messages 8.6. Structure of DAO Messages
DAOs follow a common structure in both storing and non-storing DAOs follow a common structure in both storing and non-storing
networks. Later sections describe further details for each mode of networks. Later sections describe further details for each mode of
operation. operation.
1. RPL nodes MUST include one or more RPL Target Options in each DAO 1. RPL nodes MUST include one or more RPL Target Options in each DAO
they transmit. One RPL Target Option MUST have a prefix that they transmit. One RPL Target Option MUST have a prefix that
includes the node's IPv6 address. includes the node's IPv6 address if that node needs the DODAG to
provision downward routes to that node.
2. A RPL Target Option in a unicast DAO MUST be followed by a 2. A RPL Target Option in a unicast DAO MUST be followed by a
Transit Information Option. Transit Information Option.
3. Multicast DAOs MUST NOT include Transit Information options. 3. Multicast DAOs MUST NOT include Transit Information options.
4. If a node receives a DAO that does not follow the above three 4. If a node receives a DAO that does not follow the above three
rules, it MUST discard the DAO without further processing. rules, it MUST discard the DAO without further processing.
8.7. Non-storing Mode 8.7. Non-storing Mode
skipping to change at page 62, line 6 skipping to change at page 65, line 50
In non-storing mode, RPL routes messages downward using source In non-storing mode, RPL routes messages downward using source
routing. The following rule applies to nodes that are in non-storing routing. The following rule applies to nodes that are in non-storing
mode. Storing mode has a separate set of rules, described in mode. Storing mode has a separate set of rules, described in
Section 8.8. Section 8.8.
1. The Parent Address field of a Transit Information Option MUST 1. The Parent Address field of a Transit Information Option MUST
contain one or more addresses. All of these addresses MUST be contain one or more addresses. All of these addresses MUST be
addresses of DAO parents of the sender. addresses of DAO parents of the sender.
2. On receiving a unicast DAO, a node MUST forward the DAO upwards. 2. On receiving a unicast DAO, a node MUST forward the DAO upwards.
This forwarding MAY use any parent in the parent set. This forwarding MAY use any parent in the parent set. Note that
this forwarding may be delayed in support of aggregation as
described below, but that such a delay is not required if a
node's resources do not support it.
3. When a node removes a node from its DAO parent set, it MAY 3. When a node removes a node from its DAO parent set, it MAY
generate a new DAO with an updated Transit Information option. generate a new DAO with an updated Transit Information option.
In non-storing mode, a node uses DAOs to report its DAO parents to In non-storing mode, a node uses DAOs to report its DAO parents to
the DODAG Root. The DODAG Root can piece together a downward route the DODAG Root. The DODAG Root can piece together a downward route
to a node by using DAO parent sets from each node in the route. The to a node by using DAO parent sets from each node in the route. The
purpose of this per-hop route calculation is to minimize traffic when purpose of this per-hop route calculation is to minimize traffic when
DAO parents change. If nodes reported complete source routes, then DAO parents change. If nodes reported complete source routes, then
on a DAO parent change the entire sub-DODAG would have to send new on a DAO parent change the entire sub-DODAG would have to send new
skipping to change at page 63, line 25 skipping to change at page 67, line 25
8.9. Path Control 8.9. Path Control
A DAO message from a node contains one or more Target Options. Each A DAO message from a node contains one or more Target Options. Each
Target Option specifies either the node's prefix, a prefix of Target Option specifies either the node's prefix, a prefix of
addresses reachable outside the LLN, or a destination in the node's addresses reachable outside the LLN, or a destination in the node's
sub-DODAG. The Path Control field of the Transit Information option sub-DODAG. The Path Control field of the Transit Information option
allows nodes to request multiple downward routes. A node constructs allows nodes to request multiple downward routes. A node constructs
the Path Control field of a Transit Information option as follows: the Path Control field of a Transit Information option as follows:
1. The bit width of the path control field MUST be equal to the 1. The bit width of the path control field MUST be equal to the
value specified in the PCS control field of the DODAG value (PCS + 1), where PCS is specified in the control field of
Configuration Option. Bits greater than or equal to the value the DODAG Configuration Option. Bits greater than or equal to
specified in the PCS control field MUST be cleared on the value (PCS + 1) MUST be cleared on transmission and MUST be
transmission and MUST be ignored on reception. Bits below the ignored on reception. Bits below that value are considered
value in the PCS control field are considered "active" bits. "active" bits.
2. For a RPL Target option describing a node's own address or a 2. For a RPL Target option describing a node's own address or a
prefix outside the LLN, at least one active bit of the Path prefix outside the LLN, at least one active bit of the Path
Control field MUST be set. More active bits of the Path Control Control field MUST be set. More active bits of the Path Control
field MAY be set. field MAY be set.
3. If a node receives multiple DAOs with the same RPL Target option, 3. If a node receives multiple DAOs with the same RPL Target option,
it MUST bitwise-OR the Path Control fields it receives. This it MUST bitwise-OR the Path Control fields it receives. This
aggregated bitwise-OR represents the number of downward routes aggregated bitwise-OR represents the number of downward routes
the prefix requests. the prefix requests.
skipping to change at page 67, line 24 skipping to change at page 71, line 24
using Key Index 0x00 a node can join the RPL Instance as a host but using Key Index 0x00 a node can join the RPL Instance as a host but
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. Obtaining this key a key that will enable it to act as a router. Obtaining this key
might require authentication on one or both ends. This message might require authentication on one or both ends. This message
exchange is TBD. exchange is TBD.
9.4. Counter and Counter Compression 9.4. Counter and Counter Compression
Every secured RPL packet has a Counter field. Depending on whether Every secured RPL packet has a Counter field. Depending on whether
the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL nodes the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL nodes
send CC messages to force uncompressed Counter values, protecting send CC messages to force uncompressed Counter values, protect
against replay attacks and synchronizing counters. against replay attacks and synchronize counters.
1. If a node is sending a secured RPL packet, and the Counter value 1. If a node is sending a secured RPL packet, and the Counter value
of the packet is more than 255 greater than the last secured of the packet is more than 255 greater than the last secured
packet to the destination address, the node MUST NOT set the 'C' packet to the destination address, the node MUST NOT set the 'C'
bit of the security section of the packet. bit of the security section of the packet.
2. If a node receives a secure RPL message with the C bit set and is 2. If a node receives a secure RPL message with the C bit set and is
uncertain of the 32-bit counter value, it MAY send a CC message uncertain of the 32-bit counter value, it MAY send a CC message
with the R bit cleared to obtain an uncompressed counter value. with the R bit cleared to obtain an uncompressed counter value.
The Nonce field of the CC message SHOULD be a random or The Nonce field of the CC message SHOULD be a random or
skipping to change at page 68, line 48 skipping to change at page 72, line 48
the 'T' flag set, it MUST NOT apply this temporal check. A node's the 'T' flag set, it MUST NOT apply this temporal check. A node's
security policy MAY, for application reasons, include rejecting all security policy MAY, for application reasons, include rejecting all
messages without the 'T' flag set. messages without the 'T' flag set.
9.5. Functional Description of Packet Protection 9.5. Functional Description of Packet Protection
9.5.1. Transmission of Outgoing Packets 9.5.1. Transmission of Outgoing Packets
Given an outgoing RPL control packet and required security Given an outgoing RPL control packet and required security
protection, this section describes how RPL generates the secured protection, this section describes how RPL generates the secured
packet to transmit. It describes the order of cryptographic packet to transmit. It also describes the order of cryptographic
operations to provide the required protection. operations to provide the required protection.
A RPL node MUST set the security section (KIM, LVL, T, and Sec) in The requirement for security protection and the level of security to
the RPL packet to describe the required protection level. be applied to an outgoing RPL packet shall be determined by the
node's security policy database. The configuration of this security
policy database for outgoing packet processing is TBD (it may, for
example, be defined through DIO Configuration or through out-of-band
administrative router configuration).
The Counter field of the security header MUST be an increment of the Where secured RPL messages are to be transmitted, a RPL node MUST set
last Counter field transmitted. the security section (C, T, Sec, KIM, and LVL) in the outgoing RPL
packet to describe the protection level and security settings that
are applied (see Section 5.1). The Security subfield bit of the RPL
message Code field MUST be set to indicate the secure RPL message.
If the RPL packet is not a response to a Consistency Check message, The Counter value used in constructing the Nonce to secure the
the node MAY set the Counter Compression flag of the security option, outgoing packet MUST be an increment of the last Counter transmitted
following the rules in Section 9.4. to the particular destination address. Where a Counter for the
intended destination address has not been established, the Counter
value MUST be initialized to zero and sent as a Full Counter for the
initial RPL message transmission.
If the Key Identifier Mode (KIM) is 3 (signature key used), and the Where a Counter is currently maintained for outgoing messages to the
Security Level (LVL) calls for encryption, the transmitter MUST intended destination address, the Compressed Counter (indicated with
include the Key Source Identifier and Key Index in the security the 'C' bit set) MUST be transmitted within the secured RPL message,
section and append a signature using its signature key. provided the message is not a RPL Consistency Check message. The
current Full Counter (indicated with the 'C' bit cleared) for the
given destination address SHALL always be used when the outgoing
packet is a Consistency Check (challenge or response) message. Where
a Counter for the intended destination address does not exist, the
initialized (zero-value), Full Counter MUST be transmitted within the
initial RPL control message. Where security policy specifies the
application of delay protection, the Timestamp Counter used in
constructing the Nonce to secure the outgoing packet MUST be
incremented according to the rules in Section 9.4.1. Where a
Timestamp Counter is applied (indicated with the 'T' flag set) the
locally maintained Time Counter MUST be included as part of the
transmitted secured RPL message.
A node MUST replaced the original packet payload with that payload The cryptographic algorithm used in securing the outgoing packet
encrypted using the security protection, key, and nonce specified in shall be specified by the node's security policy database and MUST be
the security section. indicated in the value of the Sec field set within the outgoing
message.
The security policy for the outgoing packet shall determine the
applicable Key Identifier Mode (KIM) and Key Identifier specifying
the security key to be used for the cryptographic packet processing,
including the optional use of signature keys (see Section 5.1). The
security policy will also specify the level of protection (LVL) in
the form of authentication or authentication and encryption, and
potential use of signatures that shall apply to the outgoing packet.
Where encryption is applied, a node MUST replace the original packet
payload with that payload encrypted using the security protection,
key, and nonce specified in the security section of the packet.
All secured RPL messages include integrity protection. In
conjunction with the security algorithm processing, a node derives a
Message Authentication Code (MAC) that MUST be included as part of
the outgoing secured RPL packet.
9.5.2. Reception of Incoming Packets 9.5.2. Reception of Incoming Packets
This section describes the reception of a secured RPL packet. Given This section describes the reception and processing of a secured RPL
an incoming RPL packet, this section describes now RPL generates an packet. Given an incoming secured RPL packet, where the Security
unencrypted version of the packet and validates its integrity. subfield bit of the RPL message Code field is set, this section
describes how RPL generates an unencrypted version of the packet and
validates its integrity.
The receiver uses the security control field of the security section The receiver uses the RPL security control fields to determine the
to determine what processing to do. If the described level of necessary packet security processing. If the described level of
security does not meet locally maintained security policies, a node security for the message type and originator does not meet locally
MAY discard the packet without further processing. These policies maintained security policies, a node MAY discard the packet without
can include security levels, keys used, source identifiers, or the further processing. These policies can include security levels, keys
lack of timestamp-based counters (the 'T' flag). used, source identifiers, or the lack of timestamp-based counters (as
indicated by the 'T' flag). The configuration of the security policy
database for incoming packet processing is TBD (it may, for example,
be defined through DIO Configuration or through out-of-band
administrative router configuration).
Using a nonce derived from the Counter field and other information Where the message security level (LVL) indicates an encrypted RPL
(as described in Section Figure 24), the receiver checks the message, the node uses the key information identified through the KIM
integrity of the packet. If this integrity check does not pass, a field as well as the Nonce as input to the message payload decryption
node MUST discard the packet. processing. The Nonce shall be derived from the message Counter
field and other received and locally maintained information (see
Section 9.5.3.1). The plaintext message contents shall be obtained
by invoking the inverse cryptographic mode of operation specified by
the Sec field of the received packet.
RPL uses the key information described in a RPL message to decrypt The receiver shall use the Nonce and identified key information to
its contents as necessary. Once a message has passed its integrity check the integrity of the incoming packet. If the integrity check
checks and been successfully decrypted, the node can update its local fails against the received message authentication code (MAC), a node
security information, such as the source's expected counter value for MUST discard the packet.
counter compression. A node MUST NOT update security information on
receipt of a message that fails security policy checks, integrity If a Compressed Counter is received and the node does not currently
checks, or decryption. have an incoming Counter currently maintained for the originator of
the message, the node MUST send a Consistency Check request to the
message source to update the Counters.
If an initialized (zero value) Full Counter is received in a secured
RPL message and the receiving node currently has an incoming Counter
currently maintained for the originator of the message, the node MUST
initiate a Counter resynchronization by sending a Consistency Check
response message (see Section 5.6.1) to the message source. The
Consistency Check response message shall be protected with the
current full outgoing Counter maintained for the particular node
address. That outgoing Counter will be included within the security
section of the message while the incoming Counter will be included
within the Consistency Check message payload.
Based on the specified security policy a node MAY apply replay
protection for a received RPL message. The replay check MUST be
performed following the authentication of the received packet. The
full Counter, as obtained from the incoming packet or as derived from
the received Compressed Counter shall be compared against the
watermark of the incoming Counter maintained for the given
origination node address. If the received message Counter value is
non-zero and less than the maintained incoming Counter watermark a
potential packet replay is indicated and the node MUST discard the
incoming packet.
If delay protection is specified as part of the incoming packet
security policy checks, the Timestamp Counter is used to validate the
timeliness of the received RPL message. If the incoming message
Timestamp Counter value indicates a message transmission time prior
to the locally maintained transmission time Counter for the
originator address, a replay violation is indicated and the node MUST
discard the incoming packet. If the received Timestamp Counter value
indicates a message transmission time that is earlier than the
Current time less the acceptable packet delay, a delay violation is
indicated and the node MUST discard the incoming packet.
Once a message has been decrypted, where applicable, and has
successfully passed its integrity check, replay, and optionally delay
protection checks, the node can update its local security
information, such as the source's expected Counter value for counter
compression and replay comparison.
A node MUST NOT update its security information on receipt of a
message that fails security policy checks or other applied integrity,
replay, or delay checks.
9.5.2.1. Timestamp Key Checks 9.5.2.1. Timestamp Key Checks
If the 'T' flag of a message is set and a node has a local timestamp If the 'T' flag of a message is set and a node has a local timestamp
that follows the requirements in Section 9.4.1, then a node MAY check that follows the requirements in Section 9.4.1, then a node MAY check
the temporal consistency of the message. The node computes the the temporal consistency of the message. The node computes the
transmit time of the message by adding the Counter value to the start transmit time of the message by adding the Counter value to the start
time of the associated key. If this transmit time is past the end time of the associated key. If this transmit time is past the end
time of the key, the node MAY discard the message without further time of the key, the node MAY discard the message without further
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
skipping to change at page 72, line 21 skipping to change at page 78, line 28
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, then use that 3. If the packet header specifies a source route, then use that
route [I-D.hui-6man-rpl-routing-header]. If the node fails to route [I-D.hui-6man-rpl-routing-header]. If the node fails to
forward the packet with that specified source route, then that forward the packet with that specified source route, then that
packet SHOULD be dropped. The node MAY log an error. The node packet SHOULD be dropped. The node MAY log an error. The node
MAY send an ICMPv6 Error in Source Routing Header message to the MAY send an ICMPv6 Error in Source Routing Header message to the
DODAG root Section 17.6. source of the packet Section 18.6.
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 74, line 33 skipping to change at page 80, line 37
associated to a given instance. 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. For traffic originating placed by any node, be it a host or router. For traffic originating
outside of the RPL domain there may be a mapping occurring at the outside of the RPL domain there may be a mapping occurring at the
gateway into the RPL domain, possibly based on an encoding within the gateway into the RPL domain, possibly based on an encoding within the
flow label. This aspect of RPL operation is to be clarified in a flow label. This aspect of RPL operation is to be clarified in a
future version of this specification. future version of this specification.
The source of the packet might be aware of the RPL network, of the
constraints imposed on OFs, and of associated Instance IDs. In that
case, the source of the packet MAY tag the flow label with the
RPLInstanceID, in which case it is used in that form within the RPL
network.
A router that injects a data packet into the RPL network MUST tag the
packet by inserting a RPL Hop-by-hop option as specified in
[I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in
flow label of the data packet, the ingress router that injects the
packet into the RPL network MUST add a RPLInstanceID field to the RPL
Hop-by-hop option.
A router that forwards a packet to outside the RPL network MUST
remove the RPL Hop-by-hop 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
the RPLInstanceID, then the node SHOULD discard the packet and send the RPLInstanceID, then the node SHOULD discard the packet and send
an ICMP error message. an ICMP error message.
10.2.2.2. DAG Inconsistency Loop Detection 10.2.2.2. DAG Inconsistency Loop Detection
skipping to change at page 76, line 13 skipping to change at page 83, line 13
cleaned up as well. cleaned up as well.
11. Multicast Operation 11. Multicast Operation
This section describes further the multicast routing operations over This section describes further the multicast routing operations over
an IPv6 RPL network, and specifically how unicast DAOs can be used to an IPv6 RPL network, and specifically how unicast DAOs can be used to
relay group registrations up. Wherever the following text mentions relay group registrations up. Wherever the following text mentions
Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or
MLDv2 ([RFC3810]). MLDv2 ([RFC3810]).
Nodes that support the RPL storing mode of operation SHOULD also
support multicast DAO operations as described below. Nodes that only
support the non-storing mode of operation are not expected to support
this section.
The multicast operation is controlled by the MOP field in the DIO.
If the MOP field requires multicast support, then a node that
joins the RPL network as a router must operate as described in
this section for multicast signaling and forwarding within the RPL
network. A node that does not support the multicast operation
required by the MOP field can only join as a leaf.
If the MOP field does not require multicast support, then
multicast is handled by some other way that is out of scope for
this specification. (Examples may include as a series of unicast
copies or limited-scope flooding)
As is traditional, a listener uses a protocol such as MLD with a As is traditional, a listener uses a protocol such as MLD with a
router to register to a multicast group. router to register to a multicast group.
Along the path between the router and the DODAG root, MLD requests Along the path between the router and the DODAG root, MLD requests
are mapped and transported as DAO messages within the RPL protocol; are mapped and transported as DAO messages within the RPL protocol;
each hop coalesces the multiple requests for a same group as a single each hop coalesces the multiple requests for a same group as a single
DAO message to the parent(s), in a fashion similar to proxy IGMP, but DAO message to the parent(s), in a fashion similar to proxy IGMP, but
recursively between child router and parent up to the root. recursively between child router and parent up to the root.
A router might select to pass a listener registration DAO message to A router might select to pass a listener registration DAO message to
skipping to change at page 79, line 37 skipping to change at page 88, line 5
* 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 self are
ignored ignored
* Candidate neighbors of an equal rank to self are ignored for * Candidate neighbors of an equal rank to self are ignored for
parent selection parent selection
* Candidate neighbors of a lesser rank than self are preferred * Candidate neighbors of a lesser rank than self are preferred
14. RPL Constants and Variables 14. Suggestions for Interoperation with Neighbor Discovery
Following is a summary of RPL constants and variables. This specification directly borrows the Prefix Information Option
(PIO) and the Routing Information Option (RIO) from IPv6 ND. It is
envisioned that as future specifications build on this base that
there may be additional cause to leverage parts of IPv6 ND. This
section provides some suggestions for future specifications.
First and foremost RPL is a routing protocol. One should take great
care to preserve architecture when mapping functionalities between
RPL and ND. RPL is for routing only. That said, there may be
persuading technical reasons to allow for sharing options between RPL
and IPv6 ND in a particular implementation/deployment.
In general the following guidelines apply:
o RPL Type codes must be allocated from the RPL Control Message
Options registry.
o RPL Length fields must be expressed in units of single octets, as
opposed to ND Length fields which are expressed in units of 8
octets.
o RPL Options are generally not required to be aligned to 8 octet
boundaries.
o When mapping/transposing an IPv6 ND option for redistribution as a
RPL option, any padding octets should be removed when possible.
For example, the Prefix Length field in the PIO is sufficient to
describe the length of the Prefix field. When mapping/transposing
a RPL option for redistribution as an IPv6 ND option, any such
padding octets should be restored. This procedure must be
unambiguous.
15. RPL Constants and Variables
Following is a summary of RPL constants and variables:
BASE_RANK This is the rank for a virtual root that might be used to BASE_RANK This is the rank for a virtual root that might be used to
coordinate multiple roots. BASE_RANK has a value of 0. coordinate multiple roots. BASE_RANK has a value of 0.
ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value
of MinHopRankIncrease (as advertised by the DODAG root), such of MinHopRankIncrease (as advertised by the DODAG root), such
that DAGRank(ROOT_RANK) is 1. that DAGRank(ROOT_RANK) is 1.
INFINITE_RANK This is the constant maximum for the rank. INFINITE_RANK This is the constant maximum for the rank.
INFINITE_RANK has a value of 0xFFFF. INFINITE_RANK has a value of 0xFFFF.
RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this
protocol by a node without any overriding policy. protocol by a node without any overriding policy.
RPL_DEFAULT_INSTANCE has a value of 0. RPL_DEFAULT_INSTANCE has a value of 0.
DEFAULT_PATH_CONTROL_SIZE TBD (To be determined) DEFAULT_PATH_CONTROL_SIZE This is the default value used to
configure PCS in the DODAG Configuration Option, which dictates
the number of significant bits in the Path Control field of the
Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a
value of 0. This configures the simplest case-- limiting the
fan-out to 1 and limiting a node to send a DAO message to only
one parent.
DEFAULT_DIO_INTERVAL_MIN TBD (To be determined) DEFAULT_DIO_INTERVAL_MIN This is the default value used to configure
Imin for the DIO trickle timer. DEFAULT_DIO_INTERVAL_MIN has a
value of 3. This configuration results in Imin of 8ms.
DEFAULT_DIO_INTERVAL_DOUBLINGS TBD (To be determined) DEFAULT_DIO_INTERVAL_DOUBLINGS This is the default value used to
configure Imax for the DIO trickle timer.
DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This
configuration results in a maximum interval of 2.3 hours.
DEFAULT_DIO_REDUNDANCY_CONSTANT TBD (To be determined) DEFAULT_DIO_REDUNDANCY_CONSTANT This is the default value used to
configure k for the DIO trickle timer.
DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This
configuration is a conservative value for trickle suppression
mechanism.
DEFAULT_MIN_HOP_RANK_INCREASE TBD a power of two (To be determined) DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of
MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value
of 256. This configuration results in an 8-bit wide integer
part of Rank.
DIO Timer One instance per DODAG that a node is a member of. Expiry DIO Timer One instance per DODAG that a node is a member of. Expiry
triggers DIO message transmission. Trickle timer with variable triggers DIO message transmission. Trickle timer with variable
interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See
Section 7.3.1 Section 7.3.1
DAG Version Increment Timer Up to one instance per DODAG that the DAG Version Increment Timer Up to one instance per DODAG that the
node is acting as DODAG root of. May not be supported in all node is acting as DODAG root of. May not be supported in all
implementations. Expiry triggers increment of implementations. Expiry triggers increment of
DODAGVersionNumber, causing a new series of updated DIO message DODAGVersionNumber, causing a new series of updated DIO message
skipping to change at page 80, line 44 skipping to change at page 91, line 5
DODAG. Expiry triggers sending of DAO message to the DAO DODAG. Expiry triggers sending of DAO message to the DAO
parent. See Section 8.4 parent. See Section 8.4
RemoveTimer Up to one instance per DAO entry per neighbor (i.e. RemoveTimer Up to one instance per DAO entry per neighbor (i.e.
those neighbors that have given DAO messages to this node as a those neighbors that have given DAO messages to this node as a
DODAG parent) Expiry triggers a change in state for the DAO DODAG parent) Expiry triggers a change in state for the DAO
entry, setting up to do unreachable (No-Path) advertisements or entry, setting up to do unreachable (No-Path) advertisements or
immediately deallocating the DAO entry if there are no DAO immediately deallocating the DAO entry if there are no DAO
parents. parents.
15. Manageability Considerations 16. Manageability Considerations
The aim of this section is to give consideration to the manageability The aim of this section is to give consideration to the manageability
of RPL, and how RPL will be operated in a LLN. The scope of this of RPL, and how RPL will be operated in a LLN. The scope of this
section is to consider the following aspects of manageability: section is to consider the following aspects of manageability:
configuration, monitoring, fault management, accounting, and configuration, monitoring, fault management, accounting, and
performance of the protocol in light of the recommendations set forth performance of the protocol in light of the recommendations set forth
in [RFC5706]. in [RFC5706].
15.1. Introduction 16.1. Introduction
Most of the existing IETF management standards are Structure of Most of the existing IETF management standards are Structure of
Management Information (SMI) based data models (MIB modules) to Management Information (SMI) based data models (MIB modules) to
monitor and manage networking devices. monitor and manage networking devices.
For a number of protocols, the IETF community has used the IETF For a number of protocols, the IETF community has used the IETF
Standard Management Framework, including the Simple Network Standard Management Framework, including the Simple Network
Management Protocol [RFC3410], the Structure of Management Management Protocol [RFC3410], the Structure of Management
Information [RFC2578], and MIB data models for managing new Information [RFC2578], and MIB data models for managing new
protocols. protocols.
skipping to change at page 82, line 5 skipping to change at page 92, line 10
RPL will be used on a variety of devices that may have resources such RPL will be used on a variety of devices that may have resources such
as memory varying from a very few Kbytes to several hundreds of as memory varying from a very few Kbytes to several hundreds of
Kbytes and even Mbytes. When memory is highly constrained, it may Kbytes and even Mbytes. When memory is highly constrained, it may
not be possible to satisfy all the requirements listed in this not be possible to satisfy all the requirements listed in this
section. Still it is worth listing all of these in an exhaustive section. Still it is worth listing all of these in an exhaustive
fashion, and implementers will then determine which of these fashion, and implementers will then determine which of these
requirements could be satisfied according to the available resources requirements could be satisfied according to the available resources
on the device. on the device.
15.2. Configuration Management 16.2. Configuration Management
15.2.1. Initialization Mode 16.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 especially true in LLNs where the number of than manually. This 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.
15.2.1.1. DIS mode of operation upon boot-up 16.2.1.1. DIS mode of operation upon boot-up
When a node is first powered up, it may either choose to stay silent When a node is first powered up:
and not send any multicast DIO messages until it has joined a DODAG,
or to immediately root a transient DODAG and start sending multicast
DIO messages. A RPL implementation SHOULD allow configuring whether
the node should stay silent or should start advertising DIO messages.
Furthermore, the implementation SHOULD allow configuring whether or 1. The node may decide to stay silent, waiting to receive DIO
not the node should start sending an DIS (optionally requesting DIO messages from DODAG of interest (advertising a supported OF and
for a specific DODAG) message as an initial probe for nearby DODAGs, metrics/constraints) and not send any multicast DIO messages
or should simply wait until it receives DIO messages from other until it has joined a DODAG.
neighboring nodes that are part of existing DODAGs.
15.2.2. DIO and DAO Base Message and Options Configuration 2. The node may decide to send one or more DIS messages (optionally
requesting DIO for a specific DODAG) message as an initial probe
for nearby DODAGs, and in the absence of DIO messages in reply
after some configurable period of time, the node may decide to
root a floating DODAG and start sending multicast DIO messages.
A RPL implementation SHOULD allow configuring the preferred mode of
operation listed above along with the required parameters (in the
second mode: the number of DIS messages and related timer).
16.2.2. DIO and DAO Base Message and Options Configuration
RPL specifies a number of protocol parameters considering the large RPL specifies a number of protocol parameters considering the large
spectrum of applications where it will be used. That said, spectrum of applications where it will be used. That said,
particular attention has been given to limiting the number of these particular attention has been given to limiting the number of these
parameters that must be configured on each RPL router. Instead, a parameters that must be configured on each RPL router. Instead, a
number of the default values can be used, and when required these number of the default values can be used, and when required these
parameters can be provided by the DODAG root thus allowing for parameters can be provided by the DODAG root thus allowing for
dynamic parameter setting. dynamic parameter setting.
A RPL implementation SHOULD allow configuring the following routing A RPL implementation SHOULD allow configuring the following routing
protocol parameters. As pointed out above, note that a large set of protocol parameters. As pointed out above, note that a large set of
parameters is configured on the DODAG root. parameters is configured on the DODAG root.
15.2.3. Protocol Parameters to be configured on every router in the LLN 16.2.3. Protocol Parameters to be configured on every router in the LLN
o RPLInstanceID [DIO message, in DIO base message]. Although the o RPLInstanceID [DIO message, in DIO base message]. Although the
RPLInstanceID must be configured on the DODAG root, it must also RPLInstanceID must be configured on the DODAG root, it must also
be configured as a policy on every node in order to determine be configured as a policy on every node in order to determine
whether or not the node should join a particular DODAG. Note that whether or not the node should join a particular DODAG. Note that
a second RPLInstance can be configured on the node, should it a second RPLInstance can be configured on the node, should it
become root of a floating DODAG. become root of a floating DODAG.
o Objective Code Point (OCP) o Objective Code Point (OCP)
o List of supported metrics: [I-D.ietf-roll-routing-metrics]
specifies a number of metrics and constraints used for the DODAG
formation. Thus a RPL implementation should allow configuring the
list of metrics that a node can accept and understand. If a DIO
is received with a metric and/or constraint that is not understood
or supported, as specified in Section 7.5, the node would join as
a leaf node.
o DODAGID [DIO, DIO base option] and [DAO message when the D flag of o DODAGID [DIO, DIO base option] and [DAO message when the D flag of
the DAO message is set). the DAO message is set).
o Route Information (and preference) [DIO message, in Route o Route Information (and preference) [DIO message, in Route
Information option] Information option]
o Solicited Information [DIS message, in Solicited Information o Solicited Information [DIS message, in Solicited Information
option]. Note that an RPL implementation SHOULD allow configuring option]. Note that an RPL implementation SHOULD allow configuring
when such messages should be sent and under which circumstances, when such messages should be sent and under which circumstances,
along with the value of the RPLInstance ID, V/I/D flags. along with the value of the RPLInstance ID, V/I/D flags.
o [I-D.ietf-roll-routing-metrics] specifies a number of metrics and
constraints that could be used. Thus a RPL implementation should
allow configuring the list of metrics that a node can accept and
understand. If a DIO is received with a metric and/or constraint
that is not understood, as specified in Section 7.5, the node
would join as a leaf node.
o K flag [DAO message, in DAO base message]. o K flag [DAO message, in DAO base message].
o MOP (Mode of Operation) [DIO message, in DIO base message] o MOP (Mode of Operation) [DIO message, in DIO base message]
15.2.4. Protocol Parameters to be configured on every non-root router 16.2.4. Protocol Parameters to be configured on every non-root router
in the LLN in the LLN
o Target prefix [DAO, in RPL Target option and DIO messages] o Target prefix [DAO, in RPL Target option and DIO messages]
o Transit information [DAO, Transit information option]: A RPL o Transit information [DAO, Transit information option]: A RPL
implementation SHOULD allow configuring whether a non-storing node implementation SHOULD allow configuring whether a non-storing node
provides the transit information in DAO messages. provides the transit information in DAO messages.
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
o Poison the broken path (see procedure in Section 7.2.2.5) o Poison the broken path (see procedure in Section 7.2.2.5)
o Trigger a local repair o Trigger a local repair
15.2.5. Parameters to be configured on the DODAG root 16.2.5. Parameters to be configured on the DODAG root
In addition, several other parameters are configured only on the In addition, several other parameters are configured only on the
DODAG root and advertised in options carried in DIO messages. DODAG root and advertised in options carried in DIO messages.
As specified in Section 7.3, a RPL implementation makes use of As specified in Section 7.3, a RPL implementation makes use of
trickle timers to govern the sending of DIO messages. The operation trickle timers to govern the sending of DIO messages. The operation
of the trickle algorithm is determined by a set of configurable of the trickle algorithm is determined by a set of configurable
parameters, which MUST be configurable and that are then advertised parameters, which MUST be configurable and that are then advertised
by the DODAG root along the DODAG in DIO messages. by the DODAG root along the DODAG in DIO messages.
skipping to change at page 84, line 36 skipping to change at page 94, line 44
o DIORedundancyConstant [DIO, in DODAG configuration option] o DIORedundancyConstant [DIO, in DODAG configuration option]
In addition, a RPL implementation SHOULD allow for configuring the In addition, a RPL implementation SHOULD allow for configuring the
following set of RPL parameters: following set of RPL parameters:
o Path Control Size [DIO, in DODAG configuration option] o Path Control Size [DIO, in DODAG configuration option]
o MinHopRankIncrease [DIO, in DODAG configuration option] o MinHopRankIncrease [DIO, in DODAG configuration option]
o The following flags: A, MOP (Mode of Operation), DODAGPreference o The following fields: MOP (Mode of Operation), DODAGPreference
field [DIO message, DIO Base object] field [DIO message, DIO Base object]
o Route information (list of prefixes with preference) [DIO message, o Route information (list of prefixes with preference) [DIO message,
in Route Information option] in Route Information option]
o The T flag allows for triggering a refresh of the downward routes. o The T flag allows for triggering a refresh of the downward routes.
A RPL implementation SHOULD support manual setting of the T flag A RPL implementation SHOULD support manual setting of the T flag
or upon the occurrence of a set of event such as the expiration of or upon the occurrence of a set of event such as the expiration of
a configurable periodic timer. a configurable periodic timer.
skipping to change at page 85, line 22 skipping to change at page 95, line 31
support the ability to configure whether or not a node could act as a support the ability to configure whether or not a node could act as a
floating DODAG root for a configured period of time. floating DODAG root for a configured period of time.
DAG Version Number Increment: a RPL implementation may allow by DAG Version Number Increment: a RPL implementation may allow by
configuration at the DODAG root to refresh the DODAG states by configuration at the DODAG root to refresh the DODAG states by
updating the DODAGVersionNumber. A RPL implementation SHOULD allow updating the DODAGVersionNumber. A RPL implementation SHOULD allow
configuring whether or not periodic or event triggered mechanisms are configuring whether or not periodic or event triggered mechanisms are
used by the DODAG root to control DODAGVersionNumber change (which used by the DODAG root to control DODAGVersionNumber change (which
triggers a global repair as specified in Section 3.3.2. triggers a global repair as specified in Section 3.3.2.
15.2.6. Configuration of RPL Parameters related to DAO-based mechanisms 16.2.6. Configuration of RPL Parameters related to DAO-based mechanisms
DAO messages are optional and used in DODAGs that require downward DAO messages are optional and used in DODAGs that require downward
routing operation. This section deals with the set of parameters routing operation. This section deals with the set of parameters
related to DAO message and provides recommendations on their related to DAO message and provides recommendations on their
configuration. configuration.
An implementation SHOULD bound the time that the entry is allocated An implementation SHOULD bound the time that the entry is allocated
in the UNREACHABLE state. Upon the equivalent expiry of the related in the UNREACHABLE state. Upon the equivalent expiry of the related
timer (RemoveTimer), the entry SHOULD be suppressed. Thus a RPL timer (RemoveTimer), the entry SHOULD be suppressed. Thus a RPL
implementation MAY allow for the configuration of the RemoveTimer. implementation MAY allow for the configuration of the RemoveTimer.
skipping to change at page 85, line 50 skipping to change at page 96, line 12
state and No-Path should be scheduled to send to the node's DAO state and No-Path should be scheduled to send to the node's DAO
Parents. The maximum threshold MAY be configurable. Parents. The maximum threshold 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.
When scheduling to send a DAO, an implementation should equivalently When scheduling to send a DAO, an implementation should equivalently
start a timer (DelayDAO) to delay sending the DAO, thus helping to start a timer (DelayDAO) to delay sending the DAO, thus helping to
potentially aggregate DAOs. The DelayDAO timer MAY be configurable. potentially aggregate DAOs. The DelayDAO timer MAY be configurable.
15.2.7. Default Values 16.2.7. Default Values
15.3. Monitoring of RPL Operation
This document specifies default values for the following set of RPL
variables:
DEFAULT_PATH_CONTROL_SIZE
DEFAULT_DIO_INTERVAL_MIN
DEFAULT_DIO_INTERVAL_DOUBLINGS
DEFAULT_DIO_REDUNDANCY_CONSTANT
DEFAULT_MIN_HOP_RANK_INCREASE
It is recommended to specify default values in protocols; that being
said, as discussed in [RFC5706], default values may make less and
less sense. RPL is a routing protocol that is expected to be used in
a number of contexts where network characteristics such as the number
of nodes, link and nodes types are expected to vary significantly.
Thus, these default values are likely to change with the context and
as the technology will evolve. Indeed, LLNs' related technology
(e.g. hardware, link layers) have been evolving dramatically over the
past few years and such technologies are expected to change and
evolve considerably in the coming years.
The proposed values are not based on extensive best current practices
and are considered to be conservative.
16.3. Monitoring of RPL Operation
Several RPL parameters should be monitored to verify the correct Several RPL parameters should be monitored to verify the correct
operation of the routing protocol and the network itself. This operation of the routing protocol and the network itself. This
section lists the set of monitoring parameters of interest. section lists the set of monitoring parameters of interest.
15.3.1. Monitoring a DODAG parameters 16.3.1. Monitoring a DODAG parameters
A RPL implementation SHOULD provide information about the following A RPL implementation SHOULD provide information about the following
parameters: parameters:
o DODAG Version number [DIO message, in DIO base message] o DODAG Version number [DIO message, in DIO base message]
o Status of the G flag [DIO message, in DIO base message] o Status of the G flag [DIO message, in DIO base message]
o Status of the A flag [DIO message, in DIO base message] o Status of the MOP field [DIO message, in DIO base message]
o Value of the DTSN [DIO message, in DIO base message] o Value of the DTSN [DIO message, in DIO base message]
o Value of the rank [DIO message, in DIO base message] o Value of the rank [DIO message, in DIO base message]
o DAOSequence: Incremented at each unique DAO message, echoed in the o DAOSequence: Incremented at each unique DAO message, echoed in the
DAO-ACK message [DAO and DAO-ACK messages] DAO-ACK message [DAO and DAO-ACK messages]
o Route Information [DIO message, Route Information option] (list of o Route Information [DIO message, Route Information option] (list of
IPv6 prefixes per parent along with lifetime and preference] IPv6 prefixes per parent along with lifetime and preference]
skipping to change at page 87, line 5 skipping to change at page 97, line 35
Values that may be monitored only on the DODAG root Values that may be monitored only on the DODAG root
o Transit Information [DAO, Transit Information option]: A RPL o Transit Information [DAO, Transit Information option]: A RPL
implementation SHOULD allow configuring whether the set of implementation SHOULD allow configuring whether the set of
received Transit Information options should be displayed on the received Transit Information options should be displayed on the
DODAG root. In this case, the RPL database of received Transit DODAG root. In this case, the RPL database of received Transit
Information should also contain: the path-sequence, path control, Information should also contain: the path-sequence, path control,
path lifetime and parent address. path lifetime and parent address.
15.3.2. Monitoring a DODAG inconsistencies and loop detection 16.3.2. Monitoring a DODAG inconsistencies and loop detection
Detection of DODAG inconsistencies is particularly critical in RPL Detection of DODAG inconsistencies is particularly critical in RPL
networks. Thus it is recommended for a RPL implementation to provide networks. Thus it is recommended for a RPL implementation to provide
appropriate monitoring tools. A RPL implementation SHOULD provide a appropriate monitoring tools. A RPL implementation SHOULD provide a
counter reporting the number of a times the node has detected an counter reporting the number of a times the node has detected an
inconsistency with respect to a DODAG parent, e.g. if the DODAGID has inconsistency with respect to a DODAG parent, e.g. if the DODAGID has
changed. changed.
When possible more granular information about inconsistency detection When possible more granular information about inconsistency detection
should be provided. A RPL implementation MAY provide counters should be provided. A RPL implementation MAY provide counters
skipping to change at page 87, line 28 skipping to change at page 98, line 12
o Packets received with O bit set (to down) from a node with a o Packets received with O bit set (to down) from a node with a
higher rank higher rank
o Packets received with O bit reset (to up) from a node with a lower o Packets received with O bit reset (to up) from a node with a lower
rank rank
o Number of packets with the F bit set o Number of packets with the F bit set
o Number of packets with the R bit set o Number of packets with the R bit set
15.4. Monitoring of the RPL data structures 16.4. Monitoring of the RPL data structures
15.4.1. Candidate Neighbor Data Structure 16.4.1. Candidate Neighbor Data Structure
A node in the candidate neighbor list is a node discovered by the A node in the candidate neighbor list is a node discovered by the
some means and qualified to potentially become a parent (with high some means and qualified to potentially become a parent (with high
enough local confidence). A RPL implementation SHOULD provide a way enough local confidence). A RPL implementation SHOULD provide a way
to monitor the candidate neighbor list with some metric reflecting to monitor the candidate neighbor list with some metric reflecting
local confidence (the degree of stability of the neighbors) as local confidence (the degree of stability of the neighbors) as
measured by some metrics. measured by some metrics.
A RPL implementation MAY provide a counter reporting the number of A RPL implementation MAY provide a counter reporting the number of
times a candidate neighbor has been ignored, should the number of times a candidate neighbor has been ignored, should the number of
candidate neighbors exceeds the maximum authorized value. candidate neighbors exceeds the maximum authorized value.
15.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table 16.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table
For each DODAG, a RPL implementation is expected to keep track of the For each DODAG, a RPL implementation is expected to keep track of the
following DODAG table values: following DODAG table values:
o RPLInstanceID o RPLInstanceID
o DODAGID o DODAGID
o DODAGVersionNumber o DODAGVersionNumber
o Rank o Rank
o Objective Code Point o Objective Code Point
o A set of DODAG Parents o A set of DODAG Parents
o A set of prefixes offered upwards along the DODAG o A set of prefixes offered upwards along the DODAG
skipping to change at page 88, line 20 skipping to change at page 99, line 4
o A set of DODAG Parents o A set of DODAG Parents
o A set of prefixes offered upwards along the DODAG o A set of prefixes offered upwards along the DODAG
o Trickle timers used to govern the sending of DIO messages for the o Trickle timers used to govern the sending of DIO messages for the
DODAG DODAG
o List of DAO parents o List of DAO parents
o DTSN o DTSN
o Node status (router versus leaf) o Node status (router versus leaf)
A RPL implementation SHOULD allow for monitoring the set of A RPL implementation SHOULD allow for monitoring the set of
parameters listed above. parameters listed above.
15.4.3. Routing Table and DAO Routing Entries 16.4.3. Routing Table and DAO Routing Entries
A RPL implementation maintains several information elements related A RPL implementation maintains several information elements related
to the DODAG and the DAO entries (for storing nodes). In the case of to the DODAG and the DAO entries (for storing nodes). In the case of
a non storing node, a limited amount of information is maintained a non storing node, a limited amount of information is maintained
(the routing table is mostly reduced to a set of DODAG parents along (the routing table is mostly reduced to a set of DODAG parents along
with characteristics of the DODAG as mentioned above) whereas in the with characteristics of the DODAG as mentioned above) whereas in the
case of storing nodes, this information is augmented with routing case of storing nodes, this information is augmented with routing
entries. entries.
A RPL implementation SHOULD provide the ability to monitor the A RPL implementation SHOULD provide the ability to monitor the
skipping to change at page 89, line 4 skipping to change at page 99, line 34
o Next Hop Interface o Next Hop Interface
o Path metrics value for each DODAG parent o Path metrics value for each DODAG parent
A DAO Routing Table Entry conceptually contains the following A DAO Routing Table Entry conceptually contains the following
elements (for storing nodes only): elements (for storing nodes only):
o Advertising Neighbor Information o Advertising Neighbor Information
o IPv6 Address o IPv6 Address
o Interface ID to which DAO Parents has this entry been reported o Interface ID to which DAO Parents has this entry been reported
o Retry Counter o Retry Counter
o Logical equivalent of DAO Content: o Logical equivalent of DAO Content:
* DAO Sequence * DAO Sequence
* DAO Lifetime * DAO Lifetime
* DAO Path Control * DAO Path Control
o Destination Prefix (or Address or Mcast Group) o Destination Prefix (or Address or Mcast Group)
A RPL implementation SHOULD provide information about the state of A RPL implementation SHOULD provide information about the state of
each DAO Routing Table entry states. each DAO Routing Table entry states.
15.5. Fault Management 16.5. Fault Management
Fault management is a critical component used for troubleshooting, Fault management is a critical component used for troubleshooting,
verification of the correct mode of operation of the protocol, verification of the correct mode of operation of the protocol,
network design, and is also a key component of network performance network design, and is also a key component of network performance
monitoring. A RPL implementation SHOULD allow providing the monitoring. A RPL implementation SHOULD allow providing the
following information related to fault managements: following information related to fault managements:
o Memory overflow along with the cause (e.g. routing tables o Memory overflow along with the cause (e.g. routing tables
overflow, ...) overflow, ...)
skipping to change at page 90, line 5 skipping to change at page 100, line 33
o Number of times a global repair was triggered by the DODAG root o Number of times a global repair was triggered by the DODAG root
o Number of received malformed messages o Number of received malformed messages
o Number of seconds with packets to forward and no next hop (DODAG o Number of seconds with packets to forward and no next hop (DODAG
parent) parent)
o Number of seconds without next hop (DODAG parent) o Number of seconds without next hop (DODAG parent)
15.6. Policy o Number of times a node has joined a DODAG as a leaf because it
received a DIO with metric/constraint not understood and it was
configured to join as a leaf node in this case (see Section 16.6).
It is RECOMMENDED to report faults via at least error log messages.
Other protocols may be used to report such faults.
16.6. Policy
Policy rules can be used by a RPL implementation to determine whether Policy rules can be used by a RPL implementation to determine whether
or not the node is allowed to join a particular DODAG advertised by a or not the node is allowed to join a particular DODAG advertised by a
neighbor by means of DIO messages. neighbor by means of DIO messages.
This document specifies operation within a single DODAG. A DODAG is This document specifies operation within a single DODAG. A DODAG is
characterized by the following tuple (RPLInstanceID, DODAGID). characterized by the following tuple (RPLInstanceID, DODAGID).
Furthermore, as pointed out above, DIO messages are used to advertise Furthermore, as pointed out above, DIO messages are used to advertise
other DODAG characteristics such as the routing metrics and other DODAG characteristics such as the routing metrics and
constraints used to build to the DODAG and the Objective Function in constraints used to build to the DODAG and the Objective Function in
skipping to change at page 90, line 39 skipping to change at page 101, line 26
A RPL implementation MUST allow configuring these parameters and A RPL implementation MUST allow configuring these parameters and
SHOULD specify whether the node must simply ignore the DIO if the SHOULD specify whether the node must simply ignore the DIO if the
advertised DODAG is not compliant with the local policy or whether advertised DODAG is not compliant with the local policy or whether
the node should join as the leaf node if only the list of supported the node should join as the leaf node if only the list of supported
routing metrics and constraints, and the OF is not supported. routing metrics and constraints, and the OF is not supported.
A RPL implementation SHOULD allow configuring the set of acceptable A RPL implementation SHOULD allow configuring the set of acceptable
or preferred Objective Functions (OF) referenced by their Objective or preferred Objective Functions (OF) referenced by their Objective
Codepoints (OCPs) for a node to join a DODAG, and what action should Codepoints (OCPs) for a node to join a DODAG, and what action should
be taken if none of a node's candidate neighbors advertise one of the be taken if none of a node's candidate neighbors advertise one of the
configured allowable Objective Functions. configured allowable Objective Functions, or if the advertised
metrics/constraint is not understood/supported. Two actions can be
taken in this case:
o The node joins the DODAG as a leaf node as specified in
Section 7.5
o The node does not join the DODAG
A node in an LLN may learn routing information from different routing A node in an LLN may learn routing information from different routing
protocols including RPL. It is in this case desirable to control via protocols including RPL. It is in this case desirable to control via
administrative preference which route should be favored. An administrative preference which route should be favored. An
implementation SHOULD allow for specifying an administrative implementation SHOULD allow for specifying an administrative
preference for the routing protocol from which the route was learned. preference for the routing protocol from which the route was learned.
Internal Data Structures: some RPL implementations may limit the size Internal Data Structures: some RPL implementations may limit the size
of the candidate neighbor list in order to bound the memory usage, in of the candidate neighbor list in order to bound the memory usage, in
which case some otherwise viable candidate neighbors may not be which case some otherwise viable candidate neighbors may not be
considered and simply dropped from the candidate neighbor list. considered and simply dropped from the candidate neighbor list.
A RPL implementation MAY provide an indicator on the size of the A RPL implementation MAY provide an indicator on the size of the
candidate neighbor list. candidate neighbor list.
15.7. Liveness Detection and Monitoring 16.7. Liveness Detection and Monitoring
By contrast with several other routing protocols, RPL does not define By contrast with several other routing protocols, RPL does not define
any 'keep-alive' mechanisms to detect routing adjacency failure: this any 'keep-alive' mechanisms to detect routing adjacency failure: this
is in most cases, because such a mechanism may be too expensive in is in most cases, because such a mechanism may be too expensive in
terms of bandwidth and even more importantly energy (a battery terms of bandwidth and even more importantly energy (a battery
operated device could not afford to send periodic Keep alive). Still operated device could not afford to send periodic Keep alive). Still
RPL requires mechanisms to detect that a neighbor is no longer RPL requires mechanisms to detect that a neighbor is no longer
reachable: this can be performed by using mechanisms such as NUD reachable: this can be performed by using mechanisms such as NUD
(Neighbor Unreachability Detection) or even some form of Keep-alive (Neighbor Unreachability Detection) or even some form of Keep-alive
that are outside of this document. that are outside of this document.
15.8. Fault Isolation 16.8. Fault Isolation
It is RECOMMENDED to quarantine neighbors that start emitting It is RECOMMENDED to quarantine neighbors that start emitting
malformed messages at unacceptable rates. malformed messages at unacceptable rates.
15.9. Impact on Other Protocols 16.9. Impact on Other Protocols
RPL has very limited impact on other protocols. Where more than one RPL has very limited impact on other protocols. Where more than one
routing protocol is required on a router such as a LBR, it is routing protocol is required on a router such as a LBR, it is
expected for the device to support routing redistribution functions expected for the device to support routing redistribution functions
between the routing protocols to allow for reachability between the between the routing protocols to allow for reachability between the
two routing domains. Such redistribution SHOULD be governed by the two routing domains. Such redistribution SHOULD be governed by the
use of user configurable policy. use of user configurable policy.
With regards to the impact in terms of traffic on the network, RPL With regards to the impact in terms of traffic on the network, RPL
has been designed to limit the control traffic thanks to mechanisms has been designed to limit the control traffic thanks to mechanisms
such as Trickle timers (Section 7.3). Thus the impact of RPL on such as Trickle timers (Section 7.3). Thus the impact of RPL on
other protocols should be extremely limited. other protocols should be extremely limited.
15.10. Performance Management 16.10. Performance Management
Performance management is always an important aspect of a protocol Performance management is always an important aspect of a protocol
and RPL is not an exception. Several metrics of interest have been and RPL is not an exception. Several metrics of interest have been
specified by the IP Performance Monitoring (IPPM) Working Group: that specified by the IP Performance Monitoring (IPPM) Working Group: that
being said, they will be hardly applicable to LLN considering the being said, they will be hardly applicable to LLN considering the
cost of monitoring these metrics in terms of resources on the devices cost of monitoring these metrics in terms of resources on the devices
and required bandwidth. Still, RPL implementation MAY support some and required bandwidth. Still, RPL implementation MAY support some
of these, and other parameters of interest are listed below: of these, and other parameters of interest are listed below:
o Number of repairs and time to repair in seconds (average, o Number of repairs and time to repair in seconds (average,
skipping to change at page 92, line 11 skipping to change at page 104, line 5
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 itself in terms of
bandwidth and required memory bandwidth and required memory
o Number of RPL control messages sent and received o Number of RPL control messages sent and received
16. Security Considerations 17. Security Considerations
+----------------------------------------------------------------+
| |
| TBD |
| Under Construction |
| Deference given to Security Design Team |
| |
+----------------------------------------------------------------+
16.1. Overview 17.1. Overview
From a security perspective, RPL networks are no different from any From a security perspective, RPL networks are no different from any
other network. They are vulnerable to passive eavesdropping attacks other network. They are vulnerable to passive eavesdropping attacks
and potentially even active tampering when physical access to a wire and potentially even active tampering when physical access to a wire
is not required to participate in communications. The very nature of is not required to participate in communications. The very nature of
ad hoc networks and their cost objectives impose additional security ad hoc networks and their cost objectives impose additional security
constraints, which perhaps make these networks the most difficult constraints, which perhaps make these networks the most difficult
environments to secure. Devices are low-cost and have limited environments to secure. Devices are low-cost and have limited
capabilities in terms of computing power, available storage, and capabilities in terms of computing power, available storage, and
power drain; and it cannot always be assumed they have neither a power drain; and it cannot always be assumed they have neither a
skipping to change at page 94, line 16 skipping to change at page 106, line 5
public-key based techniques. With public-key based techniques (via public-key based techniques. With public-key based techniques (via
signatures), one corroborates evidence as to the unique originator of signatures), one corroborates evidence as to the unique originator of
transmitted information, whereas with symmetric-key based techniques transmitted information, whereas with symmetric-key based techniques
data authenticity is only provided relative to devices in a key- data authenticity is only provided relative to devices in a key-
sharing group. Thus, public-key based authentication may be useful sharing group. Thus, public-key based authentication may be useful
in scenarios that require a more fine-grained authentication than can in scenarios that require a more fine-grained authentication than can
be provided with symmetric-key based authentication techniques alone, be provided with symmetric-key based authentication techniques alone,
such as with group communications (broadcast, multicast), or in such as with group communications (broadcast, multicast), or in
scenarios that require non-repudiation. scenarios that require non-repudiation.
17. IANA Considerations 18. IANA Considerations
17.1. RPL Control Message 18.1. RPL Control Message
The RPL Control Message is an ICMP information message type that is The RPL Control Message is an ICMP information message type that is
to be used carry DODAG Information Objects, DODAG Information to be used carry DODAG Information Objects, DODAG Information
Solicitations, and Destination Advertisement Objects in support of Solicitations, and Destination Advertisement Objects in support of
RPL operation. RPL operation.
IANA has defined an ICMPv6 Type Number Registry. The suggested type IANA has defined an ICMPv6 Type Number Registry. The suggested type
value for the RPL Control Message is 155, to be confirmed by IANA. value for the RPL Control Message is 155, to be confirmed by IANA.
17.2. New Registry for RPL Control Codes 18.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 Consensus action. Each
code should be tracked with the following qualities: code should 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:
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| 0x00 | DODAG Information Solicitation | This | | 0x00 | DODAG Information Solicitation | This |
| | | document | | | | document |
| | | |
| 0x01 | DODAG Information Object | This | | 0x01 | DODAG Information Object | This |
| | | document | | | | document |
| | | |
| 0x02 | Destination Advertisement Object | This | | 0x02 | Destination Advertisement Object | This |
| | | document | | | | document |
| | | |
| 0x03 | Destination Advertisement Object | This | | 0x03 | Destination Advertisement Object | This |
| | Acknowledgment | document | | | Acknowledgment | document |
| | | |
| 0x80 | Secure DODAG Information Solicitation | This | | 0x80 | Secure DODAG Information Solicitation | This |
| | | document | | | | document |
| | | |
| 0x81 | Secure DODAG Information Object | This | | 0x81 | Secure DODAG Information Object | This |
| | | document | | | | document |
| 0x82 | Secure Destination Advertisement Object | This | | 0x82 | Secure Destination Advertisement Object | This |
| | | document | | | | document |
| | | |
| 0x83 | Secure Destination Advertisement Object | This | | 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document | | | Acknowledgment | document |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
RPL Control Codes RPL Control Codes
17.3. New Registry for the Mode of Operation (MOP) DIO Control Field 18.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 Mode of Operation
(MOP) DIO Control Field, which is contained in the DIO Base. (MOP) DIO Control Field, which is contained in the DIO Base.
New fields may be allocated only by an IETF Consensus action. Each New fields may be allocated only by an IETF Consensus action. Each
field should be tracked with the following qualities: field should be tracked with the following qualities:
o Mode of Operation o Mode of Operation
o Capability description o Capability description
o Defining RFC o Defining RFC
Two values are currently defined: Three values are currently defined:
+-----+-------------------------------+---------------+ +-----+----------------------------------------------+--------------+
| MOP | Description | Reference | | MOP | Description | Reference |
+-----+-------------------------------+---------------+ +-----+----------------------------------------------+--------------+
| 00 | Non-Storing mode of operation | This document | | 000 | No downward routes maintained by RPL | This |
| 01 | Storing mode of operation | This document | | | | document |
+-----+-------------------------------+---------------+ | | | |
| 001 | Non-Storing mode of operation | This |
| | | document |
| | | |
| 010 | Storing mode of operation with no multicast | This |
| | support | document |
| | | |
| 011 | Storing mode of operation with multicast | This |
| | support | document |
+-----+----------------------------------------------+--------------+
DIO Base Flags DIO Base Flags
17.4. RPL Control Message Option 18.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
+-------+-----------------------+---------------+
+-------+-------------------------+---------------+ | 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 | | | | |
| 3 | Routing Information | This Document | | 2 | DAG Metric Container | This Document |
| 4 | DAG Timer Configuration | This Document | | | | |
| 5 | RPL Target | This Document | | 3 | Routing Information | This Document |
| 6 | Transit Information | This Document | | | | |
| 7 | Solicited Information | This Document | | 4 | DODAG Configuration | This Document |
| 8 | Prefix Information | This Document | | | | |
+-------+-------------------------+---------------+ | 5 | RPL Target | This Document |
| | | |
| 6 | Transit Information | This Document |
| | | |
| 7 | Solicited Information | This Document |
| | | |
| 8 | Prefix Information | This Document |
+-------+-----------------------+---------------+
RPL Control Message Options RPL Control Message Options
17.5. Objective Code Point (OCP) Registry 18.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.
17.6. ICMPv6: Error in Source Routing Header 18.6. 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.
18. Acknowledgements 18.7. Link-Local Scope multicast address
The rules for assigning new IPv6 multicast addresses are defined in
[RFC3307]. This specification requires the allocation of a new
permanent multicast address with a link local scope for RPL routers,
with a suggested value of FF02::1:A, to be confirmed by IANA.
19. 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, Phoebus Chen, Mathilde Durvy, Manhar Goindi, Mukul Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Mischa Dohler,
Goyal, Anders Jagd, JeongGil (John) Ko, Quentin Lampin, Jerry Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi,
Martocci, Matteo Paris, Alexandru Petrescu, Joseph Reddy, and Don Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Quentin
Sturek. Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, Joseph
Reddy, Don Sturek, Joydeep 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.
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,
and Arsalan Tavakoli, which have provided useful design Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom
considerations to RPL. have provided useful design considerations to RPL.
19. Contributors RPL Security Design, found in Section 9, Section 17, and elsewhere
throughout the document, is primarily the contribution of the
Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
Levis, Kris Pister, and Rene Struik.
20. Contributors
RPL is the result of the contribution of the following members of the RPL is the result of the contribution of the following members of the
RPL Author Team, including the editors, and additional contributors RPL Author Team, including the editors, and additional contributors
as listed below: as listed below:
JP Vasseur JP Vasseur
Cisco Systems, Inc Cisco Systems, Inc
11, Rue Camille Desmoulins 11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782 Issy Les Moulineaux, 92782
France France
skipping to change at page 98, line 16 skipping to change at page 112, line 4
Phone: +1 617 951 1225 Phone: +1 617 951 1225
Email: kelsey@ember.com Email: kelsey@ember.com
Jonathan W. Hui Jonathan W. Hui
Arch Rock Corporation Arch Rock Corporation
501 2nd St. Ste. 410 501 2nd St. Ste. 410
San Francisco, CA 94107 San Francisco, CA 94107
USA USA
Email: jhui@archrock.com Email: jhui@archrock.com
Kris Pister Kris Pister
Dust Networks Dust Networks
30695 Huntwood Ave. 30695 Huntwood Ave.
Hayward, 94544 Hayward, 94544
USA USA
Email: kpister@dustnetworks.com Email: kpister@dustnetworks.com
Anders Brandt Anders Brandt
Sigma Designs Sigma Designs
Emdrupvej 26A, 1. Emdrupvej 26A, 1.
Copenhagen, DK-2100 Copenhagen, DK-2100
Denmark Denmark
Email: abr@sdesigns.dk Email: abr@sdesigns.dk
R. Struik
Email: rstruik.ext@gmail.com
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
20. References 21. References
20.1. Normative References
21.1. Normative References
[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.
20.2. Informative References 21.2. Informative References
[AppliedCryptography] [AppliedCryptography]
Menzes, AJ., van Oorschot, PC., and SA. Vanstone, Menzes, AJ., van Oorschot, PC., and SA. Vanstone,
"Handbook of Applied Cryptography", CRC Press , 1997. "Handbook of Applied Cryptography", CRC Press , 1997.
[CCMStar] IEEE, "IEEE Std. 802.15.4-2006, IEEE Standard for [CCMStar] IEEE, "IEEE Std. 802.15.4-2006, IEEE Standard for
Information Technology - Telecommunications and Information Technology - Telecommunications and
Information Exchange between Systems - Local and Information Exchange between Systems - Local and
Metropolitan Area Networks - Specific requirements Part Metropolitan Area Networks - Specific requirements Part
15.4: Wireless Medium Access Control (MAC) and Physical 15.4: Wireless Medium Access Control (MAC) and Physical
skipping to change at page 99, line 33 skipping to change at page 113, line 36
[I-D.hui-6man-rpl-option] [I-D.hui-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-hui-6man-rpl-option-01 (work in progress), draft-hui-6man-rpl-option-01 (work in progress),
June 2010. June 2010.
[I-D.hui-6man-rpl-routing-header] [I-D.hui-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-hui-6man-rpl-routing-header-01 (work in progress), draft-hui-6man-rpl-routing-header-02 (work in progress),
June 2010. June 2010.
[I-D.ietf-manet-nhdp] [I-D.ietf-manet-nhdp]
Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-12 (work in progress), March 2010. draft-ietf-manet-nhdp-12 (work in progress), March 2010.
[I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-09
(work in progress), January 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-02 (work in progress), June 2010. draft-ietf-roll-of0-02 (work in progress), June 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing
Metrics used for Path Calculation in Low Power and Lossy Metrics used for Path Calculation in Low Power and Lossy
Networks", draft-ietf-roll-routing-metrics-07 (work in Networks", draft-ietf-roll-routing-metrics-07 (work in
progress), June 2010. progress), June 2010.
skipping to change at page 100, line 39 skipping to change at page 114, line 35
August 1996. August 1996.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003. Management Workshop", RFC 3535, May 2003.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, September 2003.
skipping to change at page 101, line 51 skipping to change at page 115, line 49
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, November 2009. RFC 5706, November 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
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.
[X9.63-2001] [X9.63-2001]
"ANSI X9.63-2001, Public Key Cryptography for the "ANSI X9.63-2001, Public Key Cryptography for the
Financial Services Industry - Key Agreement and Key Financial Services Industry - Key Agreement and Key
Transport Using Elliptic Curve Cryptography", 2001. Transport Using Elliptic Curve Cryptography", 2001.
[X9.92] "ANSI X9.92, Public Key Cryptography for the Financial [X9.92] "ANSI X9.92, Public Key Cryptography for the Financial
Services Industry - Digital Signature Algorithms Giving Services Industry - Digital Signature Algorithms Giving
Partial Message Recovery - Part 1: Elliptic Curve Pintsov- Partial Message Recovery - Part 1: Elliptic Curve Pintsov-
Vanstone Signatures (ECPVS)", 2009. Vanstone Signatures (ECPVS)", 2009.
Appendix A. Outstanding Issues
This section enumerates some outstanding issues that are to be
addressed in future revisions of the RPL specification.
A.1. Additional Support for P2P Routing
In some situations the baseline mechanism to support arbitrary P2P
traffic, by flowing upwards along the DODAG until a common ancestor
is reached and then flowing down, may not be suitable for all
application scenarios. A related scenario may occur when the down
paths setup along the DODAG by the destination advertisement
mechanism are not the most desirable downward paths for the specific
application scenario (in part because the DODAG links may not be
symmetric). It may be desired to support within RPL the discovery
and installation of more direct routes 'across' the DAG. Such
mechanisms need to be investigated.
A.2. Address / Header Compression
In order to minimize overhead within the LLN it is desirable to
perform some sort of address and/or header compression, perhaps via
labels, addresses aggregation, or some other means. This is still
under investigation.
A.3. Managing Multiple Instances
A network may run multiple instances of RPL concurrently. Such a
network will require methods for assigning and otherwise managing
RPLInstanceIDs. This will likely be addressed in a separate
document.
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
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
 End of changes. 170 change blocks. 
547 lines changed or deleted 858 lines changed or added

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