< draft-ietf-roll-rpl-15.txt   draft-ietf-roll-rpl-16.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: May 10, 2011 Cisco Systems Expires: June 11, 2011 Cisco Systems
A. Brandt A. Brandt
Sigma Designs Sigma Designs
T. Clausen T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
J. Hui J. Hui
Arch Rock Corporation Arch Rock Corporation
R. Kelsey R. Kelsey
Ember Corporation Ember Corporation
P. Levis P. Levis
Stanford University Stanford University
K. Pister K. Pister
Dust Networks Dust Networks
R. Struik R. Struik
JP. Vasseur JP. Vasseur
Cisco Systems Cisco Systems
November 6, 2010 December 8, 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-15 draft-ietf-roll-rpl-16
Abstract Abstract
Low power and Lossy Networks (LLNs) are a class of network in which Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by energy (battery power). Their interconnects are characterized by
high loss rates, low data rates, and instability. LLNs are comprised high loss rates, low data rates, and instability. LLNs are comprised
of anything from a few dozen and up to thousands of routers. of anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices Supported traffic flows include point-to-point (between devices
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 10, 2011. This Internet-Draft will expire on June 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Design Principles . . . . . . . . . . . . . . . . . . . 7 1.1. Design Principles . . . . . . . . . . . . . . . . . . . 8
1.2. Expectations of Link Layer Type . . . . . . . . . . . . 9 1.2. Expectations of Link Layer Type . . . . . . . . . . . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 13 3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 14
3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 13 3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 14
3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 14 3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 15
3.2. Upward Routes and DODAG Construction . . . . . . . . . . 16 3.2. Upward Routes and DODAG Construction . . . . . . . . . . 17
3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 16 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 17
3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 16 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 17
3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 17 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 17 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 18
3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 17 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 18
3.2.6. Administrative Preference . . . . . . . . . . . . . . 18 3.2.6. Administrative Preference . . . . . . . . . . . . . . 19
3.2.7. Datapath Validation and Loop Detection . . . . . . . 18 3.2.7. Datapath Validation and Loop Detection . . . . . . . 19
3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 18 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 19
3.3. Downward Routes and Destination Advertisement . . . . . 19 3.3. Downward Routes and Destination Advertisement . . . . . 20
3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 19 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 20
3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 19 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 20
3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 20 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 21
3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 21 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 22
3.6. Routing Metrics and Constraints Used By RPL . . . . . . 22 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 23
3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 23 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 24
3.7.1. Greediness and Instability . . . . . . . . . . . . . 23 3.7.1. Greediness and Instability . . . . . . . . . . . . . 24
3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 25 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 26
3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 26 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 27
4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 27 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 28
4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 27 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 28
4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 27 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 28
4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 27 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 28
5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 28 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 28 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 29
6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 30 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 31
6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 32 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 33
6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 37 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 38
6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 37 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 38
6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 37 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 38
6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 37 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 38
6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 37 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 38
6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 38 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 39
6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 40 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 41
6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 40 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 41
6.4. Destination Advertisement Object (DAO) . . . . . . . . . 40 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 41
6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 40 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 41
6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 42 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 43
6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 42 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 43
6.5. Destination Advertisement Object Acknowledgement 6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 42 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 43
6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 42 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 43
6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 44 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 45
6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 44 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 45
6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 44 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 45
6.6.1. Format of the CC Base Object . . . . . . . . . . . . 44 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 45
6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 45 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 46
6.7. RPL Control Message Options . . . . . . . . . . . . . . 45 6.7. RPL Control Message Options . . . . . . . . . . . . . . 46
6.7.1. RPL Control Message Option Generic Format . . . . . . 45 6.7.1. RPL Control Message Option Generic Format . . . . . . 46
6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 46 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 47
6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 47 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 48
6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 47 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 48
6.7.5. Route Information . . . . . . . . . . . . . . . . . . 48 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 49
6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 50 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 51
6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 52 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 53
6.7.8. Transit Information . . . . . . . . . . . . . . . . . 53 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 54
6.7.9. Solicited Information . . . . . . . . . . . . . . . . 56 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 57
6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 58 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 59
6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 60 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 61
7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 62 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 62 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 63
7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 63 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 64
8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 65 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 65 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 66
8.2. Upward Route Discovery and Maintenance . . . . . . . . . 66 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 67
8.2.1. Neighbors and Parents within a DODAG Version . . . . 66 8.2.1. Neighbors and Parents within a DODAG Version . . . . 67
8.2.2. Neighbors and Parents across DODAG Versions . . . . . 67 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 68
8.2.3. DIO Message Communication . . . . . . . . . . . . . . 72 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 73
8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 72 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 73
8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 73 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 74
8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 73 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 74
8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 74 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 75
8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 75 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 76
9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 76 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 77
9.1. Destination Advertisement Parents . . . . . . . . . . . 76 9.1. Destination Advertisement Parents . . . . . . . . . . . 77
9.2. Downward Route Discovery and Maintenance . . . . . . . . 77 9.2. Downward Route Discovery and Maintenance . . . . . . . . 78
9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 78 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 79
9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 78 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 79
9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 79 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 80
9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 79 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 80
9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 81 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 82
9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 81 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 83
9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 82 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 84
9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 83 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 85
9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 84 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 85
9.9.1. Path Control Example . . . . . . . . . . . . . . . . 85 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 87
9.10. Multicast Destination Advertisement Messages . . . . . . 87 9.10. Multicast Destination Advertisement Messages . . . . . . 89
10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 88 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 90
10.1. Security Overview . . . . . . . . . . . . . . . . . . . 88 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90
10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 89 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91
10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 90 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92
10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 90 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92
10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 91 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93
10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 92 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94
10.7. Reception of Incoming Packets . . . . . . . . . . . . . 93 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95
10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 94 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 96
10.8. Coverage of Integrity and Confidentiality . . . . . . . 95 10.8. Coverage of Integrity and Confidentiality . . . . . . . 97
10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 95 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 97
10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 95 10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 97
10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 96 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 98
11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 98 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 100
11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 98 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 100
11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 99 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 101
11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 100 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 102
11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 100 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 102
12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 103 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 105
13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 105 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 107
14. Guidelines for Objective Functions . . . . . . . . . . . . . 106 14. Guidelines for Objective Functions . . . . . . . . . . . . . 108
14.1. Objective Function Behavior . . . . . . . . . . . . . . 106 14.1. Objective Function Behavior . . . . . . . . . . . . . . 108
15. Suggestions for Interoperation with Neighbor Discovery . . . 108 15. Suggestions for Interoperation with Neighbor Discovery . . . 110
16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 109 16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 111
17. Manageability Considerations . . . . . . . . . . . . . . . . 111 17. Manageability Considerations . . . . . . . . . . . . . . . . 113
17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 111 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 113
17.2. Configuration Management . . . . . . . . . . . . . . . . 112 17.2. Configuration Management . . . . . . . . . . . . . . . . 114
17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 112 17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 114
17.2.2. DIO and DAO Base Message and Options Configuration . 113 17.2.2. DIO and DAO Base Message and Options Configuration . 115
17.2.3. Protocol Parameters to be configured on every 17.2.3. Protocol Parameters to be configured on every
router in the LLN . . . . . . . . . . . . . . . . . . 113 router in the LLN . . . . . . . . . . . . . . . . . . 115
17.2.4. Protocol Parameters to be configured on every 17.2.4. Protocol Parameters to be configured on every
non-DODAG-root router in the LLN . . . . . . . . . . 114 non-DODAG-root router in the LLN . . . . . . . . . . 116
17.2.5. Parameters to be configured on the DODAG root . . . . 114 17.2.5. Parameters to be configured on the DODAG root . . . . 116
17.2.6. Configuration of RPL Parameters related to 17.2.6. Configuration of RPL Parameters related to
DAO-based mechanisms . . . . . . . . . . . . . . . . 115 DAO-based mechanisms . . . . . . . . . . . . . . . . 117
17.2.7. Configuration of RPL Parameters related to 17.2.7. Configuration of RPL Parameters related to
Security mechanisms . . . . . . . . . . . . . . . . . 116 Security mechanisms . . . . . . . . . . . . . . . . . 118
17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 117 17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 119
17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 117 17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 119
17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 117 17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 119
17.3.2. Monitoring a DODAG inconsistencies and loop 17.3.2. Monitoring a DODAG inconsistencies and loop
detection . . . . . . . . . . . . . . . . . . . . . . 118 detection . . . . . . . . . . . . . . . . . . . . . . 120
17.4. Monitoring of the RPL data structures . . . . . . . . . 119 17.4. Monitoring of the RPL data structures . . . . . . . . . 121
17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 119 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 121
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) 17.4.2. Destination Oriented Directed Acyclic Graph (DAG)
Table . . . . . . . . . . . . . . . . . . . . . . . . 119 Table . . . . . . . . . . . . . . . . . . . . . . . . 121
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 120 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 122
17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 121 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 123
17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 121 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 123
17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 122 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 124
17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 123 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 125
17.9. Performance Management . . . . . . . . . . . . . . . . . 123 17.9. Performance Management . . . . . . . . . . . . . . . . . 125
17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 123 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 125
18. Security Considerations . . . . . . . . . . . . . . . . . . . 124 18. Security Considerations . . . . . . . . . . . . . . . . . . . 126
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 124 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 126
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128
19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 126 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 128
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 126 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 128
19.3. New Registry for the Mode of Operation (MOP) . . . . . . 127 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 129
19.4. RPL Control Message Option . . . . . . . . . . . . . . . 128 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 130
19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 128 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 130
19.6. New Registry for the Security Section Algorithm . . . . 129 19.6. New Registry for the Security Section Algorithm . . . . 131
19.7. New Registry for the Security Section Flags . . . . . . 129 19.7. New Registry for the Security Section Flags . . . . . . 131
19.8. New Registry for Per-KIM Security Levels . . . . . . . . 130 19.8. New Registry for Per-KIM Security Levels . . . . . . . . 132
19.9. New Registry for the DIS (DODAG Informational 19.9. New Registry for the DIS (DODAG Informational
Solicitation) Flags . . . . . . . . . . . . . . . . . . 131 Solicitation) Flags . . . . . . . . . . . . . . . . . . 133
19.10. New Registry for the DODAG Information Object (DIO) 19.10. New Registry for the DODAG Information Object (DIO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 134
19.11. New Registry for the Destination Advertisement Object 19.11. New Registry for the Destination Advertisement Object
(DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 132 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 134
19.12. New Registry for the Destination Advertisement Object 19.12. New Registry for the Destination Advertisement Object
(DAO) Acknowledgement Flags . . . . . . . . . . . . . . 133 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 135
19.13. New Registry for the Consistency Check (CC) Flags . . . 133 19.13. New Registry for the Consistency Check (CC) Flags . . . 135
19.14. New Registry for the DODAG Configuration Option Flags . 134 19.14. New Registry for the DODAG Configuration Option Flags . 136
19.15. New Registry for the RPL Target Option Flags . . . . . . 134 19.15. New Registry for the RPL Target Option Flags . . . . . . 136
19.16. New Registry for the Transit Information Option Flags . 134 19.16. New Registry for the Transit Information Option Flags . 137
19.17. New Registry for the Solicited Information Option 19.17. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 135 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 137
19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 136 19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 138
19.19. Link-Local Scope multicast address . . . . . . . . . . . 136 19.19. Link-Local Scope multicast address . . . . . . . . . . . 138
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 137 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 138 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 140
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 139 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 141
22.1. Normative References . . . . . . . . . . . . . . . . . . 139 22.1. Normative References . . . . . . . . . . . . . . . . . . 141
22.2. Informative References . . . . . . . . . . . . . . . . . 140 22.2. Informative References . . . . . . . . . . . . . . . . . 142
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 Appendix A. Example Operation . . . . . . . . . . . . . . . . . 145
A.1. Example with External Prefixes . . . . . . . . . . . . . 145
A.2. Example Operation in Storing Mode With Node-owned
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 147
A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 148
A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 148
A.2.3. Routing Information Base . . . . . . . . . . . . . . 149
A.3. Example Operation in Storing Mode With Subnet-wide
Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 149
A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 150
A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 151
A.3.3. Routing Information Base . . . . . . . . . . . . . . 151
A.4. Example Operation in Non-Storing Mode With Node-owned
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 152
A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 153
A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 153
A.4.3. Routing Information Base . . . . . . . . . . . . . . 154
A.5. Example Operation in Non-Storing Mode With
Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 154
A.5.1. DIO messages and PIO . . . . . . . . . . . . . . . . 155
A.5.2. DAO messages . . . . . . . . . . . . . . . . . . . . 156
A.5.3. Routing Information Base . . . . . . . . . . . . . . 156
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158
1. Introduction 1. Introduction
Low power and Lossy Networks (LLNs) consist of largely of constrained Low power and Lossy Networks (LLNs) consist of largely of constrained
nodes (with limited processing power, memory, and sometimes energy nodes (with limited processing power, memory, and sometimes energy
when they are battery operated or energy scavenging). These routers when they are battery operated or energy scavenging). These routers
are interconnected by lossy links, typically supporting only low data are interconnected by lossy links, typically supporting only low data
rates, that are usually unstable with relatively low packet delivery rates, that are usually unstable with relatively low packet delivery
rates. Another characteristic of such networks is that the traffic rates. Another characteristic of such networks is that the traffic
patterns are not simply point-to-point, but in many cases point-to- patterns are not simply point-to-point, but in many cases point-to-
skipping to change at page 8, line 30 skipping to change at page 9, line 30
Packet Information to support additional features. Packet Information to support additional features.
RPL provides a mechanism to disseminate information over the RPL provides a mechanism to disseminate information over the
dynamically-formed network topology. The dissemination enables dynamically-formed network topology. The dissemination enables
minimal configuration in the nodes, allowing nodes to operate mostly minimal configuration in the nodes, allowing nodes to operate mostly
autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to
optimize the dissemination as described in Section 8.3. optimize the dissemination as described in Section 8.3.
In some applications, RPL assembles topologies of routers that own In some applications, RPL assembles topologies of routers that own
independent prefixes. Those prefixes may or may not be aggregatable independent prefixes. Those prefixes may or may not be aggregatable
depending on the origin of the routers. RPL also introduces the depending on the origin of the routers. A prefix that is owned by a
capability to bind a subnet together and route within that subnet. router is advertised as on-link.
In that case, the source of the dissemination is authoritative for
the information about the subnet that RPL disseminates.
When operating within a subnet, RPL may in particular disseminate RPL also introduces the capability to bind a subnet together with a
Neighbor Discovery information such as the [RFC4861] Prefix common prefix and to route within that subnet. A source can inject
Information Option (PIO) and the [RFC4191] Route Information Option information about the subnet to be disseminated by RPL, and that
(RIO). ND information that is disseminated by RPL conserves its source is authoritative for that subnet. Because many LLN links have
original semantics. It is not to be confused with routing non-transitive properties, a common prefix that RPL disseminates over
advertisements and it is not to be directly redistributed in another the subnet must not be advertised as on-link.
routing protocol. However, a RPL router may trivially reform the
original ND option, use the option as if received in an ND Router RPL may in particular disseminate IPv6 Neighbor Discovery (ND)
Advertisements and expose it in its own RAs. information such as the [RFC4861] Prefix Information Option (PIO) and
the [RFC4191] Route Information Option (RIO). ND information that is
disseminated by RPL conserves all its original semantics for router
to host, with limited extensions for router to router, though it is
not to be confused with routing advertisements and it is never to be
directly redistributed in another routing protocol. A RPL node often
combines host and router behaviors. As a host, it will process the
options as specified in [RFC4191], [RFC4861], [RFC4862] and
[RFC3775]. As a router, the RPL node may advertise the information
from the options as required for the specific link, for instance in a
ND RA message, though the exact operation is out of scope.
A set of companion documents to this specification will provide A set of companion documents to this specification will provide
further guidance in the form of applicability statements specifying a further guidance in the form of applicability statements specifying a
set of operating points appropriate to the Building Automation, Home set of operating points appropriate to the Building Automation, Home
Automation, Industrial, and Urban application scenarios. Automation, Industrial, and Urban application scenarios.
1.2. Expectations of Link Layer Type 1.2. Expectations of Link Layer Type
In compliance with the layered architecture of IP, RPL does not rely In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link layer technology. RPL on any particular features of a specific link layer technology. RPL
skipping to change at page 17, line 29 skipping to change at page 18, line 29
In the second, called "pre-installed," nodes joining a RPL Instance In the second, called "pre-installed," nodes joining a RPL Instance
have pre-installed keys that enable them to process and generate have pre-installed keys that enable them to process and generate
secured RPL messages. secured RPL messages.
The third mode is called "authenticated." In authenticated mode, The third mode is called "authenticated." In authenticated mode,
nodes have pre-installed keys as in pre-installed mode, but the pre- nodes have pre-installed keys as in pre-installed mode, but the pre-
installed key may only be used to join a RPL Instance as a leaf. installed key may only be used to join a RPL Instance as a leaf.
Joining an authenticated RPL Instance as a router requires obtaining Joining an authenticated RPL Instance as a router requires obtaining
a key from an authentication authority. The process by which this a key from an authentication authority. The process by which this
key is obtained is out of scope for this specification (to be defined key is obtained is out of scope for this specification. Note that
in future companion specifications). this specification alone does not provide sufficient detail for a RPL
implementation to securely operate in authenticated mode. For a RPL
implementation to operate securely in authenticated mode it is
necessary for a future companion specification to detail the
mechanisms by which a node obtains/requests the authentication
material (e.g. key, certificate), and to determine from where that
material should be obtained. See also Section 10.3.
3.2.4. Grounded and Floating DODAGs 3.2.4. Grounded and Floating DODAGs
DODAGs can be grounded or floating: the DODAG root advertises which DODAGs can be grounded or floating: the DODAG root advertises which
is the case. A grounded DODAG offers connectivity to hosts that are is the case. A grounded DODAG offers connectivity to hosts that are
required for satisfying the application-defined goal. A floating required for satisfying the application-defined goal. A floating
DODAG is not expected to satisfy the goal and in most cases only DODAG is not expected to satisfy the goal and in most cases only
provides routes to nodes within the DODAG. Floating DODAGs may be provides routes to nodes within the DODAG. Floating DODAGs may be
used, for example, to preserve inner connectivity during repair. used, for example, to preserve inner connectivity during repair.
skipping to change at page 22, line 52 skipping to change at page 24, line 6
even a composite metric, that will satisfy all use cases. even a composite metric, that will satisfy all use cases.
In addition, RPL supports constrained-based routing where constraints In addition, RPL supports constrained-based routing where constraints
may be applied to both link and nodes. If a link or a node does not may be applied to both link and nodes. If a link or a node does not
satisfy a required constraint, it is 'pruned' from the candidate satisfy a required constraint, it is 'pruned' from the candidate
neighbor set, thus leading to a constrained shortest path. neighbor set, thus leading to a constrained shortest path.
An Objective Function specifies the objectives used to compute the An Objective Function specifies the objectives used to compute the
(constrained) path. Furthermore, nodes are configured to support a (constrained) path. Furthermore, nodes are configured to support a
set of metrics and constraints, and select their parents in the DODAG set of metrics and constraints, and select their parents in the DODAG
according the the metrics and constraints advertised in the DIO according to the metrics and constraints advertised in the DIO
messages. Upstream and Downstream metrics may be merged or messages. Upstream and Downstream metrics may be merged or
advertised separately depending on the OF and the metrics. When they advertised separately depending on the OF and the metrics. When they
are advertised separately, it may happen that the set of DIO parents are advertised separately, it may happen that the set of DIO parents
is different from the set of DAO parents (a DAO parent is a node to is different from the set of DAO parents (a DAO parent is a node to
which unicast DAO messages are sent). Yet, all are DODAG parents which unicast DAO messages are sent). Yet, all are DODAG parents
with regards to the rules for Rank computation. with regards to the rules for Rank computation.
The Objective Function is decoupled from the routing metrics and The Objective Function is decoupled from the routing metrics and
constraints used by RPL. Indeed, whereas the OF dictates rules such constraints used by RPL. Indeed, whereas the OF dictates rules such
as DODAG parents selection, load balancing and so on, the set of as DODAG parents selection, load balancing and so on, the set of
skipping to change at page 23, line 30 skipping to change at page 24, line 33
Example 1: Shortest path: path offering the shortest end-to-end Example 1: Shortest path: path offering the shortest end-to-end
delay. delay.
Example 2: Shortest Constrained path: the path that does not traverse Example 2: Shortest Constrained path: the path that does not traverse
any battery-operated node and that optimizes the path any battery-operated node and that optimizes the path
reliability. reliability.
3.7. Loop Avoidance 3.7. Loop Avoidance
RPL avoids creating loops when undergoing topology changes and RPL tries to avoid creating loops when undergoing topology changes
includes rank-based datapath validation mechanisms for detecting and includes rank-based datapath validation mechanisms for detecting
loops when they do occur (see Section 11 for more details). In loops when they do occur (see Section 11 for more details). In
practice, this means that RPL guarantees neither loop free path practice, this means that RPL guarantees neither loop free path
selection nor tight delay convergence times, but can detect and selection nor tight delay convergence times, but can detect and
repair a loop as soon as it is used. RPL uses this loop detection to repair a loop as soon as it is used. RPL uses this loop detection to
ensure that packets make forward progress within the DODAG Version ensure that packets make forward progress within the DODAG Version
and trigger repairs when necessary. and trigger repairs when necessary.
3.7.1. Greediness and Instability 3.7.1. Greediness and Instability
A node is greedy if it attempts to move deeper (increase Rank) in the A node is greedy if it attempts to move deeper (increase Rank) in the
skipping to change at page 33, line 6 skipping to change at page 34, line 6
|T| Reserved | Algorithm |KIM|Resvd| LVL | Flags | |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter | | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Key Identifier . . Key Identifier .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Section Figure 8: Security Section
Message authentication codes (MACs) and signatures cover the entire Message authentication codes (MACs) and signatures provide
unsecured ICMPv6 RPL message, yielding a secured ICMPv6 RPL message authentication over the entire unsecured ICMPv6 RPL control message,
with the inclusion of the cryptographic fields (MAC, signature, including the Security section with all fields defined, but with the
etc.). Encryption starts after the Security section. Use of the ICMPv6 checksum temporarily set to zero. Encryption provides
Security section is further detailed in Section 18 and Section 10. confidentiality of the secured RPL ICMPv6 message starting at the
first byte after the Security section and continuing to the last byte
of the packet. The security transformation yields a secured ICMPv6
RPL message with the inclusion of the cryptographic fields (MAC,
signature, etc.). In other words, the security transformation itself
(e.g. the Signature and/or Algorithm in use) will detail how to
incorporate the cryptographic fields into the secured packet. The
Security section itself does not explicitly carry those cryptographic
fields. Use of the Security section is further detailed in
Section 18 and Section 10.
Counter is Time (T): If the Counter is Time flag is set then the Counter is Time (T): If the Counter is Time flag is set then the
Counter field is a timestamp. If the flag is cleared then the Counter field is a timestamp. If the flag is cleared then the
Counter is an incrementing counter. Section 10.5 describes the Counter is an incrementing counter. Section 10.5 describes the
details of the 'T' flag and Counter field. details of the 'T' flag and Counter field.
Reserved: 7-bit unused field. The field MUST be initialized to zero Reserved: 7-bit unused field. The field MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
Security Algorithm (Algorithm): The Security Algorithm field Security Algorithm (Algorithm): The Security Algorithm field
skipping to change at page 35, line 39 skipping to change at page 36, line 39
+-------+--------------------+------+ +-------+--------------------+------+
+---------------------+ +---------------------+
| KIM=3 | | KIM=3 |
+-------+---------------+-----+ +-------+---------------+-----+
| LVL | Attributes | Sig | | LVL | Attributes | Sig |
| | | Len | | | | Len |
+-------+---------------+-----+ +-------+---------------+-----+
| 0 | Sign-3072 | 384 | | 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 | | 1 | ENC-Sign-3072 | 384 |
| 2-7 | Unassigned | N/A | | 2 | Sign-2048 | 256 |
| 3 | ENC-Sign-2048 | 256 |
| 4-7 | Unassigned | N/A |
+-------+---------------+-----+ +-------+---------------+-----+
Figure 11: Security Level (LVL) Encoding Figure 11: Security Level (LVL) Encoding
The MAC attribute indicates that the message has a Message The MAC attribute indicates that the message has a Message
Authentication Code of the specified length. The ENC attribute Authentication Code of the specified length. The ENC attribute
indicates that the message is encrypted. The Sign attribute indicates that the message is encrypted. The Sign attribute
indicates that the message has a signature of the specified indicates that the message has a signature of the specified
length. length.
skipping to change at page 55, line 29 skipping to change at page 56, line 29
initialized to zero by the sender and MUST be ignored by the initialized to zero by the sender and MUST be ignored by the
receiver. receiver.
Path Control: 8-bit bitfield. The Path Control field limits the Path Control: 8-bit bitfield. The Path Control field limits the
number of DAO-Parents to which a DAO message advertising number of DAO-Parents to which a DAO message advertising
connectivity to a specific destination may be sent, as well as connectivity to a specific destination may be sent, as well as
providing some indication of relative preference. The limit providing some indication of relative preference. The limit
provides some bound on overall DAO message fan-out in the LLN. provides some bound on overall DAO message fan-out in the LLN.
The assignment and ordering of the bits in the path control The assignment and ordering of the bits in the path control
also serves to communicate preference. Not all of these bits also serves to communicate preference. Not all of these bits
may be enabled as according the the PCS in the DODAG may be enabled as according to the PCS in the DODAG
Configuration. The Path Control field is divided into four Configuration. The Path Control field is divided into four
subfields which contain two bits each: PC1, PC2, PC3, and PC4, subfields which contain two bits each: PC1, PC2, PC3, and PC4,
as illustrated in Figure 27. The subfields are ordered by as illustrated in Figure 27. The subfields are ordered by
preference, with PC1 being the most preferred and PC4 being the preference, with PC1 being the most preferred and PC4 being the
least preferred. Within a subfield there is no order of least preferred. Within a subfield there is no order of
preference. By grouping the parents (as in ECMP) and ordering preference. By grouping the parents (as in ECMP) and ordering
them, the parents may be associated with specific bits in the them, the parents may be associated with specific bits in the
Path Control field in a way that communicates preference. Path Control field in a way that communicates preference.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 58, line 15 skipping to change at page 59, line 15
DODAGID: 128-bit unsigned integer containing the DODAGID that is DODAGID: 128-bit unsigned integer containing the DODAGID that is
being solicited when valid. being solicited when valid.
Unassigned bits of the Solicited Information option are reserved. Unassigned bits of the Solicited Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on They MUST be set to zero on transmission and MUST be ignored on
reception. reception.
6.7.10. Prefix Information 6.7.10. Prefix Information
The Prefix Information option MAY be present in DIO messages, and The Prefix Information option MAY be present in DIO messages, and
carries the equivalent information for the purpose of configuring RPL carries the information that is specified for the IPv6 ND Prefix
routers as the IPv6 ND Prefix Information option defined in Information Option in [RFC4861], [RFC4862] and [RFC3775] for use by
[RFC4861]. In particular, a RPL router may use this option to RPL nodes and IPv6 hosts. In particular, a RPL node may use this
autoconfigure an address from a parent prefix as specified in option for the purpose of State-Less Address Auto-Configuration
[RFC4862] and advertise its own address as specified in [RFC3775]. (SLAAC) from a prefix advertised by a parent as specified in
The root of a DODAG is authoritative for setting that information and [RFC4862], and advertise its own address as specified in [RFC3775].
the information is unchanged as propagated down the DODAG but for the The root of a DODAG is authoritative for setting that information.
suffix of the address of the parent that can be included in the The information is propagated down the DODAG unchanged, with the
prefix. A RPL router may trivially transform a RPL PIO that it exception that a RPL router may update (extend) the prefix by
advertises in PIO messages back into a ND option to place in RAs so a appending it's own suffix. The format of the option is modified
node attached to the RPL router can also use it for all ND purposes (Type, Length, Prefix) in order to be carried as a RPL option as
including address autoconfiguration. The format of the option is follows:
modified slightly (Type, Length, Prefix) in order to be carried as a
RPL option as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| | Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime | | Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 59, line 29 skipping to change at page 60, line 26
The prefix length field provides necessary information for on- The prefix length field provides necessary information for on-
link determination (when combined with the L flag in the prefix link determination (when combined with the L flag in the prefix
information option). It also assists with address information option). It also assists with address
autoconfiguration as specified in [RFC4862], for which there autoconfiguration as specified in [RFC4862], for which there
may be more restrictions on the prefix length. may be more restrictions on the prefix length.
L 1-bit on-link flag. When set, indicates that this prefix can L 1-bit on-link flag. When set, indicates that this prefix can
be used for on-link determination. When not set the be used for on-link determination. When not set the
advertisement makes no statement about on-link or off-link advertisement makes no statement about on-link or off-link
properties of the prefix. In other words, if the L flag is not properties of the prefix. In other words, if the L flag is not
set a host MUST NOT conclude that an address derived from the set a RPL node MUST NOT conclude that an address derived from
prefix is off-link. That is, it MUST NOT update a previous the prefix is off-link. That is, it MUST NOT update a previous
indication that the address is on-link. indication that the address is on-link. A RPL node acting as a
router MUST NOT propagate a PIO with the L flag set. A RPL
node acting as a router MAY propagate a PIO with the L flag not
set.
A 1-bit autonomous address-configuration flag. When set A 1-bit autonomous address-configuration flag. When set
indicates that this prefix can be used for stateless address indicates that this prefix can be used for stateless address
configuration as specified in [RFC4862]. configuration as specified in [RFC4862]. When both protocols
(ND RAs and RPL DIOs) are used to carry PIOs on the same link,
it is possible to use either one for SLAAC by a RPL node. It
is also possible to make either protocol ineligible for SLAAC
operation by forcing the A flag to 0 for PIOs carried in that
protocol.
R 1-bit Router address flag. When set, indicates that the Prefix R 1-bit Router address flag. When set, indicates that the Prefix
field contains a complete IPv6 address assigned to the sending field contains a complete IPv6 address assigned to the sending
router that can be used as parent in a target option. The router that can be used as parent in a target option. The
indicated prefix is the first Prefix Length bits of the Prefix indicated prefix is the first Prefix Length bits of the Prefix
field. The router IPv6 address has the same scope and conforms field. The router IPv6 address has the same scope and conforms
to the same lifetime values as the advertised prefix. This use to the same lifetime values as the advertised prefix. This use
of the Prefix field is compatible with its use in advertising of the Prefix field is compatible with its use in advertising
the prefix itself, since Prefix Advertisement uses only the the prefix itself, since Prefix Advertisement uses only the
leading bits. Interpretation of this flag bit is thus leading bits. Interpretation of this flag bit is thus
skipping to change at page 64, line 8 skipping to change at page 65, line 8
1. If (256 + B - A) is less than or equal to 1. If (256 + B - A) is less than or equal to
SEQUENCE_WINDOW, then B is greater than A, A is less than SEQUENCE_WINDOW, then B is greater than A, A is less than
B, and the two are not equal. B, and the two are not equal.
2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A 2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A
is greater than B, B is less than A, and the two are not is greater than B, B is less than A, and the two are not
equal. equal.
For example, if A is 240, and B is 5, then (256 + 5 - 240) is For example, if A is 240, and B is 5, then (256 + 5 - 240) is
21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is
greater than 16. As another example, if A is 250 and B is 5, greater than 5. As another example, if A is 250 and B is 5,
then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW
(16), thus 250 is less than 5. (16), thus 250 is less than 5.
2. In the case where both sequence counters to be compared are 2. In the case where both sequence counters to be compared are
less than or equal to 127, and in the case where both less than or equal to 127, and in the case where both
sequence counters to be compared are greater than or equal to sequence counters to be compared are greater than or equal to
128: 128:
1. If the absolute magnitude of difference between the two 1. If the absolute magnitude of difference between the two
sequence counters is less than or equal to sequence counters is less than or equal to
skipping to change at page 80, line 32 skipping to change at page 81, line 32
information for a specific Target, and that has prior information information for a specific Target, and that has prior information
for that Target, MUST use the Path Sequence number in the Transit for that Target, MUST use the Path Sequence number in the Transit
Information option associated with that Target in order to Information option associated with that Target in order to
determine whether or not the DAO message contains updated determine whether or not the DAO message contains updated
information as per Section 7. information as per Section 7.
6. If a node receives a DAO message that does not follow the above 6. If a node receives a DAO message that does not follow the above
rules, it MUST discard the DAO message without further rules, it MUST discard the DAO message without further
processing. processing.
In non-storing mode additional rules apply to ensure the continuity In non-storing mode, the root builds a strict source routing header,
of end-to-end source route path: hop-by-hop, by recursively looking up one-hop information that ties a
target (address or prefix) and a transit address together. In some
cases, when a child address is derived from a prefix that is owned
and advertised by a parent, that parent-child relationship may be
inferred by the root for the purpose of constructing the source
routing header. In all other cases it is necessary to inform the
root of the transit-target relationship from a reachable target, so
as to later enable the recursive construction of the routing header.
An address that is advertised as target in a DAO message MUST be
collocated in the same router, or reachable onlink by the router that
owns the address that is indicated in the associated transit
information. The following additional rules apply to ensure the
continuity of the end-to-end source route path:
1. The address used as transit parent by the children MUST be taken 1. The address of a parent used in the transit option MUST be taken
from a PIO with the 'R' flag set from that parent but is not from a PIO from that parent with the 'R' flag set. The 'R' flag
necessarily on link for the children. in a PIO indicates that the prefix field actually contains the
full parent address but the child SHOULD NOT assume that the
parent address is onlink.
2. The router that advertises an address as parent in a PIO MUST 2. A PIO with a 'A' flag set indicates that the RPL child node may
also advertise that address as target in a DAO message. use the prefix to autoconfigure an address. A parent that
advertises a prefix in a PIO with the 'A' flag set MUST ensure
that the address or the whole prefix in the PIO is reachable from
the root by advertising it as a DAO target. If the parent sets
also the 'L' flag indicating that the prefix is onlink, then it
MUST advertise the whole prefix as target in a DAO message.
3. An address that is advertised as target in a DAO MUST be 3. An address that is advertised as target in a DAO message MUST be
collocated or reachable onlink by the parent that is indicated in collocated in the same router or reachable onlink by the router
the associated transit information. that owns the address that is indicated in the associated transit
information.
4. A router might have targets that are not known to be onlink for a 4. In order to enable an optimum compression of the routing header,
parent, either because they are addresses located on an alternate the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
interface or because they belong to nodes that are external to set and the 'L' flag cleared, and the child SHOULD prefer to use
RPL, for instance connected hosts. In order to inject such a as transit the address of the parent that is found in the PIO
target in the RPL network, the router MUST advertise itself as that is used to autoconfigure the address that is advertised as
the Parent Address in the Transit Information option for that target in the DAO message.
target, using an address that is onlink for that nodes DAO
parent. If the target belongs to an external node then the 5. A router might have targets that are not known to be on-link for
router MUST set the External 'E' flag in the transit information. a parent, either because they are addresses located on an
alternate interface or because they belong to nodes that are
external to RPL, for instance connected hosts. In order to
inject such a target in the RPL network, the router MUST
advertise itself as the Parent Address in the Transit Information
option for that target, using an address that is on-link for that
nodes DAO parent. If the target belongs to an external node then
the router MUST set the External 'E' flag in the transit
information.
A child node that has autoconfigured an address from a parent PIO
with the 'L' flag set does not need to advertise that address as a
DAO target since the parent insures that the whole prefix is already
reachable from the root. But if the 'L' flag is not set then it is
necessary in non-storing mode for the child node to inform the root
of the parent-child relationship, using a reachable address of the
parent, so as to enable the recursive construction of the routing
header. This is done by associating an address of the parent as
transit with the address of the child as target in a DAO message.
9.5. DAO Transmission Scheduling 9.5. DAO Transmission Scheduling
Because DAOs flow upwards, receiving a unicast DAO can trigger Because DAOs flow upwards, receiving a unicast DAO can trigger
sending a unicast DAO to a DAO parent. sending a unicast DAO to a DAO parent.
1. On receiving a unicast DAO message with updated information, such 1. On receiving a unicast DAO message with updated information, such
as containing a Transit Information option with a new Path as containing a Transit Information option with a new Path
Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO
message immediately. It SHOULD delay sending the DAO message in message immediately. It SHOULD delay sending the DAO message in
skipping to change at page 89, line 8 skipping to change at page 91, line 8
To join a RPL Instance, a node must have a pre-installed key. To join a RPL Instance, a node must have a pre-installed key.
Nodes use this key to provide message confidentiality, integrity, Nodes use this key to provide message confidentiality, integrity,
and authenticity. Using this preinstalled key, a node may join and authenticity. Using this preinstalled key, a node may join
the network as a host only. To join the network as a router, a the network as a host only. To join the network as a router, a
node must obtain a second key from a key authority. This key node must obtain a second key from a key authority. This key
authority can authenticate that the requester is allowed to be a authority can authenticate that the requester is allowed to be a
router before providing it with the second key. Authenticated router before providing it with the second key. Authenticated
mode cannot be supported by symmetric algorithms. As of this mode cannot be supported by symmetric algorithms. As of this
specification, RPL supports only symmetric algorithms: specification, RPL supports only symmetric algorithms:
authenticated mode is included for the benefit of potential future authenticated mode is included for the benefit of potential future
cryptographic primitives. cryptographic primitives. See Section 10.3.
Whether or not the RPL Instance uses unsecured mode is signaled by Whether or not the RPL Instance uses unsecured mode is signaled by
whether it uses secure RPL messages. Whether a secured network uses whether it uses secure RPL messages. Whether a secured network uses
the pre-installed or authenticated mode is signaled by the 'A' bit of the pre-installed or authenticated mode is signaled by the 'A' bit of
the DAG Configuration option. the DAG Configuration option.
This specification specifies CCM -- Counter with CBC-MAC (Cipher This specification specifies CCM -- Counter with CBC-MAC (Cipher
Block Chaining Message Authentication Code) -- as the cryptographic Block Chaining Message Authentication Code) -- as the cryptographic
basis for RPL security[RFC3610]. In this specification, CCM uses basis for RPL security[RFC3610]. In this specification, CCM uses
AES-128 as its underlying cryptographic algorithm. There are bits AES-128 as its underlying cryptographic algorithm. There are bits
skipping to change at page 90, line 41 skipping to change at page 92, line 41
a key that will enable it to act as a router. a key that will enable it to act as a router.
10.3. Installing Keys 10.3. Installing Keys
Authenticated mode requires a would-be router to dynamically install Authenticated mode requires a would-be router to dynamically install
new keys once they have joined a network as a host. Having joined as new keys once they have joined a network as a host. Having joined as
a host, the node uses standard IP messaging to communicate with an a host, the node uses standard IP messaging to communicate with an
authorization server, which can provide new keys. authorization server, which can provide new keys.
The protocol to obtain such keys is out of scope for this The protocol to obtain such keys is out of scope for this
specification and to be elaborated in future specifications. specification and to be elaborated in future specifications. That
elaboration is required for RPL to securely operate in authenticated
mode.
10.4. Consistency Checks 10.4. Consistency Checks
RPL nodes send Consistency Check (CC) messages to protect against RPL nodes send Consistency Check (CC) messages to protect against
replay attacks and synchronize counters. replay attacks and synchronize counters.
1. If a node receives a unicast CC message with the R bit cleared, 1. If a node receives a unicast CC message with the R bit cleared,
and it is a member of or is in the process of joining the and it is a member of or is in the process of joining the
associated DODAG, it SHOULD respond with a unicast CC message to associated DODAG, it SHOULD respond with a unicast CC message to
the sender. This response MUST have the R bit set, and MUST have the sender. This response MUST have the R bit set, and MUST have
skipping to change at page 92, line 30 skipping to change at page 94, line 31
node's security policy database. The configuration of this security node's security policy database. The configuration of this security
policy database for outgoing packet processing is implementation policy database for outgoing packet processing is implementation
specific. specific.
Where secured RPL messages are to be transmitted, a RPL node MUST set Where secured RPL messages are to be transmitted, a RPL node MUST set
the security section (T, Sec, KIM, and LVL) in the outgoing RPL the security section (T, Sec, KIM, and LVL) in the outgoing RPL
packet to describe the protection level and security settings that packet to describe the protection level and security settings that
are applied (see Section 6.1). The Security subfield bit of the RPL are applied (see Section 6.1). The Security subfield bit of the RPL
message Code field MUST be set to indicate the secure RPL message. message Code field MUST be set to indicate the secure RPL message.
The Counter value used in constructing the Nonce to secure the The Counter value used in constructing the AES-128 CCM Nonce
outgoing packet MUST be an increment of the last Counter transmitted (Figure 31) to secure the outgoing packet MUST be an increment of the
to the particular destination address. last Counter transmitted to the particular destination address.
Where security policy specifies the application of delay protection, Where security policy specifies the application of delay protection,
the Timestamp Counter used in constructing the Nonce to secure the the Timestamp Counter used in constructing the Nonce to secure the
outgoing packet MUST be incremented according to the rules in outgoing packet MUST be incremented according to the rules in
Section 10.5. Where a Timestamp Counter is applied (indicated with Section 10.5. Where a Timestamp Counter is applied (indicated with
the 'T' flag set) the locally maintained Time Counter MUST be the 'T' flag set) the locally maintained Time Counter MUST be
included as part of the transmitted secured RPL message. included as part of the transmitted secured RPL message.
The cryptographic algorithm used in securing the outgoing packet The cryptographic algorithm used in securing the outgoing packet
shall be specified by the node's security policy database and MUST be shall be specified by the node's security policy database and MUST be
skipping to change at page 96, line 45 skipping to change at page 98, line 45
10.9.2. Signatures 10.9.2. Signatures
If the Key Identification Mode (KIM) mode indicates the use of If the Key Identification Mode (KIM) mode indicates the use of
signatures (a value of 3), then a node appends a signature to the signatures (a value of 3), then a node appends a signature to the
data payload of the packet. The Security Level (LVL) field describes data payload of the packet. The Security Level (LVL) field describes
the length of this signature. the length of this signature.
The signature scheme in RPL for Security Mode 3 is an instantiation The signature scheme in RPL for Security Mode 3 is an instantiation
of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of
[RFC3447]. It uses as public key the pair (n,e), where n is a 3072- [RFC3447]. It uses as public key the pair (n,e), where n is a 2048-
bit RSA modulus and where e=2^{16}+1. It uses CCM mode[RFC3610] as bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode
the encryption scheme with M=0 (as a stream-cipher). It uses the [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
SHA-256 hash function specified in Section 6.2 of [FIPS180]. It uses Note that although [RFC3610] disallows CCM mode with M=0, this
the message encoding rules of Section 8.1 of [RFC3447]. specification explicitly allows CCM mode with M=0 when used in
conjunction with a signature as in this case, because the signature
provides sufficient protection. It uses the SHA-256 hash function
specified in Section 6.2 of [FIPS180]. It uses the message encoding
rules of Section 8.1 of [RFC3447].
Let 'a' be a concatenation of a six-byte representation of Counter Let 'a' be a concatenation of a six-byte representation of Counter
and the message header. The packet payload is the right- and the message header. The packet payload is the right-
concatenation of packet data 'm' and the signature 's'. This concatenation of packet data 'm' and the signature 's'. This
signature scheme is invoked with the right-concatenation of the signature scheme is invoked with the right-concatenation of the
message parts a and m, whereas the signature verification is invoked message parts a and m, whereas the signature verification is invoked
with the right-concatenation of the message parts a and m, and with with the right-concatenation of the message parts a and m, and with
signature s. signature s.
RSA signatures of this form provide sufficient protection for RPL RSA signatures of this form provide sufficient protection for RPL
networks. If needed, alternative signature schemes which produce networks. If needed, alternative signature schemes which produce
more concise signatures is out of scope for this specification and more concise signatures is out of scope for this specification and
may be the subject of a future specification. may be the subject of a future specification.
An implementation that supports RSA signing with either 2048-bit or
3072-bit signatures SHOULD support verification of both 2048-bit and
3072-bit RSA signatures. This is in consideration of providing an
upgrade path for a RPL deployment.
11. Packet Forwarding and Loop Avoidance/Detection 11. Packet Forwarding and Loop Avoidance/Detection
11.1. Suggestions for Packet Forwarding 11.1. Suggestions for Packet Forwarding
This document specifies a routing protocol. These non-normative This document specifies a routing protocol. These non-normative
suggestions are provided to aid in the design of a forwarding suggestions are provided to aid in the design of a forwarding
implementation by illustrating how such an implementation could work implementation by illustrating how such an implementation could work
with RPL with RPL
When forwarding a packet to a destination, precedence is given to When forwarding a packet to a destination, precedence is given to
skipping to change at page 131, line 35 skipping to change at page 133, line 35
| | | | | | | | | |
| 1 | 2 | See Figure 11 | This document | | 1 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 2 | 2 | See Figure 11 | This document | | 2 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 3 | 2 | See Figure 11 | This document | | 3 | 2 | See Figure 11 | This document |
| | | | | | | | | |
| 0 | 3 | See Figure 11 | This document | | 0 | 3 | See Figure 11 | This document |
| | | | | | | | | |
| 1 | 3 | See Figure 11 | This document | | 1 | 3 | See Figure 11 | This document |
| | | | |
| 2 | 3 | See Figure 11 | This document |
| | | | |
| 3 | 3 | See Figure 11 | This document |
+-------+-----------+---------------+---------------+ +-------+-----------+---------------+---------------+
Per-KIM Security Levels Per-KIM Security Levels
19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags 19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags
IANA is requested to create a registry for the DIS (DODAG IANA is requested to create a registry for the DIS (DODAG
Informational Solicitation) Flag Field. Informational Solicitation) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
skipping to change at page 139, line 22 skipping to change at page 141, line 22
draft-ietf-6man-rpl-option-01 (work in progress), draft-ietf-6man-rpl-option-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-01 (work in progress), draft-ietf-6man-rpl-routing-header-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Networks, D., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-11 (work in progress), draft-ietf-roll-routing-metrics-13 (work in progress),
October 2010. December 2010.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", draft-ietf-roll-trickle-04 (work "The Trickle Algorithm", draft-ietf-roll-trickle-06 (work
in progress), August 2010. in progress), December 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
skipping to change at page 140, line 28 skipping to change at page 142, line 28
Commerce , February 2008, Commerce , February 2008,
<http://www.nist.gov/itl/upload/fips180-3_final.pdf>. <http://www.nist.gov/itl/upload/fips180-3_final.pdf>.
[I-D.ietf-manet-nhdp] [I-D.ietf-manet-nhdp]
Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-14 (work in progress), July 2010. draft-ietf-manet-nhdp-14 (work in progress), July 2010.
[I-D.ietf-roll-of0] [I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0", Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-03 (work in progress), July 2010. draft-ietf-roll-of0-04 (work in progress), December 2010.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010. progress), September 2010.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks 7: 395-405, Information", North-Holland Computer Networks 7: 395-405,
1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/ 1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/
skipping to change at page 143, line 5 skipping to change at page 145, line 5
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
June 2010. June 2010.
Appendix A. Example Operation
This appendix provides some examples to illustrate the dissemination
of addressing information and prefixes with RPL. The examples depict
information being distributed with PIO and RIO options, and the use
of DIO and DAO messages. Note that this appendix is not normative,
and that the specific details of a RPL addressing plan and
autoconfiguration may vary according to specific implementations.
RPL merely provides a vehicle for disseminating information that may
be built upon and used by other mechanisms.
Note that these examples illustrate use of address autoconfiguration
schemes supported by information distributed within RPL. However, if
an implementation includes another address autoconfiguration scheme,
RPL nodes might be configured not to set the 'A' flag in PIO options,
though the PIO can still be used to distribute prefix and addressing
information.
A.1. Example with External Prefixes
Consider the simple network illustrated in Figure 32. In this
example there are a group of routers participating in a RPL network:
a DODAG Root, nodes A, Y, and Z. The DODAG Root and node Z also have
connectivity to different external network domains (i.e. external to
the RPL network). Note that those external networks could be RPL
networks or another type of network altogether.
RPL Network +-------------------+
RPL::/64 | |
| External |
[RPL::Root] (Root)----------+ Prefix |
| | EXT_1::/64 |
| | |
| +-------------------+
[RPL::A] (A)
:
:
:
[RPL::Y] (Y)
| +-------------------+
| | |
| | External |
[RPL::Z] (Z)------------+ Prefix |
| | EXT_2::/64 |
| | |
| +-------------------+
[RPL::Host1] (Host1)
Figure 32: Simple Network Example
In this example the DODAG Root makes a prefix available to the RPL
subnet for address autoconfiguration. Here the entire RPL subnet
uses that same prefix, RPL::/64, for address autoconfiguration,
though in other implementations more complex/hybrid schemes could be
employed.
The DODAG Root has connectivity to an external (with respect to that
RPL network) prefix EXT_1::/64. The DODAG Root may have learned of
connectivity to this prefix, for example, via explicit configuration
or IPv6 ND on a non-RPL interface. The DODAG Root is configured to
announce information on the connectivity to this prefix.
Similarly, Node Z has connectivity to an external prefix EXT_2::/64.
Node Z also has direct connectivity to the node Host1.
1. The DODAG Root adds a RIO to its DIO messages. The RIO contains
the external prefix 2001:DB8:1:1::/64. This information may be
repeated in the DIO messages emitted by the other nodes within
the DODAG. Thus the reachability to the prefix 2001:DB8:1:1::/64
is disseminated down the DODAG.
2. Node Z may announce the prefix information to a non-RPL aware
host, Host1. Host1 may then participate in address
autoconfiguration and obtain the address, for example, RPL::
Host1.
3. Node Z may interact with another neighboring non-RPL router in
EXT_2::/64. Node Z may repackage the information learned from
the RPL network in order to announce that information into the
other neighboring network. For example, Node Z may repackage a
RIO to indicate reachability to EXT_1::/64.
4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs
containing Host1 as a Target and itself (Node Z) as a parent in
the Transit Information option. (In storing mode that Transit
Information option does not need to contain the address of Node
Z). A non-storing root then becomes aware of the 1-hop link Node
Z -- Host1 for use in constructing source routes.
5. Node Z may advertise reachability to the target network
EXT_2::/64 by sending DAO messages using EXT_2::/64 as a target
in the Target option and itself (Node Z) as a parent in the
Transit Information option. (In storing mode that Transit
Information option does not need to contain the address of Node
Z). A non-storing root then becomes aware of the 1-hop link
(Node Z -- EXT_2::/64) for use in constructing source routes.
Node Z may additionally advertise its reachability to EXT_2::/64
to nodes in its sub-DODAG by sending DIO messages with a PIO,
with the 'A' flag cleared.
A.2. Example Operation in Storing Mode With Node-owned Prefixes
Figure 33 illustrates the logical addressing architecture of a simple
RPL network operating in storing mode. In this example each node, A,
B, C, and D, owns its own prefix, and makes that prefix available for
address autoconfiguration by on-link devices. (This is conveyed by
setting the 'A' flag and the 'L' flag in the PIO of the DIO
messages). Node A owns the prefix A::/64, node B owns B::/64, and so
on. Node B autoconfigures an on-link address with respect to node A,
A::B. Nodes C and D similarly autoconfigure on-link addresses from
Node B's prefix, B::C and B::D respectively. Nodes have the option
of setting the 'R' flag and publishing their address within the
Prefix field of the PIO.
+-------------+
| Root |
| |
| Node A |
| |
| A::A |
+------+------+
|
|
|
+------+------+
| A::B |
| |
| Node B |
| |
| B::B |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| B::C | | B::D |
| | | |
| Node C | | Node D |
| | | |
| C::C | | D::D |
+-------------+ +-------------+
Figure 33: Storing Mode with Node-owned Prefixes
A.2.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Set
'R' flag: Clear
Prefix Length: 64
Prefix: A::
Node B, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Set
'R' flag: Set
Prefix Length: 64
Prefix: B::B
Node C, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Set
'R' flag: Clear
Prefix Length: 64
Prefix: C::
Node D, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Set
'R' flag: Set
Prefix Length: 64
Prefix: D::D
A.2.2. DAO messages
Node B will send DAO messages to node A with the following
information:
o Target B::/64
o Target C::/64
o Target D::/64
Node C will send DAO messages to node B with the following
information:
o Target C::/64
Node D will send DAO messages to node B with the following
information:
o Target D::/64
A.2.3. Routing Information Base
Node A will conceptually collect the following information into its
RIB:
o A::/64 connected
o B::/64 via B's link local
o C::/64 via B's link local
o D::/64 via B's link local
Node B will conceptually collect the following information into its
RIB:
o ::/0 via A's link local
o B::/64 connected
o C::/64 via C's link local
o D::/64 via D's link local
Node C will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o C::/64 connected
Node D will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o D::/64 connected
A.3. Example Operation in Storing Mode With Subnet-wide Prefix
Figure 34 illustrates the logical addressing architecture of a simple
RPL network operating in storing mode. In this example the root node
A sources a prefix which is used for address autoconfiguration over
the entire RPL subnet. (This is conveyed by setting the 'A' flag and
clearing the 'L' flag in the PIO of the DIO messages). Nodes A, B,
C, and D all autoconfigure to the prefix A::/64. Nodes have the
option of setting the 'R' flag and publishing their address within
the Prefix field of the PIO.
+-------------+
| Root |
| |
| Node A |
| A::A |
| |
+------+------+
|
|
|
+------+------+
| |
| Node B |
| A::B |
| |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| | | |
| Node C | | Node D |
| A::C | | A::D |
| | | |
+-------------+ +-------------+
Figure 34: Storing Mode with Subnet-wide Prefix
A.3.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Clear
Prefix Length: 64
Prefix: A::
Node B, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::B
Node C, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Clear
Prefix Length: 64
Prefix: A::
Node D, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::D
A.3.2. DAO messages
Node B will send DAO messages to node A with the following
information:
o Target A::B/128
o Target A::C/128
o Target A::D/128
Node C will send DAO messages to node B with the following
information:
o Target A::C/128
Node D will send DAO messages to node B with the following
information:
o Target A::D/128
A.3.3. Routing Information Base
Node A will conceptually collect the following information into its
RIB:
o A::/128 connected
o B::/128 via B's link local
o C::/128 via B's link local
o D::/128 via B's link local
Node B will conceptually collect the following information into its
RIB:
o ::/0 via A's link local
o B::/128 connected
o C::/128 via C's link local
o D::/128 via D's link local
Node C will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o C::/128 connected
Node D will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o D::/128 connected
A.4. Example Operation in Non-Storing Mode With Node-owned Prefixes
Figure 35 illustrates the logical addressing architecture of a simple
RPL network operating in non-storing mode. In this example each
node, A, B, C, and D, owns its own prefix, and makes that prefix
available for address autoconfiguration by on-link devices. (This is
conveyed by setting the 'A' flag and the 'L' flag in the PIO of the
DIO messages). Node A owns the prefix A::/64, node B owns B::/64,
and so on. Node B autoconfigures an on-link address with respect to
node A, A::B. Nodes C and D similarly autoconfigure on-link addresses
from Node B's prefix, B::C and B::D respectively. Nodes have the
option of setting the 'R' flag and publishing their address within
the Prefix field of the PIO.
+-------------+
| Root |
| |
| Node A |
| |
| A::A |
+------+------+
|
|
|
+------+------+
| A::B |
| |
| Node B |
| |
| B::B |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| B::C | | B::D |
| | | |
| Node C | | Node D |
| | | |
| C::C | | D::D |
+-------------+ +-------------+
Figure 35: Non-storing Mode with Node-owned Prefixes
A.4.1. DIO messages and PIO
The PIO contained in the DIO messages in the non-storing mode with
node-owned prefixes can be considered to be identical to those in the
storing mode with node-owned prefixes case (Appendix A.2.1).
A.4.2. DAO messages
Node B will send DAO messages to node A with the following
information:
o Target B::/64, Transit A::B
Node C will send DAO messages to node A with the following
information:
o Target C::/64, Transit B::C
Node D will send DAO messages to node A with the following
information:
o Target D::/64, Transit B::D
A.4.3. Routing Information Base
Node A will conceptually collect the following information into its
RIB. Note that Node A has enough information to construct source
routes by doing recursive lookups into the RIB:
o A::/64 connected
o B::/64 via A::B
o C::/64 via B::C
o D::/64 via B::D
Node B will conceptually collect the following information into its
RIB:
o ::/0 via A's link local
o B::/64 connected
Node C will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o C::/64 connected
Node D will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o D::/64 connected
A.5. Example Operation in Non-Storing Mode With Subnet-wide Prefix
Figure 36 illustrates the logical addressing architecture of a simple
RPL network operating in non-storing mode. In this example the root
node A sources a prefix which is used for address autoconfiguration
over the entire RPL subnet. (This is conveyed by setting the 'A'
flag and clearing the 'L' flag in the PIO of the DIO messages).
Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes
must set the 'R' flag and publishing their address within the Prefix
field of the PIO, in order to inform their children which address to
use in the transit option.
+-------------+
| Root |
| |
| Node A |
| A::A |
| |
+------+------+
|
|
|
+------+------+
| |
| Node B |
| A::B |
| |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| | | |
| Node C | | Node D |
| A::C | | A::D |
| | | |
+-------------+ +-------------+
Figure 36: XXX
A.5.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::A
Node B, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::B
Node C, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::C
Node D, for example, will send DIO messages with a PIO as follows:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::D
A.5.2. DAO messages
Node B will send DAO messages to node A with the following
information:
o Target A::B/128, Transit A::A
Node C will send DAO messages to node A with the following
information:
o Target A::C/128, Transit A::B
Node D will send DAO messages to node A with the following
information:
o Target A::D/128, Transit A::B
A.5.3. Routing Information Base
Node A will conceptually collect the following information into its
RIB. Note that Node A has enough information to construct source
routes by doing recursive lookups into the RIB:
o A::A/128 connected
o B::B/128 via A::A
o C::C/128 via A::B
o D::D/128 via A::B
Node B will conceptually collect the following information into its
RIB:
o ::/0 via A's link local
o A::B/128 connected
Node C will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o A::C/128 connected
Node D will conceptually collect the following information into its
RIB:
o ::/0 via B's link local
o A::D/128 connected
Authors' Addresses Authors' Addresses
Tim Winter (editor) Tim Winter (editor)
Email: wintert@acm.org Email: wintert@acm.org
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
 End of changes. 45 change blocks. 
254 lines changed or deleted 897 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/