draft-ietf-roll-rpl-13.txt   draft-ietf-roll-rpl-14.txt 
ROLL T. Winter, Ed. ROLL T. Winter, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: April 25, 2011 Cisco Systems Expires: April 28, 2011 Cisco Systems
A. Brandt A. Brandt
Sigma Designs Sigma Designs
T. Clausen T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
J. Hui J. Hui
Arch Rock Corporation Arch Rock Corporation
R. Kelsey R. Kelsey
Ember Corporation Ember Corporation
P. Levis P. Levis
Stanford University Stanford University
K. Pister K. Pister
Dust Networks Dust Networks
R. Struik R. Struik
JP. Vasseur JP. Vasseur
Cisco Systems Cisco Systems
October 22, 2010 October 25, 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-13 draft-ietf-roll-rpl-14
Abstract Abstract
Low power and Lossy Networks (LLNs) are a class of network in which Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by energy (battery power). Their interconnects are characterized by
high loss rates, low data rates, and instability. LLNs are comprised high loss rates, low data rates, and instability. LLNs are comprised
of anything from a few dozen and up to thousands of routers. of anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices Supported traffic flows include point-to-point (between devices
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 34 skipping to change at page 3, line 34
3.4. Downward Routes and Destination Advertisement . . . . . 17 3.4. Downward Routes and Destination Advertisement . . . . . 17
3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 18 3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . 18
3.6. Rank Properties . . . . . . . . . . . . . . . . . . . . 18 3.6. Rank Properties . . . . . . . . . . . . . . . . . . . . 18
3.6.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 19 3.6.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 19
3.6.2. Rank Relationships . . . . . . . . . . . . . . . . . 20 3.6.2. Rank Relationships . . . . . . . . . . . . . . . . . 20
3.7. Routing Metrics and Constraints Used By RPL . . . . . . 20 3.7. Routing Metrics and Constraints Used By RPL . . . . . . 20
3.8. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 22 3.8. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 22
3.8.1. Greediness and Instability . . . . . . . . . . . . . 22 3.8.1. Greediness and Instability . . . . . . . . . . . . . 22
3.8.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 24 3.8.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 24 3.8.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 24
4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 25 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 26
4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 25 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 26
4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 25 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 26
4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 25 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 26
5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 26 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 26 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 27
6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 28 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 29
6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 30 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 31
6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 35 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 35
6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 35 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 35
6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 35 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 35
6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 35 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 35
6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 36 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 36
6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 36 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 36
6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 38 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 38
6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 38 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 38
6.4. Destination Advertisement Object (DAO) . . . . . . . . . 38 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 38
6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 38 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 38
skipping to change at page 4, line 23 skipping to change at page 4, line 23
6.7. RPL Control Message Options . . . . . . . . . . . . . . 43 6.7. RPL Control Message Options . . . . . . . . . . . . . . 43
6.7.1. RPL Control Message Option Generic Format . . . . . . 43 6.7.1. RPL Control Message Option Generic Format . . . . . . 43
6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 44 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 44
6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 45 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 45 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 45
6.7.5. Route Information . . . . . . . . . . . . . . . . . . 46 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 46
6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 48 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 48
6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 49 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 49
6.7.8. Transit Information . . . . . . . . . . . . . . . . . 51 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 51
6.7.9. Solicited Information . . . . . . . . . . . . . . . . 54 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 54
6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 56 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 55
6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 58 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 58
7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 60 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 60
7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 60 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 60
7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 61 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 61
8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 63 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 63 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 63
8.2. Upward Route Discovery and Maintenance . . . . . . . . . 63 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 63
8.2.1. Neighbors and Parents within a DODAG Version . . . . 63 8.2.1. Neighbors and Parents within a DODAG Version . . . . 63
8.2.2. Neighbors and Parents across DODAG Versions . . . . . 64 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 64
8.2.3. DIO Message Communication . . . . . . . . . . . . . . 69 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 69
skipping to change at page 6, line 8 skipping to change at page 6, line 8
17.3.2. Monitoring a DODAG inconsistencies and loop 17.3.2. Monitoring a DODAG inconsistencies and loop
detection . . . . . . . . . . . . . . . . . . . . . . 115 detection . . . . . . . . . . . . . . . . . . . . . . 115
17.4. Monitoring of the RPL data structures . . . . . . . . . 116 17.4. Monitoring of the RPL data structures . . . . . . . . . 116
17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 116 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 116
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) 17.4.2. Destination Oriented Directed Acyclic Graph (DAG)
Table . . . . . . . . . . . . . . . . . . . . . . . . 116 Table . . . . . . . . . . . . . . . . . . . . . . . . 116
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117
17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118
17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118
17.7. Liveness Detection and Monitoring . . . . . . . . . . . 119 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 119
17.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 120 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 120
17.9. Impact on Other Protocols . . . . . . . . . . . . . . . 120 17.9. Performance Management . . . . . . . . . . . . . . . . . 120
17.10. Performance Management . . . . . . . . . . . . . . . . . 120 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 120
17.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 121 18. Security Considerations . . . . . . . . . . . . . . . . . . . 121
18. Security Considerations . . . . . . . . . . . . . . . . . . . 122 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 121
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 122 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 123
19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 124 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 123
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 124 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 124
19.3. New Registry for the Mode of Operation (MOP) DIO 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 125
Control Field . . . . . . . . . . . . . . . . . . . . . 125 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 125
19.4. RPL Control Message Option . . . . . . . . . . . . . . . 126 19.6. New Registry for the Security Section Algorithm . . . . 126
19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 126 19.7. New Registry for the Security Section Flags . . . . . . 126
19.6. New Registry for the Security Section Algorithm . . . . 127 19.8. New Registry for the Key Identification Mode . . . . . . 127
19.7. New Registry for the Security Section Flags . . . . . . 127 19.9. New Registry for the KIM levels . . . . . . . . . . . . 127
19.8. New Registry for the Key Identification Mode . . . . . . 128
19.9. New Registry for the KIM levels . . . . . . . . . . . . 128
19.10. New Registry for the DIS (DODAG Informational 19.10. New Registry for the DIS (DODAG Informational
Solicitation) Flags . . . . . . . . . . . . . . . . . . 129 Solicitation) Flags . . . . . . . . . . . . . . . . . . 128
19.11. New Registry for the DODAG Information Object (DIO) 19.11. New Registry for the DODAG Information Object (DIO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 130 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 129
19.12. New Registry for the Destination Advertisement Object 19.12. New Registry for the Destination Advertisement Object
(DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 130 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 129
19.13. New Registry for the Destination Advertisement Object 19.13. New Registry for the Destination Advertisement Object
(DAO) Acknowledgement Flags . . . . . . . . . . . . . . 131 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 130
19.14. New Registry for the Consistency Check (CC) Flags . . . 131 19.14. New Registry for the Consistency Check (CC) Flags . . . 130
19.15. New Registry for the DODAG Configuration Option Flags . 132 19.15. New Registry for the DODAG Configuration Option Flags . 131
19.16. New Registry for the RPL Target Option Flags . . . . . . 132 19.16. New Registry for the RPL Target Option Flags . . . . . . 131
19.17. New Registry for the Transit Information Option Flags . 133 19.17. New Registry for the Transit Information Option Flags . 132
19.18. New Registry for the Solicited Information Option 19.18. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 133 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132
19.19. ICMPv6: Error in Source Routing Header . . . . . . . . . 134 19.19. ICMPv6: Error in Source Routing Header . . . . . . . . . 133
19.20. Link-Local Scope multicast address . . . . . . . . . . . 134 19.20. Link-Local Scope multicast address . . . . . . . . . . . 133
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 135 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 134
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 136 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 135
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 136
22.1. Normative References . . . . . . . . . . . . . . . . . . 137 22.1. Normative References . . . . . . . . . . . . . . . . . . 136
22.2. Informative References . . . . . . . . . . . . . . . . . 138 22.2. Informative References . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140
1. Introduction 1. Introduction
Low power and Lossy Networks (LLNs) consist of largely of constrained Low power and Lossy Networks (LLNs) consist of largely of constrained
nodes (with limited processing power, memory, and sometimes energy nodes (with limited processing power, memory, and sometimes energy
when they are battery operated or energy scavenging). These routers when they are battery operated or energy scavenging). These routers
are interconnected by lossy links, typically supporting only low data are interconnected by lossy links, typically supporting only low data
rates, that are usually unstable with relatively low packet delivery rates, that are usually unstable with relatively low packet delivery
rates. Another characteristic of such networks is that the traffic rates. Another characteristic of such networks is that the traffic
patterns are not simply point-to-point, but in many cases point-to- patterns are not simply point-to-point, but in many cases point-to-
skipping to change at page 7, line 46 skipping to change at page 7, line 46
In order to be useful in a wide range of LLN application domains, RPL In order to be useful in a wide range of LLN application domains, RPL
separates packet processing and forwarding from the routing separates packet processing and forwarding from the routing
optimization objective. Examples of such objectives include optimization objective. Examples of such objectives include
minimizing energy, minimizing latency, or satisfying constraints. minimizing energy, minimizing latency, or satisfying constraints.
This document describes the mode of operation of RPL. Other This document describes the mode of operation of RPL. Other
companion documents specify routing objective functions. A RPL companion documents specify routing objective functions. A RPL
implementation, in support of a particular LLN application, will implementation, in support of a particular LLN application, will
include the necessary objective function(s) as required by the include the necessary objective function(s) as required by the
application. application.
RPL operations require bidirectional links. RPL expects an external
mechanism to verify link properties and neighbor reachability.
Neighbor Unreachability Detection (NUD) is an example such a
mechanism, but alternates are possible, such as L2 triggers.
RPL provides a mechanism to disseminate information, in particular a
prefix shared within a subnet. When this is used, one or more
routers own a prefix and are authoritative for generating its
advertisements. Other routers propagate the prefix information
without changing the prefix or the associated control information.
This capability of announcing the subnet prefix is not to be confused
with route advertisements, and this mechanism does not by any means
constrain RPL operations to within a subnet. Routers that own
prefixes can also benefit from RPL to form a larger routed structures
whereby each router announces its prefixes to its peers in the
network.
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
is designed to be able to operate over a variety of different link is designed to be able to operate over a variety of different link
skipping to change at page 9, line 30 skipping to change at page 9, line 30
DAG root: A DAG root is a node within the DAG that has no outgoing DAG root: A DAG root is a node within the DAG that has no outgoing
edge. Because the graph is acyclic, by definition all DAGs edge. Because the graph is acyclic, by definition all DAGs
must have at least one DAG root and all paths terminate at a must have at least one DAG root and all paths terminate at a
DAG root. DAG root.
Destination Oriented DAG (DODAG): A DAG rooted at a single Destination Oriented DAG (DODAG): A DAG rooted at a single
destination, i.e. at a single DAG root (the DODAG root) with no destination, i.e. at a single DAG root (the DODAG root) with no
outgoing edges. outgoing edges.
DODAG root: A DODAG root is the DAG root of a DODAG. DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root
may act as a border router for the DODAG, and in particular it
may aggregate routes in the DODAG, and may redistribute DODAG
routes into other routing protocols.
Virtual DODAG root: A Virtual DODAG root is the result of two or Virtual DODAG root: A Virtual DODAG root is the result of two or
more RPL routers, most typically LBRs, coordinating to more RPL routers, for instance 6LoWPAN Border Routers (6LBRs),
synchronize DODAG state and act in concert as if they are a coordinating to synchronize DODAG state and act in concert as
single DODAG root (with multiple interfaces), with respect to if they are a single DODAG root (with multiple interfaces),
the LLN. The coordination most likely occurs between powered with respect to the LLN. The coordination most likely occurs
devices over a reliable transit link, and the details of that between powered devices over a reliable transit link, and the
scheme are out of scope for this specification (to be defined details of that scheme are out of scope for this specification
in future companion specifications). (to be defined in future companion specifications).
Up: Up refers to the direction from leaf nodes towards DODAG roots, Up: Up refers to the direction from leaf nodes towards DODAG roots,
following DODAG edges. This follows the common terminology following DODAG edges. This follows the common terminology
used in graphs and depth-first-search, where vertices further used in graphs and depth-first-search, where vertices further
from the root are "deeper," or "down," and vertices closer to from the root are "deeper," or "down," and vertices closer to
the root are "shallower," or "up". the root are "shallower," or "up".
Down: Down refers to the direction from DODAG roots towards leaf Down: Down refers to the direction from DODAG roots towards leaf
nodes, in the reverse direction of DODAG edges. This follows nodes, in the reverse direction of DODAG edges. This follows
the common terminology used in graphs and depth-first-search, the common terminology used in graphs and depth-first-search,
skipping to change at page 16, line 32 skipping to change at page 16, line 32
3.3.6. Administrative Preference 3.3.6. Administrative Preference
An implementation/deployment may specify that some DODAG roots should An implementation/deployment may specify that some DODAG roots should
be used over others through an administrative preference. be used over others through an administrative preference.
Administrative preference offers a way to control traffic and Administrative preference offers a way to control traffic and
engineer DODAG formation in order to better support application engineer DODAG formation in order to better support application
requirements or needs. requirements or needs.
3.3.7. Datapath Validation and Loop Detection 3.3.7. Datapath Validation and Loop Detection
RPL carries routing information in a RPL Option contained in an IPv6 RPL often needs to carry control information in data packets. This
Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-option]. Such information is used to validate the routing states as discussed in
routing information is used, for example, for loop detection within a Section 11.2. The only exception is when strict source routing is
DODAG as discussed in Section 11.2 and may be extended in future used for packets going downward in non-storing mode (detailed further
specifications for additional features. in Section 9), which by nature prevents endless loops and alleviates
the need for the control information.
RPL control information may be extended to add additional features in
future companion specifications.
The low-power and lossy nature of LLNs motivates RPL's use of on- The low-power and lossy nature of LLNs motivates RPL's use of on-
demand loop detection using data packets. Because data traffic can demand loop detection using data packets. Because data traffic can
be infrequent, maintaining a routing topology that is constantly up be infrequent, maintaining a routing topology that is constantly up
to date with the physical topology can waste energy. Typical LLNs to date with the physical topology can waste energy. Typical LLNs
exhibit variations in physical connectivity that are transient and exhibit variations in physical connectivity that are transient and
innocuous to traffic, but that would be costly to track closely from innocuous to traffic, but that would be costly to track closely from
the control plane. Transient and infrequent changes in connectivity the control plane. Transient and infrequent changes in connectivity
need not be addressed by RPL until there is data to send. This need not be addressed by RPL until there is data to send. This
aspect of RPL's design draws from existing, highly used LLN protocols aspect of RPL's design draws from existing, highly used LLN protocols
skipping to change at page 30, line 40 skipping to change at page 31, line 40
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Section Figure 8: Security Section
Message authentication codes (MACs) and signatures cover the entire Message authentication codes (MACs) and signatures cover the entire
ICMPv6 RPL message, while encryption starts after the Security ICMPv6 RPL message, while encryption starts after the Security
section. Use of the Security section is further detailed in section. Use of the Security section is further detailed in
Section 18 and Section 10. Section 18 and Section 10.
Security Control Field: The Security Control Field has one flag and Counter is Time (T): If the Counter is Time flag is set then the
three fields: Counter field is a timestamp. If the flag is cleared then the
Counter is an incrementing counter. Section 10.5 describes the
Counter is Time (T): If the Counter is Time flag is set then details of the 'T' flag and Counter field.
the Counter field is a timestamp. If the flag is cleared
then the Counter is an incrementing counter.
Section 10.5 describes the details of the 'T' flag and
Counter field.
Security Level (Level): The Security Level field indicates the Security Level (Level): The Security Level field indicates the
provided packet protection. This value can be adapted on provided packet protection. This value can be adapted on a
a per-packet basis and allows for varying levels of data per-packet basis and allows for varying levels of data
authenticity and, optionally, for data confidentiality. authenticity and, optionally, for data confidentiality. The
The KIM field indicates whether signatures are used and KIM field indicates whether signatures are used and the meaning
the meaning of the Level field. The Security Level is of the Level field. The Security Level is set to one of the
set to one of the values in the tables below: values in the tables below:
+---------------------------+ +---------------------------+
| KIM=0,1,2 | | KIM=0,1,2 |
+-------+--------------------+------+ +-------+--------------------+------+
| LVL | Attributes | MAC | | LVL | Attributes | MAC |
| | | Len | | | | Len |
+-------+--------------------+------+ +-------+--------------------+------+
| 0 | MAC-32 | 4 | | 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 | | 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 | | 2 | MAC-64 | 8 |
skipping to change at page 31, line 37 skipping to change at page 32, line 31
| KIM=3 | | KIM=3 |
+-------+---------------+-----+ +-------+---------------+-----+
| LVL | Attributes | Sig | | LVL | Attributes | Sig |
| | | Len | | | | Len |
+-------+---------------+-----+ +-------+---------------+-----+
| 0 | Sign-3072 | 384 | | 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 | | 1 | ENC-Sign-3072 | 384 |
| 2-127 | Unassigned | N/A | | 2-127 | Unassigned | N/A |
+-------+---------------+-----+ +-------+---------------+-----+
Figure 9: Security Level (LVL) Encoding Figure 9: Security Level (LVL) Encoding
The MAC attribute indicates that the message has a The MAC attribute indicates that the message has a Message
Message Authentication Code of the specified length. The Authentication Code of the specified length. The ENC attribute
ENC attribute indicates that the message is encrypted. indicates that the message is encrypted. The Sign attribute
The Sign attribute indicates that the message has a indicates that the message has a signature of the specified
signature of the specified length. length.
Security Algorithm (Algorithm): The Security Algorithm field Security Algorithm (Algorithm): The Security Algorithm field
specifies the encryption, MAC, and signature scheme the specifies the encryption, MAC, and signature scheme the network
network uses. Supported values of this field are as uses. Supported values of this field are as follows:
follows:
+-----------+-------------------+------------------------+ +-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature | | Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+ +-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA2 | | 0 | CCM with AES-128 | RSA with SHA2 |
| 1-255 | Unassigned | Unassigned | | 1-255 | Unassigned | Unassigned |
+-------+-------------------+----------------------------+ +-------+-------------------+----------------------------+
Figure 10: Security Algorithm (Algorithm) Encoding Figure 10: Security Algorithm (Algorithm) Encoding
Section 10.9 describes the algorithms in greater detail. Section 10.9 describes the algorithms in greater detail.
Key Identifier Mode (KIM): The Key Identifier Mode field Key Identifier Mode (KIM): The Key Identifier Mode field indicates
indicates whether the key used for packet protection is whether the key used for packet protection is determined
determined implicitly or explicitly and indicates the implicitly or explicitly and indicates the particular
particular representation of the Key Identifier field. representation of the Key Identifier field. The Key Identifier
The Key Identifier Mode is set one of the values from the Mode is set one of the values from the table below:
table below:
+------+-----+-----------------------------+------------+ +------+-----+-----------------------------+------------+
| Mode | KIM | Meaning | Key | | Mode | KIM | Meaning | Key |
| | | | Identifier | | | | | Identifier |
| | | | Length | | | | | Length |
| | | | (octets) | | | | | (octets) |
+------+-----+-----------------------------+------------+ +------+-----+-----------------------------+------------+
| 0 | 00 | Group key used. | 1 | | 0 | 00 | Group key used. | 1 |
| | | Key determined by Key Index | | | | | Key determined by Key Index | |
| | | field. | | | | | field. | |
skipping to change at page 33, line 42 skipping to change at page 33, line 50
| 3 | 11 | Node's signature key used. | 0/9 | | 3 | 11 | Node's signature key used. | 0/9 |
| | | If packet is encrypted, | | | | If packet is encrypted, |
| | | it uses a group key, Key | | | | | it uses a group key, Key | |
| | | Index and Key Source | | | | | Index and Key Source | |
| | | specify key. | | | | | specify key. | |
| | | | | | | | | |
| | | Key Source may be present. | | | | | Key Source may be present. | |
| | | Key Index may be present. | | | | | Key Index may be present. | |
+------+-----+-----------------------------+------------+ +------+-----+-----------------------------+------------+
Figure 11: Key Identifier Mode (KIM) Figure 11: Key Identifier Mode (KIM) Encoding
Encoding
In Mode 3 (KIM=11), the presence or absence of the Key In Mode 3 (KIM=11), the presence or absence of the Key Source
Source and Key Identifier depends on the Security Level and Key Identifier depends on the Security Level (LVL)
(LVL) described below. If the Security Level indicates described below. If the Security Level indicates there is
there is encryption, then the fields are present; if it encryption, then the fields are present; if it indicates there
indicates there is no encryption, then the fields are not is no encryption, then the fields are not present.
present.
Reserved: 5-bit unused field. The field MUST be initialized to zero Reserved: 5-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.
Flags: 8-bit unused field reserved for flags. The field MUST be Flags: 8-bit unused field reserved for flags. The field MUST be
initialized to zero by the sender and MUST be ignored by the initialized to zero by the sender and MUST be ignored by the
receiver. receiver.
Counter: The Counter field indicates the non-repeating 4-octet value Counter: The Counter field indicates the non-repeating 4-octet value
(nonce) used with the cryptographic mechanism that implements (nonce) used with the cryptographic mechanism that implements
skipping to change at page 36, line 33 skipping to change at page 36, line 37
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 14: The DIO Base Object Figure 14: The DIO Base Object
Control Field: The DAG Control Field has three flags and two fields: Grounded (G): The Grounded (G) flag indicates whether the DODAG
advertised can satisfy the application-defined goal. If the
Grounded (G): The Grounded (G) flag indicates whether the flag is set, the DODAG is grounded. If the flag is cleared,
DODAG advertised can satisfy the application-defined the DODAG is floating.
goal. If the flag is set, the DODAG is grounded. If the
flag is cleared, the DODAG is floating.
Mode of Operation (MOP): The Mode of Operation (MOP) field Mode of Operation (MOP): The Mode of Operation (MOP) field
identifies the mode of operation of the RPL Instance as identifies the mode of operation of the RPL Instance as
administratively provisioned at and distributed by the administratively provisioned at and distributed by the DODAG
DODAG Root. All nodes who join the DODAG must be able to Root. All nodes who join the DODAG must be able to honor the
honor the MOP in order to fully participate as a router, MOP in order to fully participate as a router, or else they
or else they must only join as a leaf. MOP is encoded as must only join as a leaf. MOP is encoded as in the figure
in the figure below: below:
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
| MOP | Meaning | | MOP | Meaning |
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
| 0 | No downward routes maintained by RPL | | 0 | No downward routes maintained by RPL |
| 1 | Non storing mode | | 1 | Non storing mode |
| 2 | Storing without multicast support | | 2 | Storing without multicast support |
| 3 | Storing with multicast support | | 3 | Storing with multicast support |
| | | | | |
| | All other values are unassigned | | | All other values are unassigned |
+-----+-------------------------------------------------+ +-----+-------------------------------------------------+
A value of 0 indicates that destination advertisement A value of 0 indicates that destination advertisement messages
messages are disabled and the DODAG maintains only upward are disabled and the DODAG maintains only upward routes
routes
Figure 15: Mode of Operation (MOP) Encoding Figure 15: Mode of Operation (MOP) Encoding
DODAGPreference (Prf): A 3-bit unsigned integer that defines DODAGPreference (Prf): A 3-bit unsigned integer that defines how
how preferable the root of this DODAG is compared to preferable the root of this DODAG is compared to other DODAG
other DODAG roots within the instance. DAGPreference roots within the instance. DAGPreference ranges from 0x00
ranges from 0x00 (least preferred) to 0x07 (most (least preferred) to 0x07 (most preferred). The default is 0
preferred). The default is 0 (least preferred). (least preferred). Section 8.2 describes how DAGPreference
Section 8.2 describes how DAGPreference affects DIO affects DIO processing.
processing.
Version Number: 8-bit unsigned integer set by the DODAG root to the Version Number: 8-bit unsigned integer set by the DODAG root to the
DODAGVersionNumber. Section 8.2 describes the rules for DODAG DODAGVersionNumber. Section 8.2 describes the rules for DODAG
Version numbers and how they affect DIO processing. Version numbers and how they affect DIO processing.
Rank: 16-bit unsigned integer indicating the DODAG rank of the node Rank: 16-bit unsigned integer indicating the DODAG rank of the node
sending the DIO message. Section 8.2 describes how Rank is set sending the DIO message. Section 8.2 describes how Rank is set
and how it affects DIO processing. and how it affects DIO processing.
RPLInstanceID: 8-bit field set by the DODAG root that indicates RPLInstanceID: 8-bit field set by the DODAG root that indicates
skipping to change at page 41, line 44 skipping to change at page 41, line 44
DAOSequence: Incremented at each DAO message from a node, and echoed DAOSequence: Incremented at each DAO message from a node, and echoed
in the DAO-ACK by the recipient. The DAOSequence is used to in the DAO-ACK by the recipient. The DAOSequence is used to
correlate a DAO message and a DAO ACK message and is not to be correlate a DAO message and a DAO ACK message and is not to be
confused with the Transit Information option Path Sequence that confused with the Transit Information option Path Sequence that
is associated to a given target Down the DODAG. is associated to a given target Down the DODAG.
Status: Indicates the completion. Status 0 is unqualified Status: Indicates the completion. Status 0 is unqualified
acceptance, 1 to 127 are unassigned and undetermined, and 128 acceptance, 1 to 127 are unassigned and undetermined, and 128
and greater are rejection codes used to indicate that the node and greater are rejection codes used to indicate that the node
should select an alternate parent. should select an alternate parent. This specification does not
define any rejection codes.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root DODAGID (optional): 128-bit unsigned integer set by a DODAG root
which uniquely identifies a DODAG. This field is only present which uniquely identifies a DODAG. This field is only present
when the 'D' flag is set. This field is typically only present when the 'D' flag is set. This field is typically only present
when a local RPLInstanceID is in use, in order to identify the when a local RPLInstanceID is in use, in order to identify the
DODAGID that is associated with the RPLInstanceID. When a DODAGID that is associated with the RPLInstanceID. When a
global RPLInstanceID is in use this field need not be present. global RPLInstanceID is in use this field need not be present.
Unassigned bits of the DAO-ACK Base are reserved. They MUST be set Unassigned bits of the DAO-ACK Base are reserved. They MUST be set
to zero on transmission and MUST be ignored on reception. to zero on transmission and MUST be ignored on reception.
skipping to change at page 44, line 49 skipping to change at page 44, line 49
messages, and its format is as follows: messages, and its format is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad 1 Option Figure 20: Format of the Pad 1 Option
The Pad1 option is used to insert one or two octets of padding into The Pad1 option is used to insert a single octet of padding into the
the message to enable options alignment. If more than one octet of message to enable options alignment. If more than one octet of
padding is required, the PadN option should be used rather than padding is required, the PadN option should be used rather than
multiple Pad1 options. multiple Pad1 options.
NOTE! the format of the Pad1 option is a special case - it has NOTE! the format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields. neither Option Length nor Option Data fields.
6.7.3. PadN 6.7.3. PadN
The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC
messages, and its format is as follows: messages, and its format is as follows:
skipping to change at page 45, line 28 skipping to change at page 45, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 21: Format of the Pad N Option Figure 21: Format of the Pad N Option
The PadN option is used to insert two or more octets of padding into The PadN option is used to insert two or more octets of padding into
the message to enable options alignment. PadN Option data MUST be the message to enable options alignment. PadN Option data MUST be
ignored by the receiver. ignored by the receiver.
Option Type: 0x01 (to be confirmed by IANA) Option Type: 0x01 (to be confirmed by IANA)
Option Length: For N (N > 1) octets of padding, the Option Length Option Length: For N octets of padding, where 2 <= N <= 7, the
field contains the value N-2. Option Length field contains the value N-2. An Option Length
of 0 indicates a total padding of 2 octets. An Option Length
of 5 indicates a total padding of 7 octets, which is the
maximum padding size allowed with the PadN option.
Option Data: For N (N > 1) octets of padding, the Option Data Option Data: For N (N > 1) octets of padding, the Option Data
consists of N-2 zero-valued octets. consists of N-2 zero-valued octets.
6.7.4. Metric Container 6.7.4. Metric Container
The Metric Container option MAY be present in DIO or DAO messages, The Metric Container option MAY be present in DIO or DAO messages,
and its format is as follows: and its format is as follows:
0 1 2 0 1 2
skipping to change at page 54, line 45 skipping to change at page 54, line 45
Figure 28: Format of the Solicited Information Option Figure 28: Format of the Solicited Information Option
The Solicited Information option is used for a node to request DIO The Solicited Information option is used for a node to request DIO
messages from a subset of neighboring nodes. The Solicited messages from a subset of neighboring nodes. The Solicited
Information option may specify a number of predicate criteria to be Information option may specify a number of predicate criteria to be
matched by a receiving node. This is used by the requester to limit matched by a receiving node. This is used by the requester to limit
the number of replies from "non-interesting" nodes. These predicates the number of replies from "non-interesting" nodes. These predicates
affect whether a node resets its DIO trickle timer, as described in affect whether a node resets its DIO trickle timer, as described in
Section 8.3. Section 8.3.
The Solicited Information option contains flags that indicate which
predicates a node should check when deciding whether to reset its
Trickle timer. A node resets its Trickle timer when all predicates
are true. If a flag is set, then the RPL node MUST check the
associated predicate. If a flag is cleared, then the RPL node MUST
NOT check the associated predicate. (If a flag is cleared, the RPL
node assumes that the associated predicate is true).
Option Type: 0x07 (to be confirmed by IANA) Option Type: 0x07 (to be confirmed by IANA)
Option Length: 19 Option Length: 19
Control Field: The control field contains flags that indicate which
predicates a node should check when deciding whether to reset
its Trickle timer. A node resets its Trickle timer when all
predicates are true. If a flag is set, then the RPL node MUST
check the associated predicate. If a flag is cleared, then the
RPL node MUST NOT check the associated predicate and assume the
predicate is true. The Solicited Information option Control
Field has three flags:
V: The V flag is the Version predicate. The Version V: The V flag is the Version predicate. The Version predicate is
predicate is true if the receiver's DODAGVersionNumber true if the receiver's DODAGVersionNumber matches the requested
matches the requested Version Number. If the V flag is Version Number. If the V flag is cleared then the Version
cleared then the Version field is not valid and the field is not valid and the Version field MUST be set to zero on
Version field MUST be set to zero on transmission and transmission and ignored upon receipt.
ignored upon receipt.
I: The I flag is the InstanceID predicate. The InstanceID I: The I flag is the InstanceID predicate. The InstanceID
predicate is true when the RPL node's current predicate is true when the RPL node's current RPLInstanceID
RPLInstanceID matches the requested RPLInstanceID. If matches the requested RPLInstanceID. If the I flag is cleared
the I flag is cleared then the RPLInstanceID field is not then the RPLInstanceID field is not valid and the RPLInstanceID
valid and the RPLInstanceID field MUST be set to zero on field MUST be set to zero on transmission and ignored upon
transmission and ignored upon receipt. receipt.
D: The D flag is the DODAGID predicate. The DODAGID D: The D flag is the DODAGID predicate. The DODAGID predicate is
predicate is true if the RPL node's parent set has the true if the RPL node's parent set has the same DODAGID as the
same DODAGID as the DODAGID field. If the D flag is DODAGID field. If the D flag is cleared then the DODAGID field
cleared then the DODAGID field is not valid and the is not valid and the DODAGID field MUST be set to zero on
DODAGID field MUST be set to zero on transmission and transmission and ignored upon receipt.
ignored upon receipt.
Flags: 5-bit unused field reserved for flags. The field MUST Flags: 5-bit unused field reserved for flags. The field MUST be
be initialized to zero by the sender and MUST be ignored initialized to zero by the sender and MUST be ignored by the
by the receiver. receiver.
Version Number: 8-bit unsigned integer containing the value of Version Number: 8-bit unsigned integer containing the value of
DODAGVersionNumber that is being solicited when valid. DODAGVersionNumber that is being solicited when valid.
RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID
that is being solicited when valid. that is being solicited when valid.
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.
skipping to change at page 68, line 21 skipping to change at page 68, line 21
announce themselves. Similarly, when a node jumps into a new DODAG announce themselves. Similarly, when a node jumps into a new DODAG
it needs to construct a new DODAG parent set for this new DODAG. it needs to construct a new DODAG parent set for this new DODAG.
If a node needs to move Down a DODAG that it is attached to, If a node needs to move Down a DODAG that it is attached to,
increasing its Rank, then it MAY poison its routes and delay before increasing its Rank, then it MAY poison its routes and delay before
moving as described in Section 8.2.2.5. moving as described in Section 8.2.2.5.
A node is allowed to join any DODAG Version that it has never been a A node is allowed to join any DODAG Version that it has never been a
prior member of without any restrictions, but if the node has been a prior member of without any restrictions, but if the node has been a
prior member of the DODAG Version then it must continue to observe prior member of the DODAG Version then it must continue to observe
the rule that it may not advertise an effective rank higher than the rule that it may not advertise a rank higher than
L+DAGMaxRankIncrease at any point in the life of the DODAG Version. L+DAGMaxRankIncrease at any point in the life of the DODAG Version.
This rule must be observed so as not to create a loophole that would This rule must be observed so as not to create a loophole that would
allow the node to effectively increment its rank all the way to allow the node to effectively increment its rank all the way to
INFINITE_RANK, which may have impact on other nodes and create a INFINITE_RANK, which may have impact on other nodes and create a
resource-wasting count-to-infinity scenario. resource-wasting count-to-infinity scenario.
8.2.2.5. Poisoning 8.2.2.5. Poisoning
1. A node poisons routes by advertising a Rank of INFINITE_RANK. 1. A node poisons routes by advertising a Rank of INFINITE_RANK.
skipping to change at page 74, line 23 skipping to change at page 74, line 23
1. All nodes who join a DODAG MUST abide by the MOP setting from the 1. All nodes who join a DODAG MUST abide by the MOP setting from the
root. Nodes that do not have the capability to fully participate root. Nodes that do not have the capability to fully participate
as a router, e.g. that does not match the advertised MOP, MAY as a router, e.g. that does not match the advertised MOP, MAY
join the DODAG as a leaf. join the DODAG as a leaf.
2. If the MOP is 0, indicating no downward routing, nodes MUST NOT 2. If the MOP is 0, indicating no downward routing, nodes MUST NOT
transmit DAO messages, and MAY ignore DAO messages. transmit DAO messages, and MAY ignore DAO messages.
3. In non-storing mode, the DODAG Root SHOULD store source routing 3. In non-storing mode, the DODAG Root SHOULD store source routing
table entries for destinations learned from DAOs. table entries for destinations learned from DAOs. If the Root
fails to store some information, then some destination may be
unreachable.
4. In storing mode, all non-root, non-leaf nodes MUST store routing 4. In storing mode, all non-root, non-leaf nodes MUST store routing
table entries for destinations learned from DAOs. table entries for destinations learned from DAOs.
A DODAG can have one of several possible modes of operation, as A DODAG can have one of several possible modes of operation, as
defined by the MOP field. Either it does not support downward defined by the MOP field. Either it does not support downward
routes, it supports downward routes through source routing from DODAG routes, it supports downward routes through source routing from DODAG
Roots, or it supports downward routes through in-network routing Roots, or it supports downward routes through in-network routing
tables. tables.
skipping to change at page 79, line 38 skipping to change at page 79, line 38
In non-storing mode, RPL routes messages downward using IP source In non-storing mode, RPL routes messages downward using IP source
routing. The following rule applies to nodes that are in non-storing routing. The following rule applies to nodes that are in non-storing
mode. Storing mode has a separate set of rules, described in mode. Storing mode has a separate set of rules, described in
Section 9.8. Section 9.8.
1. The Parent Address field of a Transit Information Option MUST 1. The Parent Address field of a Transit Information Option MUST
contain one or more addresses. All of these addresses MUST be contain one or more addresses. All of these addresses MUST be
addresses of DAO parents of the sender. addresses of DAO parents of the sender.
2. On receiving a unicast DAO, a node MUST propagate the updated 2. DAOs are sent directly to the root along a default route
downward route information upwards. The node MAY use any parent installed as part of the parent selection.
in the parent set. The downward route information in the DAO
message MAY be aggregated with other DAOs before being propagated
upwards, which MAY entail to delay the propagation as described
below.
3. When a node removes a node from its DAO parent set, it MAY 3. When a node removes a node from its DAO parent set, it MAY
generate a new DAO message with an updated Transit Information generate a new DAO message with an updated Transit Information
option. option.
In non-storing mode, a node uses DAOs to report its DAO parents to In non-storing mode, a node uses DAOs to report its DAO parents to
the DODAG Root. The DODAG Root can piece together a downward route the DODAG Root. The DODAG Root can piece together a downward route
to a node by using DAO parent sets from each node in the route. The to a node by using DAO parent sets from each node in the route. The
Path Sequence information may be used to detect stale DAO Path Sequence information may be used to detect stale DAO
information. The purpose of this per-hop route calculation is to information. The purpose of this per-hop route calculation is to
skipping to change at page 81, line 14 skipping to change at page 81, line 10
it has received to produce a set of RPL Target options and their it has received to produce a set of RPL Target options and their
associated Transmit Information options. associated Transmit Information options.
Because this information is stored within each node's routing tables, Because this information is stored within each node's routing tables,
in storing mode DAOs are communicated directly to DAO parents, who in storing mode DAOs are communicated directly to DAO parents, who
store this information. store this information.
9.9. Path Control 9.9. Path Control
A DAO message from a node contains one or more Target Options. Each A DAO message from a node contains one or more Target Options. Each
Target Option specifies either the node's prefix, a prefix of Target Option specifies either a prefix advertised by the node, a
addresses reachable outside the LLN, or a destination in the node's prefix of addresses reachable outside the LLN, the address of
sub-DODAG. The Path Control field of the Transit Information option destination in the node's sub-DODAG, or a multicast group that a node
allows nodes to request or allow for multiple downward routes. A in the sub-DODAG is listening to. The Path Control field of the
node constructs the Path Control field of a Transit Information Transit Information option allows nodes to request or allow for
option as follows: multiple downward routes. A node constructs the Path Control field
of a Transit Information option as follows:
1. The bit width of the path control field MUST be equal to the 1. The bit width of the path control field MUST be equal to the
value (PCS + 1), where PCS is specified in the control field of value (PCS + 1), where PCS is specified in the control field of
the DODAG Configuration Option. Bits greater than or equal to the DODAG Configuration Option. Bits greater than or equal to
the value (PCS + 1) MUST be cleared on transmission and MUST be the value (PCS + 1) MUST be cleared on transmission and MUST be
ignored on reception. Bits below that value are considered ignored on reception. Bits below that value are considered
"active" bits. "active" bits.
2. The node MUST logically construct groupings of its DAO parents 2. The node MUST logically construct groupings of its DAO parents
while populating the Path Control field, where each group while populating the Path Control field, where each group
skipping to change at page 90, line 25 skipping to change at page 90, line 25
10.7. Reception of Incoming Packets 10.7. Reception of Incoming Packets
This section describes the reception and processing of a secured RPL This section describes the reception and processing of a secured RPL
packet. Given an incoming secured RPL packet, where the Security packet. Given an incoming secured RPL packet, where the Security
subfield bit of the RPL message Code field is set, this section subfield bit of the RPL message Code field is set, this section
describes how RPL generates an unencrypted variant of the packet and describes how RPL generates an unencrypted variant of the packet and
validates its integrity. validates its integrity.
The receiver uses the RPL security control fields to determine the The receiver uses the RPL security control fields to determine the
necessary packet security processing. If the described level of necessary packet security processing. If the described level of
security for the message type and originator does not meet locally security for the message type and originator is unknown or does not
maintained security policies, a node MAY discard the packet without meet locally maintained security policies, a node MUST discard the
further processing. These policies can include security levels, keys packet without further processing, MAY raise a management alert, and
used, source identifiers, or the lack of timestamp-based counters (as MUST NOT send any messages in response. These policies can include
indicated by the 'T' flag). The configuration of the security policy security levels, keys used, source identifiers, or the lack of
database for incoming packet processing is out of scope for this timestamp-based counters (as indicated by the 'T' flag). The
specification (it may, for example, be defined through DIO configuration of the security policy database for incoming packet
Configuration or through out-of-band administrative router processing is out of scope for this specification (it may, for
configuration). example, be defined through DIO Configuration or through out-of-band
administrative router configuration).
Where the message security level (LVL) indicates an encrypted RPL Where the message security level (LVL) indicates an encrypted RPL
message, the node uses the key information identified through the KIM message, the node uses the key information identified through the KIM
field as well as the Nonce as input to the message payload decryption field as well as the Nonce as input to the message payload decryption
processing. The Nonce shall be derived from the message Counter processing. The Nonce shall be derived from the message Counter
field and other received and locally maintained information (see field and other received and locally maintained information (see
Section 10.9.1). The plaintext message contents shall be obtained by Section 10.9.1). The plaintext message contents shall be obtained by
invoking the inverse cryptographic mode of operation specified by the invoking the inverse cryptographic mode of operation specified by the
Sec field of the received packet. Sec field of the received packet.
skipping to change at page 96, line 37 skipping to change at page 96, line 37
RPL loop avoidance mechanisms are kept simple and designed to RPL loop avoidance mechanisms are kept simple and designed to
minimize churn and states. Loops may form for a number of reasons, minimize churn and states. Loops may form for a number of reasons,
e.g. control packet loss. RPL includes a reactive loop detection e.g. control packet loss. RPL includes a reactive loop detection
technique that protects from meltdown and triggers repair of broken technique that protects from meltdown and triggers repair of broken
paths. paths.
RPL loop detection uses information that contained within the data RPL loop detection uses information that contained within the data
packet using the RPL Option [I-D.ietf-6man-rpl-option]) in an IPv6 packet using the RPL Option [I-D.ietf-6man-rpl-option]) in an IPv6
Hop-by-Hop Option header. The RPL Option contains RPL Packet Hop-by-Hop Option header. The RPL Option contains RPL Packet
Information (Figure 32) and [I-D.ietf-6man-rpl-option] defines the Information as defined below, and [I-D.ietf-6man-rpl-option] defines
details of how that RPL Packet Information is carried within the RPL the details of how that RPL Packet Information is carried within the
Option. RPL Option. Future companion specifications may detail alternate
ways to carry this information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: RPL Packet Information The content of RPL Packet Information is defined as follows:
Down 'O': 1-bit flag indicating whether the packet is expected to Down 'O': 1-bit flag indicating whether the packet is expected to
progress Up or Down. A router sets the 'O' flag when the progress Up or Down. A router sets the 'O' flag when the
packet is expected to progress Down (using DAO routes), and packet is expected to progress Down (using DAO routes), and
clears it when forwarding toward the DODAG root (to a node with clears it when forwarding toward the DODAG root (to a node with
a lower rank). A host or RPL leaf node MUST set the 'O' flag a lower rank). A host or RPL leaf node MUST set the 'O' flag
to 0. to 0.
Rank-Error 'R': 1-bit flag indicating whether a rank error was Rank-Error 'R': 1-bit flag indicating whether a rank error was
detected. A rank error is detected when there is a mismatch in detected. A rank error is detected when there is a mismatch in
skipping to change at page 97, line 46 skipping to change at page 97, line 39
11.2.2. Router Operation 11.2.2. Router Operation
11.2.2.1. Instance Forwarding 11.2.2.1. Instance Forwarding
The RPLInstanceID is associated by the source with the packet. This The RPLInstanceID is associated by the source with the packet. This
RPLInstanceID MUST match the RPL Instance onto which the packet is RPLInstanceID MUST match the RPL Instance onto which the packet is
placed by any node, be it a host or router. placed by any node, be it a host or router.
A RPL router that forwards a packet in the RPL network MUST check if A RPL router that forwards a packet in the RPL network MUST check if
the packet includes an IPv6 Hop-by-Hop RPL Option, and that the RPL the packet includes an IPv6 Hop-by-Hop RPL Option, and that the RPL
Option contains RPL Packet Information (Figure 32). If not, then the Option contains RPL Packet Information (Section 11.2). If not, then
RPL router MUST insert a RPL Option with RPL Packet Information as the RPL router MUST insert a RPL Option with RPL Packet Information
specified in [I-D.ietf-6man-rpl-option]. If the router is an ingress as specified in [I-D.ietf-6man-rpl-option]. If the router is an
router that injects the packet into the RPL network, the router MUST ingress router that injects the packet into the RPL network, the
set the RPLInstanceID field in the RPL Packet Information. The router MUST set the RPLInstanceID field in the RPL Packet
details of how that router determines the mapping to a RPLInstanceID Information. The details of how that router determines the mapping
are out of scope for this specification and left to future to a RPLInstanceID are out of scope for this specification and left
specification. to future specification.
A router that forwards a packet to outside the RPL network MUST A router that forwards a packet to outside the RPL network MUST
remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. remove the RPL Option as specified in [I-D.ietf-6man-rpl-option].
When a router receives a packet that specifies a given RPLInstanceID When a router receives a packet that specifies a given RPLInstanceID
and the node can forward the packet along the DODAG associated to and the node can forward the packet along the DODAG associated to
that instance, then the router MUST do so and leave the RPLInstanceID that instance, then the router MUST do so and leave the RPLInstanceID
value unchanged. value unchanged.
If any node can not forward a packet along the DODAG associated to If any node can not forward a packet along the DODAG associated to
skipping to change at page 102, line 24 skipping to change at page 102, line 24
or other protocols such as BFD ([RFC5880]) and MANET Neighborhood or other protocols such as BFD ([RFC5880]) and MANET Neighborhood
Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]). Unfortunately, such Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]). Unfortunately, such
an approach is not desirable in constrained environments such as LLN an approach is not desirable in constrained environments such as LLN
and would lead to excessive control traffic in light of the data and would lead to excessive control traffic in light of the data
traffic with a negative impact on both link loads and nodes traffic with a negative impact on both link loads and nodes
resources. Overhead to maintain the routing adjacency should be resources. Overhead to maintain the routing adjacency should be
minimized. Furthermore, it is not always possible to rely on the minimized. Furthermore, it is not always possible to rely on the
link or transport layer to provide information of the associated link link or transport layer to provide information of the associated link
state. The network layer needs to fall back on its own mechanism. state. The network layer needs to fall back on its own mechanism.
Thus RPL makes use of a different approach consisting of probing the By contrast with several other routing protocols, RPL does not define
neighbor using a Neighbor Solicitation message (see [RFC4861]). The any 'keep-alive' mechanisms to detect routing adjacency failure: this
reception of a Neighbor Advertisement (NA) message with the is in most cases, because such a mechanism may be too expensive in
"Solicited Flag" set is used to verify the validity of the routing terms of bandwidth and even more importantly energy (a battery
adjacency. Such mechanism MAY be used prior to sending a data operated device could not afford to send periodic Keep alive). Still
packet. This allows for detecting whether or not the routing RPL requires mechanisms to detect that a neighbor is no longer
adjacency is still valid, and should it not be the case, select reachable: this can be performed by using mechanisms such as Neighbor
another feasible successor to forward the packet. Under specific Unreachability Detection as defined in [RFC4861] or even some form of
circumstances and according to the network resources, a RPL Keep-alive that are outside of this document.
implementation MAY decide to augment this mechanism with Keep-Alive
messages.
14. Guidelines for Objective Functions 14. Guidelines for Objective Functions
An Objective Function (OF), in conjunction with routing metrics and An Objective Function (OF), in conjunction with routing metrics and
constraints, allows for the selection of a DODAG to join, and a constraints, allows for the selection of a DODAG to join, and a
number of peers in that DODAG as parents. The OF is used to compute number of peers in that DODAG as parents. The OF is used to compute
an ordered list of parents. The OF is also responsible to compute an ordered list of parents. The OF is also responsible to compute
the rank of the device within the DODAG Version. the rank of the device within the DODAG Version.
The Objective Function is indicated in the DIO message using an The Objective Function is indicated in the DIO message using an
skipping to change at page 119, line 49 skipping to change at page 119, line 49
preference for the routing protocol from which the route was learned. preference for the routing protocol from which the route was learned.
Internal Data Structures: some RPL implementations may limit the size Internal Data Structures: some RPL implementations may limit the size
of the candidate neighbor list in order to bound the memory usage, in of the candidate neighbor list in order to bound the memory usage, in
which case some otherwise viable candidate neighbors may not be which case some otherwise viable candidate neighbors may not be
considered and simply dropped from the candidate neighbor list. considered and simply dropped from the candidate neighbor list.
A RPL implementation MAY provide an indicator on the size of the A RPL implementation MAY provide an indicator on the size of the
candidate neighbor list. candidate neighbor list.
17.7. Liveness Detection and Monitoring 17.7. Fault Isolation
By contrast with several other routing protocols, RPL does not define
any 'keep-alive' mechanisms to detect routing adjacency failure: this
is in most cases, because such a mechanism may be too expensive in
terms of bandwidth and even more importantly energy (a battery
operated device could not afford to send periodic Keep alive). Still
RPL requires mechanisms to detect that a neighbor is no longer
reachable: this can be performed by using mechanisms such as NUD
(Neighbor Unreachability Detection) or even some form of Keep-alive
that are outside of this document.
17.8. Fault Isolation
It is RECOMMENDED to quarantine neighbors that start emitting It is RECOMMENDED to quarantine neighbors that start emitting
malformed messages at unacceptable rates. malformed messages at unacceptable rates.
17.9. Impact on Other Protocols 17.8. Impact on Other Protocols
RPL has very limited impact on other protocols. Where more than one RPL has very limited impact on other protocols. Where more than one
routing protocol is required on a router such as a LBR, it is routing protocol is required on a router such as a LBR, it is
expected for the device to support routing redistribution functions expected for the device to support routing redistribution functions
between the routing protocols to allow for reachability between the between the routing protocols to allow for reachability between the
two routing domains. Such redistribution SHOULD be governed by the two routing domains. Such redistribution SHOULD be governed by the
use of user configurable policy. use of user configurable policy.
With regards to the impact in terms of traffic on the network, RPL With regards to the impact in terms of traffic on the network, RPL
has been designed to limit the control traffic thanks to mechanisms has been designed to limit the control traffic thanks to mechanisms
such as Trickle timers (Section 8.3). Thus the impact of RPL on such as Trickle timers (Section 8.3). Thus the impact of RPL on
other protocols should be extremely limited. other protocols should be extremely limited.
17.10. Performance Management 17.9. Performance Management
Performance management is always an important aspect of a protocol Performance management is always an important aspect of a protocol
and RPL is not an exception. Several metrics of interest have been and RPL is not an exception. Several metrics of interest have been
specified by the IP Performance Monitoring (IPPM) Working Group: that specified by the IP Performance Monitoring (IPPM) Working Group: that
being said, they will be hardly applicable to LLN considering the being said, they will be hardly applicable to LLN considering the
cost of monitoring these metrics in terms of resources on the devices cost of monitoring these metrics in terms of resources on the devices
and required bandwidth. Still, RPL implementation MAY support some and required bandwidth. Still, RPL implementation MAY support some
of these, and other parameters of interest are listed below: of these, and other parameters of interest are listed below:
o Number of repairs and time to repair in seconds (average, o Number of repairs and time to repair in seconds (average,
skipping to change at page 121, line 7 skipping to change at page 120, line 41
o Number of times and duration during which a devices could not o Number of times and duration during which a devices could not
forward a packet because of a lack of reachable neighbor in its forward a packet because of a lack of reachable neighbor in its
routing table routing table
o Monitoring of resources consumption by RPL in terms of bandwidth o Monitoring of resources consumption by RPL in terms of bandwidth
and required memory and required memory
o Number of RPL control messages sent and received o Number of RPL control messages sent and received
17.11. Diagnostics 17.10. Diagnostics
There may be situations where a node should be placed in "verbose" There may be situations where a node should be placed in "verbose"
mode to improve diagnostics. Thus a RPL implementation SHOULD mode to improve diagnostics. Thus a RPL implementation SHOULD
provide the ability to place a node in and out of verbose mode in provide the ability to place a node in and out of verbose mode in
order to get additional diagnostic information. order to get additional diagnostic information.
18. Security Considerations 18. Security Considerations
18.1. Overview 18.1. Overview
skipping to change at page 124, line 31 skipping to change at page 123, line 31
New codes may be allocated only by an IETF Review. Each code should New codes may be allocated only by an IETF Review. Each code should
be tracked with the following qualities: be tracked with the following qualities:
o Code o Code
o Description o Description
o Defining RFC o Defining RFC
Three codes are currently defined: The following codes are currently defined:
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| 0x00 | DODAG Information Solicitation | This | | 0x00 | DODAG Information Solicitation | This |
| | | document | | | | document |
| | | | | | | |
| 0x01 | DODAG Information Object | This | | 0x01 | DODAG Information Object | This |
| | | document | | | | document |
| | | | | | | |
skipping to change at page 125, line 9 skipping to change at page 124, line 9
| 0x80 | Secure DODAG Information Solicitation | This | | 0x80 | Secure DODAG Information Solicitation | This |
| | | document | | | | document |
| | | | | | | |
| 0x81 | Secure DODAG Information Object | This | | 0x81 | Secure DODAG Information Object | This |
| | | document | | | | document |
| 0x82 | Secure Destination Advertisement Object | This | | 0x82 | Secure Destination Advertisement Object | This |
| | | document | | | | document |
| | | | | | | |
| 0x83 | Secure Destination Advertisement Object | This | | 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document | | | Acknowledgment | document |
| | | |
| 0x8A | Consistency Check | This |
| | | document |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
RPL Control Codes RPL Control Codes
19.3. New Registry for the Mode of Operation (MOP) DIO Control Field 19.3. New Registry for the Mode of Operation (MOP)
IANA is requested to create a registry for the 3-bit Mode of IANA is requested to create a registry for the 3-bit Mode of
Operation (MOP) DIO Control Field, which is contained in the DIO Operation (MOP), which is contained in the DIO Base.
Base.
New values may be allocated only by an IETF Review. Each value New values may be allocated only by an IETF Review. Each value
should be tracked with the following qualities: should be tracked with the following qualities:
o Mode of Operation Value o Mode of Operation Value
o Capability description o Capability description
o Defining RFC o Defining RFC
skipping to change at page 137, line 12 skipping to change at page 136, line 12
Email: stevedh@cs.berkeley.edu Email: stevedh@cs.berkeley.edu
22. References 22. References
22.1. Normative References 22.1. Normative References
[I-D.ietf-6man-rpl-option] [I-D.ietf-6man-rpl-option]
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
Information in Data-Plane Datagrams", Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-00 (work in progress), draft-ietf-6man-rpl-option-01 (work in progress),
July 2010. October 2010.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-00 (work in progress), draft-ietf-6man-rpl-routing-header-01 (work in progress),
July 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., Networks, D., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-10 (work in progress), draft-ietf-roll-routing-metrics-11 (work in progress),
October 2010. October 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-04 (work
in progress), August 2010. in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 60 change blocks. 
239 lines changed or deleted 234 lines changed or added

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