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/