draft-ietf-roll-rpl-17.txt   draft-ietf-roll-rpl-18.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: June 18, 2011 Cisco Systems Expires: August 8, 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
December 15, 2010 February 4, 2011
RPL: IPv6 Routing Protocol for Low power and Lossy Networks RPL: IPv6 Routing Protocol for Low power and Lossy Networks
draft-ietf-roll-rpl-17 draft-ietf-roll-rpl-18
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 June 18, 2011. This Internet-Draft will expire on August 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 17 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 17
3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 17 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 17
3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 18 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 18
3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 18 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 18
3.2.6. Administrative Preference . . . . . . . . . . . . . . 19 3.2.6. Administrative Preference . . . . . . . . . . . . . . 19
3.2.7. Datapath Validation and Loop Detection . . . . . . . 19 3.2.7. Datapath Validation and Loop Detection . . . . . . . 19
3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 19 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 19
3.3. Downward Routes and Destination Advertisement . . . . . 20 3.3. Downward Routes and Destination Advertisement . . . . . 20
3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 20 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 20
3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 20 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 21
3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 21 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 22
3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 22 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 23
3.6. Routing Metrics and Constraints Used By RPL . . . . . . 23 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 23
3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 24 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 24
3.7.1. Greediness and Instability . . . . . . . . . . . . . 24 3.7.1. Greediness and Instability . . . . . . . . . . . . . 25
3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 26 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 27
3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 27 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 27
4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 28 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 28
4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 28 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 28
4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 28 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 28
4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 28 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 28
5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 29 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 29 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 29
6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 31 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 31
6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 33 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 33
6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 38 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 38
skipping to change at page 4, line 47 skipping to change at page 4, line 47
8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 74 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 74
8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 75 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 75
8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 76 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 76
9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 77 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 77
9.1. Destination Advertisement Parents . . . . . . . . . . . 77 9.1. Destination Advertisement Parents . . . . . . . . . . . 77
9.2. Downward Route Discovery and Maintenance . . . . . . . . 78 9.2. Downward Route Discovery and Maintenance . . . . . . . . 78
9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 79 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 79
9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 79 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 79
9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 80 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 80
9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 80 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 80
9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 82 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 83
9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 83 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 83
9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 84 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 84
9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 85 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 85
9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 85 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 86
9.9.1. Path Control Example . . . . . . . . . . . . . . . . 87 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 87
9.10. Multicast Destination Advertisement Messages . . . . . . 89 9.10. Multicast Destination Advertisement Messages . . . . . . 89
10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 90 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 90
10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90
10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91
10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92
10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92
10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93
10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94
10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95
skipping to change at page 6, line 45 skipping to change at page 6, line 45
19.17. New Registry for the Solicited Information Option 19.17. New Registry for the Solicited Information Option
Flags . . . . . . . . . . . . . . . . . . . . . . . . . 137 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 137
19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 138 19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 138
19.19. Link-Local Scope multicast address . . . . . . . . . . . 138 19.19. Link-Local Scope multicast address . . . . . . . . . . . 138
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 140 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 140
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 141 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 141
22.1. Normative References . . . . . . . . . . . . . . . . . . 141 22.1. Normative References . . . . . . . . . . . . . . . . . . 141
22.2. Informative References . . . . . . . . . . . . . . . . . 142 22.2. Informative References . . . . . . . . . . . . . . . . . 142
Appendix A. Example Operation . . . . . . . . . . . . . . . . . 145 Appendix A. Example Operation . . . . . . . . . . . . . . . . . 145
A.1. Example with External Prefixes . . . . . . . . . . . . . 145 A.1. Example Operation in Storing Mode With Node-owned
A.2. Example Operation in Storing Mode With Node-owned Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 145
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 147 A.1.1. DIO messages and PIO . . . . . . . . . . . . . . . . 146
A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 148 A.1.2. DAO messages . . . . . . . . . . . . . . . . . . . . 147
A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 148 A.1.3. Routing Information Base . . . . . . . . . . . . . . 147
A.2.3. Routing Information Base . . . . . . . . . . . . . . 149 A.2. Example Operation in Storing Mode With Subnet-wide
A.3. Example Operation in Storing Mode With Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 148
Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 149
A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 150 A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 149
A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 151 A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 150
A.3.3. Routing Information Base . . . . . . . . . . . . . . 151 A.2.3. Routing Information Base . . . . . . . . . . . . . . 150
A.4. Example Operation in Non-Storing Mode With Node-owned A.3. Example Operation in Non-Storing Mode With Node-owned
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 152 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 151
A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 153 A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 152
A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 153 A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 152
A.4.3. Routing Information Base . . . . . . . . . . . . . . 154 A.3.3. Routing Information Base . . . . . . . . . . . . . . 153
A.5. Example Operation in Non-Storing Mode With A.4. Example Operation in Non-Storing Mode With
Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 154 Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 153
A.5.1. DIO messages and PIO . . . . . . . . . . . . . . . . 155 A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 154
A.5.2. DAO messages . . . . . . . . . . . . . . . . . . . . 156 A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 155
A.5.3. Routing Information Base . . . . . . . . . . . . . . 156 A.4.3. Routing Information Base . . . . . . . . . . . . . . 155
A.5. Example with External Prefixes . . . . . . . . . . . . . 156
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158 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
skipping to change at page 20, line 31 skipping to change at page 20, line 31
modes of downward traffic: storing (fully stateful) or non-storing modes of downward traffic: storing (fully stateful) or non-storing
(fully source routed). Any given RPL Instance is either storing or (fully source routed). Any given RPL Instance is either storing or
non-storing. In both cases, P2P packets travel Up toward a DODAG non-storing. In both cases, P2P packets travel Up toward a DODAG
Root then Down to the final destination (unless the destination is on Root then Down to the final destination (unless the destination is on
the upward route). In the non-storing case the packet will travel the upward route). In the non-storing case the packet will travel
all the way to a DODAG root before traveling Down. In the storing all the way to a DODAG root before traveling Down. In the storing
case the packet may be directed Down towards the destination by a case the packet may be directed Down towards the destination by a
common ancestor of the source and the destination prior to reaching a common ancestor of the source and the destination prior to reaching a
DODAG Root. DODAG Root.
As of this specification no implementation is expected to support
both storing and non-storing modes of operation. Most
implementations are expected to support either no downward routes,
non-storing mode only, or storing mode only. Other modes of
operation, such as a hybrid mix of storing and non-storing mode, are
out of scope for this specification and may be described in other
companion specifications.
This specification describes a basic mode of operation in support of This specification describes a basic mode of operation in support of
P2P traffic. Note that more optimized P2P solutions may be described P2P traffic. Note that more optimized P2P solutions may be described
in companion specifications. in companion specifications.
3.4. Local DODAGs Route Discovery 3.4. Local DODAGs Route Discovery
A RPL network can optionally support on-demand discovery of DODAGs to A RPL network can optionally support on-demand discovery of DODAGs to
specific destinations within an LLN. Such local DODAGs behave specific destinations within an LLN. Such local DODAGs behave
slightly differently than global DODAGs: they are uniquely defined by slightly differently than global DODAGs: they are uniquely defined by
the combination of DODAGID and RPLInstanceID. The RPLInstanceID the combination of DODAGID and RPLInstanceID. The RPLInstanceID
skipping to change at page 42, line 34 skipping to change at page 42, line 34
RPLInstanceID: 8-bit field indicating the topology instance RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
K: The 'K' flag indicates that the recipient is expected to send a K: The 'K' flag indicates that the recipient is expected to send a
DAO-ACK back. (See Section 9.3 DAO-ACK back. (See Section 9.3
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
Flags: 6-bit unused field reserved for flags. The field MUST be Flags: The 6-bits remaining unused in the Flags field are reserved
initialized to zero by the sender and MUST be ignored by the for flags. The field MUST be initialized to zero by the sender
receiver. and MUST be ignored by the receiver.
Reserved: 8-bit unused field. The field MUST be initialized to zero Reserved: 8-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.
DAOSequence: Incremented at each unique DAO message from a node and DAOSequence: Incremented at each unique DAO message from a node and
echoed in the DAO-ACK message. echoed in the DAO-ACK message.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root DODAGID (optional): 128-bit unsigned integer set by a DODAG root
which uniquely identifies a DODAG. This field is only present which uniquely identifies a DODAG. This field is only present
when the 'D' flag is set. This field is typically only present when the 'D' flag is set. This field is typically only present
skipping to change at page 44, line 31 skipping to change at page 44, line 31
below. below.
Figure 17: The DAO ACK Base Object Figure 17: The DAO ACK Base Object
RPLInstanceID: 8-bit field indicating the topology instance RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
would typically only be set when a local RPLInstanceID is used. would typically only be set when a local RPLInstanceID is used.
Flags: 7-bit unused field reserved for flags. The field MUST be Flags: The 7-bits remaining unused in the Flags field are reserved
initialized to zero by the sender and MUST be ignored by the for flags. The field MUST be initialized to zero by the sender
receiver. and MUST be ignored by the receiver.
DAOSequence: Incremented at each DAO message from a node, and echoed DAOSequence: Incremented at each DAO message from a node, and echoed
in the DAO-ACK by the recipient. The DAOSequence is used to in the DAO-ACK by the recipient. The DAOSequence is used to
correlate a DAO message and a DAO ACK message and is not to be correlate a DAO message and a DAO ACK message and is not to be
confused with the Transit Information option Path Sequence that confused with the Transit Information option Path Sequence that
is associated to a given target Down the DODAG. is associated to a given target Down the DODAG.
Status: Indicates the completion. Status 0 is unqualified Status: Indicates the completion. Status 0 is unqualified
acceptance, 1 to 127 are 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. This specification does not should select an alternate parent. No rejection codes are
define any rejection codes. defined in this specification. Rejection codes are to be
elaborated in future specifications.
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 46, line 12 skipping to change at page 46, line 12
Figure 18: The CC Base Object Figure 18: The CC Base Object
RPLInstanceID: 8-bit field indicating the topology instance RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
R: The 'R' flag indicates whether the CC message is a response. A R: The 'R' flag indicates whether the CC message is a response. A
message with the 'R' flag cleared is a request; a message with message with the 'R' flag cleared is a request; a message with
the 'R' flag set is a response. the 'R' flag set is a response.
Flags: 7-bit unused field reserved for flags. The field MUST be Flags: The 7-bits remaining unused in the Flags field are reserved
initialized to zero by the sender and MUST be ignored by the for flags. The field MUST be initialized to zero by the sender
receiver. and MUST be ignored by the receiver.
CC Nonce: 16-bit unsigned integer set by a CC request. The CC Nonce: 16-bit unsigned integer set by a CC request. The
corresponding CC response includes the same CC nonce value as corresponding CC response includes the same CC nonce value as
the request. the request.
Destination Counter: 32-bit unsigned integer value indicating the Destination Counter: 32-bit unsigned integer value indicating the
sender's estimate of the destination's current security Counter sender's estimate of the destination's current security Counter
value. If the sender does not have an estimate, it SHOULD set value. If the sender does not have an estimate, it SHOULD set
the Destination Counter field to zero. the Destination Counter field to zero.
skipping to change at page 52, line 12 skipping to change at page 52, line 12
Nodes other than the DODAG Root MUST NOT modify this information when Nodes other than the DODAG Root MUST NOT modify this information when
propagating the DODAG Configuration option. This option MAY be propagating the DODAG Configuration option. This option MAY be
included occasionally by the DODAG Root (as determined by the DODAG included occasionally by the DODAG Root (as determined by the DODAG
Root), and MUST be included in response to a unicast request, e.g. a Root), and MUST be included in response to a unicast request, e.g. a
unicast DODAG Information Solicitation (DIS) message. unicast DODAG Information Solicitation (DIS) message.
Option Type: 0x04 (to be confirmed by IANA) Option Type: 0x04 (to be confirmed by IANA)
Option Length: 14 Option Length: 14
Flags: 4-bit unused field reserved for flags. The field MUST be Flags: The 4-bits remaining unused in the Flags field are reserved
initialized to zero by the sender and MUST be ignored by the for flags. The field MUST be initialized to zero by the sender
receiver. and MUST be ignored by the receiver.
Authentication Enabled (A): One bit flag describing the security Authentication Enabled (A): One bit flag describing the security
mode of the network. The bit describe whether a node must mode of the network. The bit describe whether a node must
authenticate with a key authority before joining the network as authenticate with a key authority before joining the network as
a router. If the DIO is not a secure DIO, the 'A' bit MUST be a router. If the DIO is not a secure DIO, the 'A' bit MUST be
zero. zero.
Path Control Size (PCS): 3-bit unsigned integer used to configure Path Control Size (PCS): 3-bit unsigned integer used to configure
the number of bits that may be allocated to the Path Control the number of bits that may be allocated to the Path Control
field (see Section 9.9). Note that when PCS is consulted to field (see Section 9.9). Note that when PCS is consulted to
skipping to change at page 56, line 18 skipping to change at page 56, line 18
is present. is present.
External (E): 1-bit flag. The 'E' flag is set to indicate that the External (E): 1-bit flag. The 'E' flag is set to indicate that the
parent router redistributes external targets into the RPL parent router redistributes external targets into the RPL
network. An external target is a target that has been learned network. An external target is a target that has been learned
through an alternate protocol. The external targets are listed through an alternate protocol. The external targets are listed
in the target options that immediately precede the Transit in the target options that immediately precede the Transit
Information option. An external target is not expected to Information option. An external target is not expected to
support RPL messages and options. support RPL messages and options.
Flags: 7-bit unused field reserved for flags. The field MUST be Flags: The 7-bits remaining unused in the Flags field are reserved
initialized to zero by the sender and MUST be ignored by the for flags. The field MUST be initialized to zero by the sender
receiver. and MUST be ignored by the 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 to 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
skipping to change at page 58, line 39 skipping to change at page 58, line 39
then the RPLInstanceID field is not valid and the RPLInstanceID then the RPLInstanceID field is not valid and the RPLInstanceID
field MUST be set to zero on transmission and ignored upon field MUST be set to zero on transmission and ignored upon
receipt. receipt.
D: The D flag is the DODAGID predicate. The DODAGID predicate is D: The D flag is the DODAGID predicate. The DODAGID predicate is
true if the RPL node's parent set has the same DODAGID as the true if the RPL node's parent set has the same DODAGID as the
DODAGID field. If the D flag is cleared then the DODAGID field DODAGID field. If the D flag is cleared then the DODAGID field
is not valid and the DODAGID field MUST be set to zero on is not valid and the DODAGID field MUST be set to zero on
transmission and ignored upon receipt. transmission and ignored upon receipt.
Flags: 5-bit unused field reserved for flags. The field MUST be Flags: The 5-bits remaining unused in the Flags field are reserved
initialized to zero by the sender and MUST be ignored by the for flags. The field MUST be initialized to zero by the sender
receiver. and MUST be ignored by the 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 59, line 23 skipping to change at page 59, line 23
The Prefix Information option MAY be present in DIO messages, and The Prefix Information option MAY be present in DIO messages, and
carries the information that is specified for the IPv6 ND Prefix carries the information that is specified for the IPv6 ND Prefix
Information Option in [RFC4861], [RFC4862] and [RFC3775] for use by Information Option in [RFC4861], [RFC4862] and [RFC3775] for use by
RPL nodes and IPv6 hosts. In particular, a RPL node may use this RPL nodes and IPv6 hosts. In particular, a RPL node may use this
option for the purpose of State-Less Address Auto-Configuration option for the purpose of State-Less Address Auto-Configuration
(SLAAC) from a prefix advertised by a parent as specified in (SLAAC) from a prefix advertised by a parent as specified in
[RFC4862], and advertise its own address as specified in [RFC3775]. [RFC4862], and advertise its own address as specified in [RFC3775].
The root of a DODAG is authoritative for setting that information. The root of a DODAG is authoritative for setting that information.
The information is propagated down the DODAG unchanged, with the The information is propagated down the DODAG unchanged, with the
exception that a RPL router may update (extend) the prefix by exception that a RPL router may overwrite the Interface ID if the 'R'
appending it's own suffix. The format of the option is modified flag is set to indicate its full address in the PIO The format of the
(Type, Length, Prefix) in order to be carried as a RPL option as option is modified (Type, Length, Prefix) in order to be carried as a
follows: 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 78, line 23 skipping to change at page 78, 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. If the Root table entries for destinations learned from DAOs
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.
When downward routes are supported through source routing from DODAG
Roots, it is generally expected that the DODAG Root has stored the
source routing information learned from DAOs in order to construct
the source routes. If the DODAG Root fails to store some
information, then some destinations may be unreachable. A particular
implementation may choose to discard the source routing information
in some cases as required by implementation specific constraints. In
that case it is necessary for the implementation to accommodate an
appropriate behavior if it does not store all of the source routing
information, for example a policy of storing DAOs for the 'most
recently used' routes.
When downward routes are supported through in-network routing tables, When downward routes are supported through in-network routing tables,
the multicast operation defined in this specification may or may not the multicast operation defined in this specification may or may not
be supported, also as indicated by the MOP field. be supported, also as indicated by the MOP field.
When downward routes are supported through in-network routing tables When downward routes are supported through in-network routing tables
as described in this specification, it is expected that nodes acting as described in this specification, it is expected that nodes acting
as routers have been provisioned sufficiently to hold the required as routers have been provisioned sufficiently to hold the required
routing table state. If a node acting as a router is unable to hold routing table state. If a node acting as a router is unable to hold
the full routing table state then the routing state is not complete, the full routing table state then the routing state is not complete,
messages may be dropped as a consequence, and a fault may be logged messages may be dropped as a consequence, and a fault may be logged
skipping to change at page 82, line 9 skipping to change at page 82, line 17
1. The address of a parent used in the transit option MUST be taken 1. The address of a parent used in the transit option MUST be taken
from a PIO from that parent with the 'R' flag set. The 'R' flag from a PIO from that parent with the 'R' flag set. The 'R' flag
in a PIO indicates that the prefix field actually contains the in a PIO indicates that the prefix field actually contains the
full parent address but the child SHOULD NOT assume that the full parent address but the child SHOULD NOT assume that the
parent address is onlink. parent address is onlink.
2. A PIO with a 'A' flag set indicates that the RPL child node may 2. A PIO with a 'A' flag set indicates that the RPL child node may
use the prefix to autoconfigure an address. A parent that use the prefix to autoconfigure an address. A parent that
advertises a prefix in a PIO with the 'A' flag set MUST ensure 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 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 the root by advertising it as a DAO target. If the parent also
also the 'L' flag indicating that the prefix is onlink, then it sets the 'L' flag indicating that the prefix is onlink, then it
MUST advertise the whole prefix as target in a DAO message. MUST advertise the whole prefix as target in a DAO message. If
the 'L' flag is cleared, indicating a subnet operation, and the
'R' flag is set, indicating that the parent provides its own
address in the PIO, then the parent MUST advertise that address
as a DAO target.
3. An address that is advertised as target in a DAO message MUST be 3. An address that is advertised as target in a DAO message MUST be
collocated in the same router or reachable onlink by the router collocated in the same router or reachable onlink by the router
that owns the address that is indicated in the associated transit that owns the address that is indicated in the associated transit
information. information.
4. In order to enable an optimum compression of the routing header, 4. In order to enable an optimum compression of the routing header,
the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag
set and the 'L' flag cleared, and the child SHOULD prefer to use set and the 'L' flag cleared, and the child SHOULD prefer to use
as transit the address of the parent that is found in the PIO as transit the address of the parent that is found in the PIO
skipping to change at page 105, line 7 skipping to change at page 105, line 7
neighbor, clear the Forwarding-Error bit and attempt to send the neighbor, clear the Forwarding-Error bit and attempt to send the
packet again. The packet may be sent to an alternate neighbor, after packet again. The packet may be sent to an alternate neighbor, after
the expiration of a user-configurable implementation specific timer. the expiration of a user-configurable implementation specific timer.
If that alternate neighbor still has an inconsistent DAO state via If that alternate neighbor still has an inconsistent DAO state via
this node, the process will recurse, this node will set the this node, the process will recurse, this node will set the
Forwarding-Error 'F' bit and the routing state in the alternate Forwarding-Error 'F' bit and the routing state in the alternate
neighbor will be cleaned up as well. neighbor will be cleaned up as well.
12. Multicast Operation 12. Multicast Operation
This section describes further the multicast routing operations over This section describes further a multicast routing operation over an
an IPv6 RPL network, and specifically how unicast DAOs can be used to IPv6 RPL network, and specifically how unicast DAOs can be used to
relay group registrations up. Wherever the following text mentions relay group registrations up. The same DODAG construct can used to
Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or forward unicast and multicast traffic. The registration uses DAO
MLDv2 ([RFC3810]). messages that are identical to unicast except for the type of address
that is transported. The main difference is that the multicast
RPL provides a trivial mapping between MLD queries and RPL DAOs by traffic going down is copied to all the children that have registered
transporting a multicast group in a DAO target option. The mapping to the multicast group whereas unicast traffic is passed to one child
excludes the support of source specific filters that are not defined only.
in DAO options. The mapping enables to proxy a multicast
registration from a non-RPL node attached to a RPL router up to the
root of the DODAG, which can act as a multicast router as if the
listeners were directly attached to it.
Nodes that support the RPL storing mode of operation SHOULD also Nodes that support the RPL storing mode of operation SHOULD also
support multicast DAO operations as described below. Nodes that only support multicast DAO operations as described below. Nodes that only
support the non-storing mode of operation are not expected to support support the non-storing mode of operation are not expected to support
this section. this section.
The multicast operation is controlled by the MOP field in the DIO. The multicast operation is controlled by the MOP field in the DIO.
If the MOP field requires multicast support, then a node that o If the MOP field requires multicast support, then a node that
joins the RPL network as a router must operate as described in joins the RPL network as a router must operate as described in
this section for multicast signaling and forwarding within the RPL this section for multicast signaling and forwarding within the RPL
network. A node that does not support the multicast operation network. A node that does not support the multicast operation
required by the MOP field can only join as a leaf. required by the MOP field can only join as a leaf.
If the MOP field does not require multicast support, then o If the MOP field does not require multicast support, then
multicast is handled by some other way that is out of scope for multicast is handled by some other way that is out of scope for
this specification. (Examples may include a series of unicast this specification. (Examples may include a series of unicast
copies or limited-scope flooding). copies or limited-scope flooding).
As is traditional, a listener that is not a RPL node uses a protocol
such as MLD with a router to register to a multicast group. If the
listener is attached to a RPL router and multicast support is
enabled, then the RPL router maps the MLD query into a RPL DAO
message. A listener that is a RPL node uses a listener registration
DAO message right away.
Along the path between the router and the DODAG root, MLD requests
are transported as DAO messages within RPL; each hop coalesces the
multiple requests for a same group as a single DAO message to the
parent(s), in a fashion similar to proxy IGMP, but recursively
between child router and parent Up to the DODAG root.
A router might select to pass a listener registration DAO message to A router might select to pass a listener registration DAO message to
its preferred parent only, in which case multicast packets coming its preferred parent only, in which case multicast packets coming
back might be lost for all of its sub-DODAG if the transmission fails back might be lost for all of its sub-DODAG if the transmission fails
over that link. Alternatively the router might select to copy over that link. Alternatively the router might select to copy
additional parents as it would do for DAO messages advertising additional parents as it would do for DAO messages advertising
unicast destinations, in which case there might be duplicates that unicast destinations, in which case there might be duplicates that
the router will need to prune. the router will need to prune.
As a result, multicast routing states are installed in each router on As a result, multicast routing states are installed in each router on
the way from the listeners to the DODAG root, enabling the root to the way from the listeners to the DODAG root, enabling the root to
copy a multicast packet to all its children routers that had issued a copy a multicast packet to all its children routers that had issued a
DAO message including a Target option for that multicast group, as DAO message including a Target option for that multicast group.
well as all the attached nodes that registered over MLD.
For unicast traffic, it is expected that the grounded DODAG root acts
as a Low power and lossy network Border Router (LBR) and MAY
redistribute the RPL routes over the external infrastructure using
whatever routing protocol is used in the other routing domain. For
multicast traffic, the root MAY proxy MLD for all the nodes attached
to the RPL domain (this would be needed if the multicast source is
located in the external infrastructure). For such a source, the
packet will be replicated as it flows Down the DODAG based on the
multicast routing table entries installed from the DAO message.
For a multicast packet sourced from inside the DODAG, the packet is For a multicast packet sourced from inside the DODAG, the packet is
passed to the preferred parents, and if that fails then to the passed to the preferred parents, and if that fails then to the
alternates in the DODAG. The packet is also copied to all the alternates in the DODAG. The packet is also copied to all the
registered children, except for the one that passed the packet. registered children, except for the one that passed the packet.
Finally, if there is a listener in the external infrastructure then Finally, if there is a listener in the external infrastructure then
the DODAG root has to further propagate the packet into the external the DODAG root has to further propagate the packet into the external
infrastructure. infrastructure.
As a result, the DODAG Root acts as an automatic proxy Rendezvous As a result, the DODAG Root acts as an automatic proxy Rendezvous
skipping to change at page 135, line 5 skipping to change at page 135, line 5
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bits are currently defined: The following bits are currently defined:
+------------+--------------------------+---------------+ +------------+------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+--------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DAO-ACK request | This document | | 0 | DAO-ACK request (K) | This document |
| | | | | | | |
| 1 | DODAGID field is present | This document | | 1 | DODAGID field is present (D) | This document |
+------------+--------------------------+---------------+ +------------+------------------------------+---------------+
DAO Base Flags DAO Base Flags
19.12. New Registry for the Destination Advertisement Object (DAO) 19.12. New Registry for the Destination Advertisement Object (DAO)
Acknowledgement Flags Acknowledgement Flags
IANA is requested to create a registry for the 8-bit Destination IANA is requested to create a registry for the 8-bit Destination
Advertisement Object (DAO) Acknowledgement Flag Field. Advertisement Object (DAO) Acknowledgement Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bit is currently defined: The following bit is currently defined:
+------------+--------------------------+---------------+ +------------+------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+--------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DODAGID field is present | This document | | 0 | DODAGID field is present (D) | This document |
+------------+--------------------------+---------------+ +------------+------------------------------+---------------+
DAO-ACK Base Flags DAO-ACK Base Flags
19.13. New Registry for the Consistency Check (CC) Flags 19.13. New Registry for the Consistency Check (CC) Flags
IANA is requested to create a registry for the 8-bit Consistency IANA is requested to create a registry for the 8-bit Consistency
Check (CC) Flag Field. Check (CC) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bit is currently defined: The following bit is currently defined:
+------------+-------------+---------------+ +------------+-----------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-------------+---------------+ +------------+-----------------+---------------+
| 0 | CC Response | This document | | 0 | CC Response (R) | This document |
+------------+-------------+---------------+ +------------+-----------------+---------------+
Consistency Check Base Flags Consistency Check Base Flags
19.14. New Registry for the DODAG Configuration Option Flags 19.14. New Registry for the DODAG Configuration Option Flags
IANA is requested to create a registry for the 8-bit DODAG IANA is requested to create a registry for the 8-bit DODAG
Configuration Option Flag Field. Configuration Option Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bits are currently defined: The following bits are currently defined:
+------------+------------------------+---------------+ +------------+----------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+------------------------+---------------+ +------------+----------------------------+---------------+
| 4 | Authentication Enabled | This document | | 4 | Authentication Enabled (A) | This document |
| | | | | | | |
| 5-7 | Path Control Size | This document | | 5-7 | Path Control Size (PCS) | This document |
+------------+------------------------+---------------+ +------------+----------------------------+---------------+
DODAG Configuration Option Flags DODAG Configuration Option Flags
19.15. New Registry for the RPL Target Option Flags 19.15. New Registry for the RPL Target Option Flags
IANA is requested to create a registry for the 8-bit RPL Target IANA is requested to create a registry for the 8-bit RPL Target
Option Flag Field. Option Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
skipping to change at page 137, line 29 skipping to change at page 137, line 29
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bits are currently defined: The following bits are currently defined:
+------------+-------------+---------------+ +------------+--------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-------------+---------------+ +------------+--------------+---------------+
| 0 | External | This document | | 0 | External (E) | This document |
+------------+-------------+---------------+ +------------+--------------+---------------+
Transit Information Option Flags Transit Information Option Flags
19.17. New Registry for the Solicited Information Option Flags 19.17. New Registry for the Solicited Information Option Flags
IANA is requested to create a registry for the 8-bit Solicited IANA is requested to create a registry for the 8-bit Solicited
Information Option (RIO) Flag Field. Information Option (RIO) Flag Field.
New bit numbers may be allocated only by an IETF Review. Each bit New bit numbers may be allocated only by an IETF Review. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bits are currently defined: The following bits are currently defined:
+------------+----------------------------+---------------+ +------------+--------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+----------------------------+---------------+ +------------+--------------------------------+---------------+
| 0 | Version Predicate match | This document | | 0 | Version Predicate match (V) | This document |
| | | | | | | |
| 1 | InstanceID Predicate match | This document | | 1 | InstanceID Predicate match (I) | This document |
| | | | | | | |
| 2 | DODAGID Predicate match | This document | | 2 | DODAGID Predicate match (D) | This document |
+------------+----------------------------+---------------+ +------------+--------------------------------+---------------+
Solicited Information Option Flags Solicited Information Option Flags
19.18. ICMPv6: Error in Source Routing Header 19.18. ICMPv6: Error in Source Routing Header
In some cases RPL will return an ICMPv6 error message when a message In some cases RPL will return an ICMPv6 error message when a message
cannot be delivered as specified by its source routing header. This cannot be delivered as specified by its source routing header. This
ICMPv6 error message is "Error in Source Routing Header". ICMPv6 error message is "Error in Source Routing Header".
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
skipping to change at page 141, line 25 skipping to change at page 141, line 25
[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., Pister, K., 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-14 (work in progress), draft-ietf-roll-routing-metrics-17 (work in progress),
December 2010. January 2011.
[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-06 (work "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work
in progress), December 2010. in progress), January 2011.
[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 142, line 24 skipping to change at page 142, line 24
22.2. Informative References 22.2. Informative References
[FIPS180] National Institute of Standards and Technology, "FIPS Pub [FIPS180] National Institute of Standards and Technology, "FIPS Pub
180-3, Secure Hash Standard (SHS)", US Department of 180-3, Secure Hash Standard (SHS)", US Department of
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-15 (work in progress),
December 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-04 (work in progress), December 2010. draft-ietf-roll-of0-05 (work in progress), January 2011.
[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 142, line 51 skipping to change at page 143, line 5
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003. Management Workshop", RFC 3535, May 2003.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005. June 2005.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
skipping to change at page 145, line 23 skipping to change at page 145, line 23
RPL merely provides a vehicle for disseminating information that may RPL merely provides a vehicle for disseminating information that may
be built upon and used by other mechanisms. be built upon and used by other mechanisms.
Note that these examples illustrate use of address autoconfiguration Note that these examples illustrate use of address autoconfiguration
schemes supported by information distributed within RPL. However, if schemes supported by information distributed within RPL. However, if
an implementation includes another address autoconfiguration scheme, an implementation includes another address autoconfiguration scheme,
RPL nodes might be configured not to set the 'A' flag in PIO options, 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 though the PIO can still be used to distribute prefix and addressing
information. information.
A.1. Example with External Prefixes A.1. Example Operation in Storing Mode With Node-owned 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 Figure 32 illustrates the logical addressing architecture of a simple
RPL network operating in storing mode. In this example each node, A, 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 B, C, and D, owns its own prefix, and makes that prefix available for
address autoconfiguration by on-link devices. (This is conveyed by address autoconfiguration by on-link devices. (This is conveyed by
setting the 'A' flag and the 'L' flag in the PIO of the DIO 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 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, 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 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 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 of setting the 'R' flag and publishing their address within the
Prefix field of the PIO. Prefix field of the PIO.
skipping to change at page 148, line 6 skipping to change at page 146, line 35
/ \ / \
/ \ / \
+------+------+ +------+------+ +------+------+ +------+------+
| B::C | | B::D | | B::C | | B::D |
| | | | | | | |
| Node C | | Node D | | Node C | | Node D |
| | | | | | | |
| C::C | | D::D | | C::C | | D::D |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 33: Storing Mode with Node-owned Prefixes Figure 32: Storing Mode with Node-owned Prefixes
A.2.1. DIO messages and PIO A.1.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows: Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Set 'L' flag: Set
'R' flag: Clear 'R' flag: Clear
Prefix Length: 64 Prefix Length: 64
Prefix: A:: Prefix: A::
Node B, for example, will send DIO messages with a PIO as follows: Node B, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
skipping to change at page 148, line 38 skipping to change at page 147, line 23
Prefix Length: 64 Prefix Length: 64
Prefix: C:: Prefix: C::
Node D, for example, will send DIO messages with a PIO as follows: Node D, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Set 'L' flag: Set
'R' flag: Set 'R' flag: Set
Prefix Length: 64 Prefix Length: 64
Prefix: D::D Prefix: D::D
A.2.2. DAO messages A.1.2. DAO messages
Node B will send DAO messages to node A with the following Node B will send DAO messages to node A with the following
information: information:
o Target B::/64 o Target B::/64
o Target C::/64 o Target C::/64
o Target D::/64 o Target D::/64
Node C will send DAO messages to node B with the following Node C will send DAO messages to node B with the following
information: information:
o Target C::/64 o Target C::/64
Node D will send DAO messages to node B with the following Node D will send DAO messages to node B with the following
information: information:
o Target D::/64 o Target D::/64
A.2.3. Routing Information Base A.1.3. Routing Information Base
Node A will conceptually collect the following information into its Node A will conceptually collect the following information into its
RIB: RIB:
o A::/64 connected o A::/64 connected
o B::/64 via B's link local o B::/64 via B's link local
o C::/64 via B's link local o C::/64 via B's link local
o D::/64 via B's link local o D::/64 via B's link local
Node B will conceptually collect the following information into its Node B will conceptually collect the following information into its
RIB: RIB:
skipping to change at page 149, line 37 skipping to change at page 148, line 20
Node C will conceptually collect the following information into its Node C will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o C::/64 connected o C::/64 connected
Node D will conceptually collect the following information into its Node D will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o D::/64 connected o D::/64 connected
A.3. Example Operation in Storing Mode With Subnet-wide Prefix A.2. Example Operation in Storing Mode With Subnet-wide Prefix
Figure 34 illustrates the logical addressing architecture of a simple Figure 33 illustrates the logical addressing architecture of a simple
RPL network operating in storing mode. In this example the root node RPL network operating in storing mode. In this example the root node
A sources a prefix which is used for address autoconfiguration over A sources a prefix which is used for address autoconfiguration over
the entire RPL subnet. (This is conveyed by setting the 'A' flag and 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, 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 C, and D all autoconfigure to the prefix A::/64. Nodes have the
option of setting the 'R' flag and publishing their address within option of setting the 'R' flag and publishing their address within
the Prefix field of the PIO. the Prefix field of the PIO.
+-------------+ +-------------+
| Root | | Root |
skipping to change at page 150, line 33 skipping to change at page 149, line 33
.--------------+--------------. .--------------+--------------.
/ \ / \
/ \ / \
+------+------+ +------+------+ +------+------+ +------+------+
| | | | | | | |
| Node C | | Node D | | Node C | | Node D |
| A::C | | A::D | | A::C | | A::D |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 34: Storing Mode with Subnet-wide Prefix Figure 33: Storing Mode with Subnet-wide Prefix
A.3.1. DIO messages and PIO A.2.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows: Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Clear 'L' flag: Clear
'R' flag: Clear 'R' flag: Clear
Prefix Length: 64 Prefix Length: 64
Prefix: A:: Prefix: A::
Node B, for example, will send DIO messages with a PIO as follows: Node B, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
skipping to change at page 151, line 22 skipping to change at page 150, line 22
Prefix Length: 64 Prefix Length: 64
Prefix: A:: Prefix: A::
Node D, for example, will send DIO messages with a PIO as follows: Node D, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Clear 'L' flag: Clear
'R' flag: Set 'R' flag: Set
Prefix Length: 64 Prefix Length: 64
Prefix: A::D Prefix: A::D
A.3.2. DAO messages A.2.2. DAO messages
Node B will send DAO messages to node A with the following Node B will send DAO messages to node A with the following
information: information:
o Target A::B/128 o Target A::B/128
o Target A::C/128 o Target A::C/128
o Target A::D/128 o Target A::D/128
Node C will send DAO messages to node B with the following Node C will send DAO messages to node B with the following
information: information:
o Target A::C/128 o Target A::C/128
Node D will send DAO messages to node B with the following Node D will send DAO messages to node B with the following
information: information:
o Target A::D/128 o Target A::D/128
A.3.3. Routing Information Base A.2.3. Routing Information Base
Node A will conceptually collect the following information into its Node A will conceptually collect the following information into its
RIB: RIB:
o A::/128 connected o A::A/128 connected
o B::/128 via B's link local o A::B/128 via B's link local
o C::/128 via B's link local o A::C/128 via B's link local
o D::/128 via B's link local o A::D/128 via B's link local
Node B will conceptually collect the following information into its Node B will conceptually collect the following information into its
RIB: RIB:
o ::/0 via A's link local o ::/0 via A's link local
o B::/128 connected o A::B/128 connected
o C::/128 via C's link local o A::C/128 via C's link local
o D::/128 via D's link local o A::D/128 via D's link local
Node C will conceptually collect the following information into its Node C will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o C::/128 connected o A::C/128 connected
Node D will conceptually collect the following information into its Node D will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o D::/128 connected o A::D/128 connected
A.4. Example Operation in Non-Storing Mode With Node-owned Prefixes A.3. Example Operation in Non-Storing Mode With Node-owned Prefixes
Figure 35 illustrates the logical addressing architecture of a simple Figure 34 illustrates the logical addressing architecture of a simple
RPL network operating in non-storing mode. In this example each 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 node, A, B, C, and D, owns its own prefix, and makes that prefix
available for address autoconfiguration by on-link devices. (This is 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 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, 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 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 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 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 option of setting the 'R' flag and publishing their address within
the Prefix field of the PIO. the Prefix field of the PIO.
skipping to change at page 153, line 35 skipping to change at page 152, line 35
/ \ / \
/ \ / \
+------+------+ +------+------+ +------+------+ +------+------+
| B::C | | B::D | | B::C | | B::D |
| | | | | | | |
| Node C | | Node D | | Node C | | Node D |
| | | | | | | |
| C::C | | D::D | | C::C | | D::D |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 35: Non-storing Mode with Node-owned Prefixes Figure 34: Non-storing Mode with Node-owned Prefixes
A.4.1. DIO messages and PIO A.3.1. DIO messages and PIO
The PIO contained in the DIO messages in the non-storing mode with 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 node-owned prefixes can be considered to be identical to those in the
storing mode with node-owned prefixes case (Appendix A.2.1). storing mode with node-owned prefixes case (Appendix A.1.1).
A.4.2. DAO messages A.3.2. DAO messages
Node B will send DAO messages to node A with the following Node B will send DAO messages to node A with the following
information: information:
o Target B::/64, Transit A::B o Target B::/64, Transit A::B
Node C will send DAO messages to node A with the following Node C will send DAO messages to node A with the following
information: information:
o Target C::/64, Transit B::C o Target C::/64, Transit B::C
Node D will send DAO messages to node A with the following Node D will send DAO messages to node A with the following
information: information:
o Target D::/64, Transit B::D o Target D::/64, Transit B::D
A.4.3. Routing Information Base A.3.3. Routing Information Base
Node A will conceptually collect the following information into its Node A will conceptually collect the following information into its
RIB. Note that Node A has enough information to construct source RIB. Note that Node A has enough information to construct source
routes by doing recursive lookups into the RIB: routes by doing recursive lookups into the RIB:
o A::/64 connected o A::/64 connected
o B::/64 via A::B o B::/64 via A::B
o C::/64 via B::C o C::/64 via B::C
o D::/64 via B::D o D::/64 via B::D
Node B will conceptually collect the following information into its Node B will conceptually collect the following information into its
skipping to change at page 154, line 40 skipping to change at page 153, line 40
Node C will conceptually collect the following information into its Node C will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o C::/64 connected o C::/64 connected
Node D will conceptually collect the following information into its Node D will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o D::/64 connected o D::/64 connected
A.5. Example Operation in Non-Storing Mode With Subnet-wide Prefix A.4. Example Operation in Non-Storing Mode With Subnet-wide Prefix
Figure 36 illustrates the logical addressing architecture of a simple Figure 35 illustrates the logical addressing architecture of a simple
RPL network operating in non-storing mode. In this example the root RPL network operating in non-storing mode. In this example the root
node A sources a prefix which is used for address autoconfiguration node A sources a prefix which is used for address autoconfiguration
over the entire RPL subnet. (This is conveyed by setting the 'A' 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). 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 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 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 field of the PIO, in order to inform their children which address to
use in the transit option. use in the transit option.
+-------------+ +-------------+
skipping to change at page 155, line 33 skipping to change at page 154, line 33
.--------------+--------------. .--------------+--------------.
/ \ / \
/ \ / \
+------+------+ +------+------+ +------+------+ +------+------+
| | | | | | | |
| Node C | | Node D | | Node C | | Node D |
| A::C | | A::D | | A::C | | A::D |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 36: XXX Figure 35: XXX
A.5.1. DIO messages and PIO A.4.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows: Node A, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Clear 'L' flag: Clear
'R' flag: Set 'R' flag: Set
Prefix Length: 64 Prefix Length: 64
Prefix: A::A Prefix: A::A
Node B, for example, will send DIO messages with a PIO as follows: Node B, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
skipping to change at page 156, line 22 skipping to change at page 155, line 22
Prefix Length: 64 Prefix Length: 64
Prefix: A::C Prefix: A::C
Node D, for example, will send DIO messages with a PIO as follows: Node D, for example, will send DIO messages with a PIO as follows:
'A' flag: Set 'A' flag: Set
'L' flag: Clear 'L' flag: Clear
'R' flag: Set 'R' flag: Set
Prefix Length: 64 Prefix Length: 64
Prefix: A::D Prefix: A::D
A.5.2. DAO messages A.4.2. DAO messages
Node B will send DAO messages to node A with the following Node B will send DAO messages to node A with the following
information: information:
o Target A::B/128, Transit A::A o Target A::B/128, Transit A::A
Node C will send DAO messages to node A with the following Node C will send DAO messages to node A with the following
information: information:
o Target A::C/128, Transit A::B o Target A::C/128, Transit A::B
Node D will send DAO messages to node A with the following Node D will send DAO messages to node A with the following
information: information:
o Target A::D/128, Transit A::B o Target A::D/128, Transit A::B
A.5.3. Routing Information Base A.4.3. Routing Information Base
Node A will conceptually collect the following information into its Node A will conceptually collect the following information into its
RIB. Note that Node A has enough information to construct source RIB. Note that Node A has enough information to construct source
routes by doing recursive lookups into the RIB: routes by doing recursive lookups into the RIB:
o A::A/128 connected o A::A/128 connected
o B::B/128 via A::A o A::B/128 via A::A
o C::C/128 via A::B o A::C/128 via A::B
o D::D/128 via A::B o A::D/128 via A::B
Node B will conceptually collect the following information into its Node B will conceptually collect the following information into its
RIB: RIB:
o ::/0 via A's link local o ::/0 via A's link local
o A::B/128 connected o A::B/128 connected
Node C will conceptually collect the following information into its Node C will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o A::C/128 connected o A::C/128 connected
Node D will conceptually collect the following information into its Node D will conceptually collect the following information into its
RIB: RIB:
o ::/0 via B's link local o ::/0 via B's link local
o A::D/128 connected o A::D/128 connected
A.5. Example with External Prefixes
Consider the simple network illustrated in Figure 36. 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 |
: | |
: +-------------------+
Figure 36: 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 a sub-DODAG underneath of it.
1. The DODAG Root adds a RIO to its DIO messages. The RIO contains
the external prefix EXT_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 EXT_1::/64 is disseminated
down the DODAG.
2. 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.
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. 71 change blocks. 
274 lines changed or deleted 244 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/