draft-ietf-roll-p2p-rpl-09.txt		draft-ietf-roll-p2p-rpl-10.txt
	Internet Engineering Task Force M. Goyal, Ed.		Internet Engineering Task Force M. Goyal, Ed.
	Internet-Draft University of Wisconsin		Internet-Draft University of Wisconsin
	Intended status: Experimental Milwaukee		Intended status: Experimental Milwaukee
	Expires: September 7, 2012 E. Baccelli		Expires: November 6, 2012 E. Baccelli
	M. Philipp		M. Philipp
	INRIA		INRIA
	A. Brandt		A. Brandt
	Sigma Designs		Sigma Designs
	J. Martocci		J. Martocci
	Johnson Controls		Johnson Controls
	March 6, 2012		May 5, 2012
	Reactive Discovery of Point-to-Point Routes in Low Power and Lossy		Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
	Networks		Networks
	draft-ietf-roll-p2p-rpl-09		draft-ietf-roll-p2p-rpl-10
	Abstract		Abstract
	This document specifies a point-to-point route discovery mechanism,		This document specifies a point-to-point route discovery mechanism,
	complementary to the RPL core functionality. This mechanism allows		complementary to the RPL core functionality. This mechanism allows
	an IPv6 router to discover "on demand" routes to one or more IPv6		an IPv6 router to discover "on demand" routes to one or more IPv6
	routers in the LLN such that the discovered routes meets specified		routers in the LLN such that the discovered routes meet specified
	metrics constraints.		metrics constraints.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). 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 September 7, 2012.		This Internet-Draft will expire on November 6, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3		2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 5		5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6
	6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 8		6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 9
	6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 8		6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9
	7. New RPL Control Message Options . . . . . . . . . . . . . . . 11		7. New RPL Control Message Options . . . . . . . . . . . . . . . 11
	7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 11		7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 12
	7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15
	8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 14		8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15
	8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 16		8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 16		8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18
	9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 17		9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18
	9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 17		9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18
	9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 18		9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19
	9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 19		9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 20
	9.4. Additional Processing of a P2P Mode DIO At An		9.4. Additional Processing of a P2P Mode DIO At An
	Intermediate Router . . . . . . . . . . . . . . . . . . . 20		Intermediate Router . . . . . . . . . . . . . . . . . . . 21
	9.5. Additional Processing of a P2P Mode DIO At The Target . . 21		9.5. Additional Processing of a P2P Mode DIO At The Target . . 22
	9.6. Processing a DRO At An Intermediate Router . . . . . . . . 22		9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24
	9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 23		9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25
	10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 24		10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 26
	11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 24		11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27
	12. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 25		12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28
	13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 25		13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 26		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29
	15.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 26		14.2. Additions to RPL Control Message Options . . . . . . . . . 29
	15.2. Additions to RPL Control Message Options . . . . . . . . . 27		14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30
	15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 27		14.4. New Registry for Upper Layer Headers inside Data Option . 30
	16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 28		16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
	17.2. Informative References . . . . . . . . . . . . . . . . . . 28		16.2. Informative References . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	Targeting Low power and Lossy Networks (LLNs), the RPL routing		Targeting Low power and Lossy Networks (LLNs), the RPL routing
	protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic		protocol [RFC6550] provides paths along a Directed Acyclic Graph
	Graph (DAG) rooted at a single router in the network. Establishment		(DAG) rooted at a single router in the network. Establishment and
	and maintenance of a DAG is performed by routers in the LLN using		maintenance of a DAG is performed by routers in the LLN using DODAG
	DODAG Information Object (DIO) messages. When two arbitrary routers		Information Object (DIO) messages. When two arbitrary routers
	(neither of which is the DAG's root) need to communicate, the data		(neither of which is the DAG's root) need to communicate, the data
	packets are restricted to travel only along the links in the DAG.		packets are restricted to travel only along the links in the DAG.
	Such point-to-point (P2P) routing functionality may not be sufficient		Such point-to-point (P2P) routing functionality may not be sufficient
	for several Home and Building Automation applications [RFC5826]		for several Home and Building Automation applications [RFC5826]
	[RFC5867] due to the following reasons:		[RFC5867] due to the following reasons:
	o The need to pre-establish routes: each potential destination in		o The need to pre-establish routes: each potential destination in
	the network must declare itself as such ahead of the time a source		the network must declare itself as such ahead of the time a source
	needs to reach it.		needs to reach it.
	skipping to change at page 3, line 34		skipping to change at page 3, line 34
	routes to use only the in-DAG links may result in significantly		routes to use only the in-DAG links may result in significantly
	suboptimal routes and severe traffic congestion near the DAG root.		suboptimal routes and severe traffic congestion near the DAG root.
	This document describes an extension to core RPL that enables an IPv6		This document describes an extension to core RPL that enables an IPv6
	router in the LLN to discover routes to one or more IPv6 routers in		router in the LLN to discover routes to one or more IPv6 routers in
	the LLN "on demand", such that the discovered routes meet the		the LLN "on demand", such that the discovered routes meet the
	specified metrics constraints, without necessarily going along the		specified metrics constraints, without necessarily going along the
	links in an existing DAG. This reactive P2P route discovery		links in an existing DAG. This reactive P2P route discovery
	mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not		mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not
	guarantee discovery of a route. Also, the discovered routes may not		guarantee discovery of a route. Also, the discovered routes may not
	be the best available. However, any discovered routes are guaranteed		be optimal. However, any discovered routes are guaranteed to satisfy
	to satisfy the desired constraints in terms of the routing metrics		the desired constraints in terms of the routing metrics and are thus
	and are thus considered "good enough" from the application's		considered "good enough" from the application's perspective.
	perspective.
	A mechanism to measure the end-to-end cost of an existing route has		A mechanism to measure the end-to-end cost of an existing route is
	been specified in [I-D.ietf-roll-p2p-measurement]. As discussed in		specified in [I-D.ietf-roll-p2p-measurement]. As discussed in
	Section 4, measuring the end-to-end cost of an existing route may		Section 4, measuring the end-to-end cost of an existing route may
	help decide whether to initiate the discovery of a better route using		help decide whether to initiate the discovery of a better route using
	P2P-RPL and the metric constraints to be used for this purpose.		P2P-RPL and the metric constraints to be used for this purpose.
	2. The Use Cases		2. The Use Cases
	One use case, common in home and commercial building environments,		One use case, common in home and commercial building environments,
	involves a device (say a remote control or an airduct controller)		involves a device (say a remote control or an airduct controller)
	that suddenly needs to communicate with another device (say a lamp or		that suddenly needs to communicate with another device (say a lamp or
	a humidity sensor) to which it does not already have a route. In		a humidity sensor) to which it does not already have a route. In
	skipping to change at page 4, line 25		skipping to change at page 4, line 24
	they involve traversing many more intermediate routers than necessary		they involve traversing many more intermediate routers than necessary
	to reach the destination.		to reach the destination.
	3. Terminology		3. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	Additionally, this document uses terminology from		Additionally, this document uses terminology from [RFC6550]. This
	[I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document		document introduces the following terms:
	introduces the following terms:
	Origin : The IPv6 router initiating the P2P-RPL route discovery.		Origin : The IPv6 router initiating the P2P-RPL route discovery.
	Target : The IPv6 router at the other end point of the P2P route(s)		Target : The IPv6 router at the other end point of the P2P route(s)
	to be discovered. A P2P-RPL route discovery can discover routes to		to be discovered. A P2P-RPL route discovery can discover routes to
	multiple targets at the same time.		multiple Targets at the same time.
	Intermediate Router: An IPv6 router that is neither the origin nor a		Intermediate Router: An IPv6 router that is neither the Origin nor a
	target.		Target.
	Forward Route: A route in the forward direction, i.e., from the		Forward direction: The direction from the Origin to the Target.
	origin to the target.
	Backward Route: A route in the backward direction, i.e., from the		Backward direction: The direction from the Target to the Origin.
	target to the origin.
	Bidirectional Route: A route that can be used in both forward and		Forward Route: A route in the Forward direction.
	backward directions.
			Backward Route: A route in the Backward direction.
			Bidirectional Route: A route that can be used in both Forward and
			Backward directions.
	Source Route: A complete and ordered list of routers that can be used		Source Route: A complete and ordered list of routers that can be used
	by a packet to travel from a source to a destination node.		by a packet to travel from a source to a destination node.
	Hop-by-hop Route: The route characterized by each router on the route		Hop-by-hop Route: The route characterized by each router on the route
	using its routing table to determine the next hop on the route.		using its routing table to determine the next hop on the route.
	4. Applicability		4. Applicability
	A route discovery using P2P-RPL may be performed by an origin when no		A route discovery using P2P-RPL may be performed by an Origin when no
	route exists between itself and the target(s) or when the existing		route exists between itself and the Target(s) or when the existing
	routes do not satisfy the application requirements. P2P-RPL is		routes do not satisfy the application requirements. P2P-RPL is
	designed to discover hop-by-hop or source routes to one or more		designed to discover Hop-by-hop or Source Routes to one or more
	targets such that the discovered routes meet the specified		Targets such that the discovered routes meet the specified
	constraints. In some application contexts, the constraints that the		constraints. In some application contexts, the constraints that the
	discovered routes must satisfy are intrinsically known or can be		discovered routes must satisfy are intrinsically known or can be
	specified by the application. For example, an origin that expects		specified by the application. For example, an Origin that expects
	its targets to be less than 5 hops away may use "hop-count < 5" as		its Targets to be less than 5 hops away may use "hop-count < 5" as
	the constraint. In other application contexts, the origin may need		the constraint. In other application contexts, the Origin may need
	to measure the cost of the existing route to a target to determine		to measure the cost of the existing route to a Target to determine
	the constraints. For example, an origin that measures the total ETX		the constraints. For example, an Origin that measures the total ETX
	along its current route to a target to be 20 may use "ETX < x*20",		along its current route to a Target to be 20 may use "ETX < x*20",
	where x is a fraction that the origin decides, as the constraint. A		where x is a fraction that the Origin decides, as the constraint. A
	mechanism to measure the cost of an existing route between two IPv6		mechanism to measure the cost of an existing route between two IPv6
	routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is		routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is
	no existing route between the origin and the target(s) or the cost		no existing route between the Origin and the Target(s) or the cost
	measurement for the existing routes fails, the origin will have to		measurement for the existing routes fails, the Origin will have to
	guess the constraints to be used in the initial route discovery.		guess the constraints to be used in the initial route discovery.
	Once, the initial route discovery succeeds or fails, the origin will		Once, the initial route discovery succeeds or fails, the Origin will
	have a better estimate for the constraints to be used in the		have a better estimate for the constraints to be used in the
	subsequent route discovery.		subsequent route discovery.
	P2P-RPL may result in discovery of better P2P routes than the ones		P2P-RPL may result in discovery of better P2P routes than the ones
	available along a DAG designed to optimize routing cost to the DAG's		available along a global DAG designed to optimize routing cost to the
	root. The improvement in route quality depends on a number of		DAG's root. The improvement in route quality depends on a number of
	factors including the network topology, the routing metrics in use		factors including the network topology, the "distance" between the
	and the prevalent conditions in the network. A network designer may		Origin and the Target (in terms of the routing metrics in use) and
	take into consideration both the benefits (potentially better routes;		the prevalent conditions in the network. In general, a P2P-RPL route
	no need to maintain routes proactively) and costs (control messages		may be better than the one along a global DAG if the Origin and the
	generated during the route discovery process) when using P2P-RPL.		Target are nearby. Similarly, a P2P-RPL route may not be much better
			than the one along a global DAG if the Origin and the Target are far
			apart. Note that, even when P2P-RPL routes are not much better than
			those along a global DAG, P2P-RPL routes may still be able to avoid
			congestion that might occur near the root if the routing takes place
			only along a global DAG. In general, the costs associated with a
			P2P-RPL route discovery (in terms of the control messages, mostly
			DIOs, generated) increases with the distance between the Origin and
			the Target. However, it is possible to limit the cost of route
			discovery by carefully setting the routing constraints, the Trickle
			parameters (that govern the DIO generation) and the lifetime of the
			temporary DAG created for the route discovery. A network designer
			may take into consideration both the benefits (potentially better
			routes; no need to maintain routes proactively; avoid congestion near
			the global DAG's root) and costs when using P2P-RPL. The latency
			associated with a P2P-RPL route discovery again depends on the
			distance between the Origin and the Target and the Trickle
			parameters.
			Note that the participation in a P2P-RPL route discovery is limited
			to the routers with IPv6 addresses that are reachable in both Forward
			and Backward directions.
	5. Functional Overview		5. Functional Overview
	This section contains a high level description of P2P-RPL.		This section contains a high level description of P2P-RPL.
	A P2P-RPL route discovery takes place by forming a DAG rooted at the		A P2P-RPL route discovery takes place by forming a DAG rooted at the
	origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local		Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local
	multicast DIO messages to establish a DAG. However, unlike core RPL,		multicast DIO messages to establish a DAG. However, unlike core RPL,
	this DAG is temporary in nature and routers in the DAG leave once the		this DAG is temporary in nature and routers in the DAG leave once the
	DAG's life time is over. The sole purpose of DAG creation is to		DAG's life time is over. The sole purpose of DAG creation is to
	discover routes to the target(s) and DIOs serve as the route		discover routes to the Target(s) and DIOs serve as the route
	discovery messages. Each router joining the DAG determines a rank		discovery messages. Each router joining the DAG determines a rank
	for itself in the DAG and ignores the subsequent DIOs received from		for itself in the DAG and ignores the subsequent DIOs received from
	lower (higher in numerical value) ranked neighbors. Thus, the route		lower (higher in numerical value) ranked neighbors. Thus, the route
	discovery messages propagate away from the origin rather than return		discovery messages propagate away from the Origin rather than return
	back to it. As in core RPL, DIO generation at a router is controlled		back to it. As in core RPL, DIO generation at a router is controlled
	by a Trickle timer [RFC6206] that allows a router to avoid generating		by a Trickle timer [RFC6206] that allows a router to avoid generating
	unnecessary messages while providing protection against unreliable		unnecessary messages while providing protection against packet loss.
	wireless communication. P2P-RPL also uses the routing metrics		P2P-RPL also uses the routing metrics [RFC6551], objective functions
	[I-D.ietf-roll-routing-metrics], objective functions and packet		and packet forwarding framework [RFC6554][RFC6553] developed for core
	forwarding framework		RPL.
	[I-D.ietf-6man-rpl-routing-header][I-D.ietf-6man-rpl-option]
	developed for core RPL.
	An origin may use P2P-RPL to discover routes to one or more targets		An Origin may use P2P-RPL to discover routes to one or more Targets
	identified by one or more unicast/multicast addresses. P2P-RPL		identified by one or more unicast/multicast addresses. P2P-RPL
	allows for the discovery of one hop-by-hop route or upto four source		allows for the discovery of one Hop-by-hop Route or up to four Source
	routes per target. P2P-RPL allows an origin to piggyback time-		Routes per Target. P2P-RPL allows an Origin to piggyback time-
	critical application data on the DIO messages for delivery to the		critical application data on the DIO messages for delivery to the
	target(s). P2P-RPL does not guarantee discovery of a route to a		Target(s). P2P-RPL does not guarantee discovery of a route to a
	target. Also, the discovered routes may not be the best available.		Target. Also, the discovered routes may not be the best available.
	However, any discovered routes are guaranteed to satisfy the desired		However, any discovered routes are guaranteed to satisfy the desired
	constraints in terms of the routing metrics and are thus considered		constraints in terms of the routing metrics and are thus considered
	"good enough" from the application's perspective.		"good enough" from the application's perspective.
	A P2P-RPL route discovery takes place by forming a temporary DAG		A P2P-RPL route discovery takes place by forming a temporary DAG
	rooted at the origin. The DIOs, used to create the temporary DAG,		rooted at the Origin. The DIOs, used to create the temporary DAG,
	are identified by a new Mode of Operation (P2P Route Discovery mode		are identified by a new Mode of Operation (P2P Route Discovery mode
	defined in Section 6). The DIOs, listing the P2P Route Discovery		defined in Section 6). The DIOs, listing the P2P Route Discovery
	mode as the Mode of Operation, are henceforth referred to as the P2P		mode as the Mode of Operation, are henceforth referred to as the P2P
	mode DIOs. A P2P mode DIO always carries one P2P Route Discovery		mode DIOs. A P2P mode DIO always carries one P2P Route Discovery
	Option (defined in Section 7.1) in which the origin specifies the		Option (defined in Section 7.1) in which the Origin specifies the
	following information:		following information:
	o The IPv6 address of a target. This could be a unicast address or		o The IPv6 address of a Target. This could be a unicast address or
	a multicast one. Any additional targets may be specified by		a multicast one. Any additional Targets may be specified by
	including one or more RPL Target Options [I-D.ietf-roll-rpl]		including one or more RPL Target Options [RFC6550] inside the DIO.
	inside the DIO.
	o The nature of the route(s) to be discovered: hop-by-hop or source		o The nature of the route(s) to be discovered: hop-by-hop or Source
	routes. This specification allows for the discovery of one hop-		Routes. This specification allows for the discovery of one Hop-
	by-hop route or up to four source routes per target.		by-hop Route or up to four Source Routes per Target.
	o The desired number of routes (if source routes are being		o The desired number of routes (if Source Routes are being
	discovered).		discovered).
	o Whether the target(s) should send Discovery Reply Object (DRO)		o Whether the Target(s) should send Discovery Reply Object (DRO)
	messages (defined in Section 8) back to the origin on receiving a		messages (defined in Section 8) back to the Origin on receiving a
	DIO message. A DRO message carries a discovered source route back		DIO message. A DRO message carries a discovered Source Route back
	to the origin or establishes a hop-by-hop route between the origin		to the Origin or establishes a Hop-by-hop Route between the Origin
	and the target. By not allowing the generation of DRO messages,		and the Target. By not allowing the generation of DRO messages,
	an origin can use P2P-RPL as purely a mechanism to deliver time-		an Origin can use P2P-RPL as purely a mechanism to deliver time-
	critical application data to the target(s).		critical application data to the Target(s).
	A P2P Route Discovery Option also accumulates a route from the origin		A P2P Route Discovery Option also accumulates a route from the Origin
	to a target as the routers join the temporary DAG.		to a Target as the routers join the temporary DAG.
	A P2P mode DIO MAY also carry:		A P2P mode DIO MAY also carry:
	o One or more Metric Container Options to specify:		o One or more Metric Container Options to specify:
	* The relevant routing metrics.		* The relevant routing metrics.
	* The constraints that the discovered route must satisfy. These		* The constraints that the discovered route must satisfy. These
	constraints also limit how far the DIOs message may travel.		constraints also limit how far the DIOs message may travel.
	o One or more RPL Target options to specify additional unicast or		o One or more RPL Target options to specify additional unicast or
	multicast targets.		multicast Targets.
	o One or more Data Options (defined in Section 7.2) to carry time-		o One Data Option (defined in Section 7.2) to carry time-critical
	critical application-level data to be delivered to the target(s).		application-level data to be delivered to the Target(s).
	As the routers join the temporary DAG, they keep track of the best		As the routers join the temporary DAG, they keep track of the best
	(partial) route(s) they have seen and advertise these routes, along		(partial) route(s) they have seen and advertise these routes, along
	with the corresponding routing metrics, in their P2P mode DIOs. A		with the corresponding routing metrics, in their P2P mode DIOs. A
	router, including the target(s), discards a received P2P mode DIO if		router, including the Target(s), discards a received P2P mode DIO if
	the aggregated routing metrics on the route advertised by the DIO do		the aggregated routing metrics on the route advertised by the DIO do
	not satisfy the listed constraints. These constraints can be used to		not satisfy the listed constraints. These constraints can be used to
	limit the propagation of P2P mode DIO messages. A router may also		limit the propagation of P2P mode DIO messages. A router may also
	discard a received P2P mode DIO if it does not wish to be a part of		discard a received P2P mode DIO if it does not wish to be a part of
	the discovered route due to limited resources or due to policy		the discovered route due to limited resources or due to policy
	reasons.		reasons.
	When a target receives a P2P mode DIO, it forwards the data in any		When a Target receives a P2P mode DIO, it forwards the data in the
	Data Options to the higher layer. The target may remember the		Data Option, if present, to the higher layer. The Target may
	discovered route for use as a source route to reach the origin. If		remember the discovered route for use as a Source Route to reach the
	the origin has requested DRO messages to be sent back, the target may		Origin. If the Origin has requested DRO messages to be sent back,
	select the route contained in the received DIO for further processing		the Target may select the route contained in the received DIO for
	as described next. This document does not specify a particular		further processing as described next. This document does not specify
	method for the target to use to select a route for further		a particular method for the Target to use to select a route for
	processing. Example methods include selecting any route that meets		further processing. Example methods include selecting any route that
	the constraints or selecting the best route(s) discovered over a		meets the constraints or selecting the best route(s) discovered over
	certain time period.		a certain time period.
	If one or more source routes are being discovered, the target sends		If one or more Source Routes are being discovered, the Target sends
	the selected source routes to the origin via DRO messages with one		the selected Source Routes to the Origin via DRO messages with one
	DRO message carrying one discovered route. On receiving a DRO		DRO message carrying one discovered route. On receiving a DRO
	message, the origin stores the discovered route in its memory. If a		message, the Origin stores the discovered route in its memory. If a
	hop-by-hop route is being discovered, the target sends a DRO message		Hop-by-hop Route is being discovered, the Target sends a DRO message
	containing the selected route to the origin. The DRO message travels		containing the selected route to the Origin. The DRO message travels
	back to the origin along the selected route, establishing state for		back to the Origin along the selected route, establishing state for
	this route in the routers on the path. The target may include one or		this route in the routers on the path. The Target may include a Data
	more Data Options in a DRO message to deliver any time-critical		Option in a DRO message to deliver any time-critical application data
	application data to the origin.		to the Origin.
	The target may request the origin to acknowledge the receipt of a DRO		The Target may request the Origin to acknowledge the receipt of a DRO
	message by sending back a DRO Acknowledgement (DRO-ACK) message		message by sending back a DRO Acknowledgement (DRO-ACK) message
	(defined in Section 10). The origin unicasts a DRO-ACK message to		(defined in Section 10). The Origin unicasts a DRO-ACK message to
	the target. When the target does not receive the requested DRO-ACK		the Target. If the Target does not receive the requested DRO-ACK
	within a certain time interval of sending a DRO, it resends the DRO		within a certain time interval of sending a DRO, it resends the DRO
	message (up to a certain number of times) carrying the same route as		message (up to a certain number of times) carrying the same route as
	before.		before.
	The use of trickle timers to delay the propagation of DIO messages		The use of trickle timers to delay the propagation of DIO messages
	may cause some nodes to generate these messages even when the desired		may cause some nodes to generate these messages even when the desired
	routes have already been discovered. In order to preempt the		routes have already been discovered. In order to preempt the
	generation of such unnecessary messages, the target may set a "stop"		generation of such unnecessary messages, the Target may set a "stop"
	flag in the DRO message to let the nodes in the LLN know about the		flag in the DRO message to let the nodes in the LLN know about the
	completion of the route discovery process. The routers receiving		completion of the route discovery process. The routers receiving
	such a DRO should not generate any more DIOs for this temporary DAG.		such a DRO should not generate any more DIOs for this temporary DAG.
	Neither should they process any received DIOs for this temporary DAG		Neither should they process any received DIOs for this temporary DAG
	in future. However, such routers must still process the DROs		in future. However, such routers must still process the DROs
	received for this temporary DAG.		received for this temporary DAG.
	6. P2P Route Discovery Mode Of Operation		6. P2P Route Discovery Mode Of Operation
	This section specifies a new RPL Mode of Operation (MOP), P2P Route		This section specifies a new RPL Mode of Operation (MOP), P2P Route
	skipping to change at page 8, line 46		skipping to change at page 9, line 20
	identified as performing a P2P-RPL route discovery by creating a		identified as performing a P2P-RPL route discovery by creating a
	temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route		temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route
	Discovery Option (specified in Section 7.1).		Discovery Option (specified in Section 7.1).
	6.1. Setting a P2P Mode DIO		6.1. Setting a P2P Mode DIO
	The Base Object in a P2P mode DIO message MUST be set in the		The Base Object in a P2P mode DIO message MUST be set in the
	following manner:		following manner:
	o RPLInstanceID: RPLInstanceID MUST be a local value as described in		o RPLInstanceID: RPLInstanceID MUST be a local value as described in
	Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the		Section 5.1 of [RFC6550]. The Origin MUST NOT use the same
	same RPLInstanceID in two or more concurrent route discoveries.		RPLInstanceID in two or more concurrent route discoveries. When
			initiating a new route discovery to a particular Target, the
			Origin MUST NOT reuse the RPLInstanceID used in a previous route
			discovery to this Target if the previously discovered routes might
			still exist. The Default Lifetime and Lifetime Unit parameters in
			the DODAG Configuration Option specify the lifetime of the state
			the routers, including the Origin and the Target, maintain for a
			hop-by-hop or a Source Route discovered using P2P-RPL. Thus, an
			Origin can safely reuse an RPLInstanceID to discover a new route
			to a Target if the lifetime of all previously discovered routes to
			this Target using this RPLInstanceID is over.
	o Version Number: MUST be set to zero. The temporary DAG used for		o Version Number: MUST be set to zero. The temporary DAG used for
	P2P-RPL route discovery does not exist long enough to have new		P2P-RPL route discovery does not exist long enough to have new
	versions.		versions.
	o Grounded (G) Flag: MUST be set to zero since this DAG is temporary		o Grounded (G) Flag: This flag MUST be set to one. Unlike a global
	in nature, is created solely for the purpose of P2P-RPL route		RPL instance, the concept of a floating DAG, used to provide
	discovery and MUST NOT be used for packet routing.		connectivity within a sub-DAG detached from a grounded DAG, does
			not apply to a local RPL instance. Hence, an Origin MUST always
			set the G flag to one when initiating a P2P-RPL route discovery.
			Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply
			and a node MUST NOT initiate a new DAG if it does not have any
			parent left in a P2P-RPL DAG.
	o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P		o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P
	Route Discovery mode.		Route Discovery mode.
	o DTSN: MUST be set to zero on transmission and ignored on		o DTSN: MUST be set to zero on transmission and ignored on
	reception.		reception.
	o DODAGPreference (Prf): This field MUST be set to zero (least		o DODAGPreference (Prf): This field MUST be set to zero (least
	preferred).		preferred).
	o DODAGID: This field MUST be set to an IPv6 address of the origin.		o DODAGID: This field MUST be set to an IPv6 address of the Origin.
	o The other fields in the DIO Base Object can be set in the desired		o The other fields in the DIO Base Object can be set in the desired
	fashion as per the rules described in [I-D.ietf-roll-rpl].		fashion as per the rules described in [RFC6550].
	The DODAG Configuration Option, inside a P2P mode DIO MUST be set in		The DODAG Configuration Option, inside a P2P mode DIO MUST be set in
	the following manner:		the following manner:
	o MaxRankIncrease: This field MUST be set to zero to disable local		o The Origin MUST set the MaxRankIncrease parameter to zero to
	repair of the temporary DAG.		disable local repair of the temporary DAG.
	o Trickle parameters (DIOIntervalDoublings, DIOIntervalMin,		o The Origin SHOULD set the Trickle parameters
	DIORedundancyConstant) SHOULD be set as described in Section 9.2.		(DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as
			recommended in Section 9.2.
	o The Default Lifetime and Lifetime Unit parameters in DODAG		o The Origin sets the Default Lifetime and Lifetime Unit parameters
	Configuration option indicate the life time of the state the		to indicate the lifetime of the state the routers, including the
	routers maintain for a hop-by-hop route established using P2P-RPL		Origin and the Target(s), maintain for a hop-by-hop or a Source
	and may be set as desired.		Route discovered using P2P-RPL.
	o The other fields in the DODAG Configuration Option, including the		o The Origin sets the other fields in the DODAG Configuration
	OCP identifying the Objective function, can be set in the desired		Option, including the OCP identifying the Objective function, in
	fashion as per the rules described in [I-D.ietf-roll-rpl].		the desired fashion as per the rules described in [RFC6550].
			o An Intermediate Router (or a Target) MUST set various fields in
			the DODAG Configuration Option in the outgoing P2P mode DIOs to
			the values they had in the incoming P2P mode DIOs for this DAG.
	A default DODAG Configuration Option comes in effect if a P2P mode		A default DODAG Configuration Option comes in effect if a P2P mode
	DIO does not carry an explicit one. The default DODAG Configuration		DIO does not carry an explicit one. The default DODAG Configuration
	Option has the following parameter values:		Option has the following parameter values:
	o Authentication Enabled: 0		o Authentication Enabled: 0
	o DIOIntervalMin: 6, which translates to 64ms as the value for Imin		o DIOIntervalMin: 6, which translates to 64ms as the value for Imin
	parameter in Trickle operation.		parameter in Trickle operation.
	o DIORedundancyConstant: 1		o DIORedundancyConstant: 1
	o MaxRankIncrease: 0		o MaxRankIncrease: 0
	o Default Lifetime: 0xFF		o Default Lifetime: 0xFF
	o Lifetime Unit: 0xFFFF		o Lifetime Unit: 0xFFFF
			o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default
	o Objective Code Point: 0, i.e., OF0 [I-D.ietf-roll-of0] is the		objective function.
	default objective function.
	o The remaining parameters have default values as specified in		o The remaining parameters have default values as specified in
	[I-D.ietf-roll-rpl].		[RFC6550].
	The routing metrics and constraints [I-D.ietf-roll-routing-metrics]		The routing metrics and constraints [RFC6551] used in P2P-RPL route
	used in P2P-RPL route discovery are included in one or more Metric		discovery are included in one or more Metric Container Options
	Container Options [I-D.ietf-roll-rpl] inside the P2P mode DIO. Note		[RFC6550] inside the P2P mode DIO. Note that a DIO need not include
	that a DIO need not include a Metric Container if OF0 is the		a Metric Container if OF0 is the objective function in effect. In
	objective function in effect. In that case, a P2P mode DIO may still		that case, a P2P mode DIO may still specify an upper limit on the
	specify an upper limit on the maximum rank, that a router may have in		maximum rank, that a router may have in the temporary DAG, inside the
	the temporary DAG, inside the P2P Route Discovery Option (described		P2P Route Discovery Option (described in Section 7.1).
	in Section 7.1).
	A P2P mode DIO:		A P2P mode DIO:
	o MUST carry one (and only one) P2P Route Discovery Option		o MUST carry one (and only one) P2P Route Discovery Option
	(described in Section 7.1). The P2P Route Discovery Option allows		(described in Section 7.1). The P2P Route Discovery Option allows
	for the specification of one unicast or multicast address for the		for the specification of one unicast or multicast address for the
	target.		Target.
	o MAY carry one or more RPL Target Options to specify additional		o MAY carry one or more RPL Target Options to specify additional
	unicast/multicast addresses for the target.		unicast/multicast addresses for the Target.
	o MAY carry one or more Metric Container Options to specify routing		o MAY carry one or more Metric Container Options to specify routing
	metrics and constraints.		metrics and constraints.
	o MAY carry one or more Data Options (described in Section 7.2)		o MAY carry one Data Option (described in Section 7.2) containing
	containing time-critical application data to be delivered to the		time-critical application data to be delivered to the Target(s).
	target(s).
	o MAY carry one or more Route Information or Prefix Information		o MAY carry one or more Route Information or Prefix Information
	Options (described in [I-D.ietf-roll-rpl]).		Options (described in [RFC6550]).
	A router MUST discard a received P2P mode DIO if it violates any of		A router MUST discard a received P2P mode DIO if it violates any of
	the rules listed above.		the rules listed above.
	7. New RPL Control Message Options		7. New RPL Control Message Options
	This document defines two new RPL control message options: the P2P		This document defines two new RPL control message options: the P2P
	Route Discovery Option and the Data Option.		Route Discovery Option and the Data Option.
	7.1. P2P Route Discovery Option (P2P-RDO)		7.1. P2P Route Discovery Option (P2P-RDO)
	skipping to change at page 11, line 42		skipping to change at page 12, line 37
	in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message		in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message
	MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the		MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the
	following fields:		following fields:
	o Option Type: 0x0A (to be confirmed by IANA).		o Option Type: 0x0A (to be confirmed by IANA).
	o Option Length: 8-bit unsigned integer, representing the length in		o Option Length: 8-bit unsigned integer, representing the length in
	octets of the option, not including the Option Type and Option		octets of the option, not including the Option Type and Option
	Length fields.		Length fields.
	o Reply (R): The origin sets this flag to one to allow the target(s)		o Reply (R): The Origin sets this flag to one to allow the Target(s)
	to send DRO messages back to the origin. If this flag is zero, a		to send DRO messages back to the Origin. If this flag is zero, a
	target MUST NOT generate any DRO message.		Target MUST NOT generate any DRO message.
	o Hop-by-hop (H): This flag is valid only if the R flag is set to		o Hop-by-hop (H): This flag is valid only if the R flag is set to
	one. The origin sets this flag to one if it desires hop-by-hop		one. The Origin sets this flag to one if it desires Hop-by-hop
	routes. The origin sets this flag to zero if it desires source		Routes. The Origin sets this flag to zero if it desires Source
	routes. This specification allows for the establishment of one		Routes. This specification allows for the establishment of one
	hop-by-hop route or up to four source routes per target. The hop-		hop-by-hop route or up to four Source Routes per Target. The Hop-
	by-hop route is established in the forward direction, i.e. from		by-hop Route is established in the Forward direction, i.e. from
	the origin to the target. This specification does not allow for		the Origin to the Target. This specification does not allow for
	the establishment of hop-by-hop routes in the backward direction.		the establishment of Hop-by-hop Routes in the Backward direction.
	o Number of Routes (N): This flag is valid only if the R flag is one		o Number of Routes (N): This flag is valid only if the R flag is one
	and H flag is zero, i.e. the targets are allowed to generate DRO		and H flag is zero, i.e. the Targets are allowed to generate DRO
	messages carrying discovered source routes back to the origin. In		messages carrying discovered Source Routes back to the Origin. In
	this case, the value in the N field plus one indicates the number		this case, the value in the N field plus one indicates the number
	of source routes that each target should convey to the origin.		of Source Routes that each Target should convey to the Origin.
	When hop-by-hop routes are being discovered, the N field MUST be		When Hop-by-hop Routes are being discovered, the N field MUST be
	set to zero on transmission and ignored on reception.		set to zero on transmission and ignored on reception.
	o Compr: 4-bit unsigned integer indicating the number of prefix		o Compr: 4-bit unsigned integer indicating the number of prefix
	octets that are elided from the Target field and the Address		octets that are elided from the Target field and the Address
	vector. For example, Compr value will be zero if full IPv6		vector. For example, Compr value will be zero if full IPv6
	addresses are carried in the Target field and the Address vector.		addresses are carried in the Target field and the Address vector.
	o Life Time (L): A 2-bit field that indicates the suggested life		o Life Time (L): A 2-bit field that indicates the minimum life time
	time of the temporary DAG, i.e., the suggested duration a router		of the temporary DAG, i.e., the minimum duration a router joining
	joining the temporary DAG SHOULD maintain its membership in the		the temporary DAG MUST maintain its membership in the DAG. The
	DAG. The mapping between the values in this field and the life		mapping between the values in this field and the life time of the
	time of the temporary DAG is as follows:		temporary DAG is as follows:
	* 0x00: 1 second;		* 0x00: 1 second;
	* 0x01: 4 seconds;		* 0x01: 4 seconds;
	* 0x02: 16 seconds;		* 0x02: 16 seconds;
	* 0x03: 64 seconds;		* 0x03: 64 seconds;
	The origin sets this field based on its expectation regarding the		The Origin sets this field based on its expectation regarding the
	time required for the DIOs to reach the target(s).		time required for the route discovery to complete, which includes
			the time required for the DIOs to reach the Target(s) and the DROs
			to travel back to the Origin. While deciding the temporary DAG's
			lifetime, the Origin should also take in account the fact that all
			nodes joining the temporary DAG would need to stay in the DAG for
			at least this much time.
	o MaxRank/NH:		o MaxRank/NH:
	* When a P2P-RDO is included in a P2P mode DIO, this field		* When a P2P-RDO is included in a P2P mode DIO, this field
	indicates the upper limit on the integer portion of the rank		indicates the upper limit on the integer portion of the rank
	(calculated using the DAGRank() macro defined in		(calculated using the DAGRank() macro defined in [RFC6550])
	[I-D.ietf-roll-rpl]) that a router may have in the temporary		that a router may have in the temporary DAG being created. An
	DAG being created. An intermediate router MUST NOT join a		Intermediate Router MUST NOT join a temporary DAG being created
	temporary DAG being created by a P2P mode DIO if the integer		by a P2P mode DIO if the integer portion of its rank would be
	portion of its rank would be equal to or higher (in numerical		equal to or higher (in numerical value) than the MaxRank limit.
	value) than the MaxRank limit. A target can join the temporary		A Target can join the temporary DAG at a rank whose integer
	DAG at a rank whose integer portion is equal to the MaxRank. A		portion is equal to the MaxRank. A router MUST discard a
	router MUST discard a received P2P mode DIO if the integer part		received P2P mode DIO if the integer part of the advertized
	of the advertized rank equals or exceeds the MaxRank limit. A		rank equals or exceeds the MaxRank limit. A value 0 in this
	value 0 in this field indicates that the MaxRank is infinity.		field indicates that the MaxRank is infinity.
	* When a P2P-RDO is included in a DRO message, this field		* When a P2P-RDO is included in a DRO message, this field
	indicates the index of the next hop address inside the Address		indicates the index of the next hop address inside the Address
	vector.		vector.
	o Target: An IPv6 address of the target after eliding Compr number		o Target: An IPv6 address of the Target after eliding Compr number
	of prefix octets. When the P2P-RDO is included in a P2P mode DIO,		of prefix octets. When the P2P-RDO is included in a P2P mode DIO,
	this field may contain a unicast address or a multicast one. Any		this field may contain a unicast address or a multicast one. Any
	additional target addresses can be specified by including one or		additional Target addresses can be specified by including one or
	more RPL Target Options [I-D.ietf-roll-rpl] in the DIO. When the		more RPL Target Options [RFC6550] in the DIO. When the P2P-RDO is
	P2P-RDO is included in a DRO, this field MUST contain a unicast		included in a DRO, this field MUST contain a unicast IPv6 address
	IPv6 address of the target generating the DRO.		of the Target generating the DRO.
	o Address[1..n]: A vector of IPv6 addresses representing a (partial)		o Address[1..n]: A vector of IPv6 addresses representing a (partial)
	route in the forward direction:		route in the Forward direction:
	* Each element in the Address vector has size (16 - Compr) octets		* Each element in the Address vector has size (16 - Compr) octets
	and MUST contain a valid IPv6 address with first Compr octets		and MUST contain a valid IPv6 address with first Compr octets
	elided.		elided.
	* The total number of elements inside the Address vector is given		* The total number of elements inside the Address vector is given
	by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).		by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).
	* The IPv6 addresses in the Address vector MUST be reachable in		* The IPv6 addresses in the Address vector MUST be reachable in
	both forward and backward directions. Reachability in the		both Forward and Backward directions. Reachability in the
	backward direction allows a DRO message to use the route		Backward direction allows a DRO message to use the route
	accumulated in the Address vector to travel from the target to		accumulated in the Address vector to travel from the Target to
	the origin.		the Origin.
	* The Address vector MUST carry the accumulated route in the		* The Address vector MUST carry the accumulated route in the
	forward direction, i.e., the first element in the Address		Forward direction, i.e., the first element in the Address
	vector must contain the IPv6 address of the router next to the		vector must contain the IPv6 address of the router next to the
	origin and so on.		Origin and so on.
	* The origin and target addresses MUST NOT be included in the		* The Origin and Target addresses MUST NOT be included in the
	Address vector.		Address vector.
	* A router adding its address to the vector MUST ensure that its		* A router adding its address to the vector MUST ensure that its
	address does not already exist in the vector. A router		address does not already exist in the vector. A router
	specifying a complete route in the Address vector MUST ensure		specifying a complete route in the Address vector MUST ensure
	that the vector does not contain any address more than once.		that the vector does not contain any address more than once.
	* The Address vector MUST NOT contain any multicast addresses.		* The Address vector MUST NOT contain any multicast addresses.
	7.2. Data Option		7.2. Data Option
	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 = 11 | Option Length | Data |		| Type = 11 | Option Length | SeqNo | Upper | Data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	Figure 2: Format of Data Option		Figure 2: Format of Data Option
	The format of a Data Option is illustrated in Figure 2. A P2P mode		The format of a Data Option is illustrated in Figure 2. A P2P mode
	DIO and a DRO (defined in Section 8) message MAY carry one or more		DIO and a DRO (defined in Section 8) message MAY carry one or more
	Data Options. A P2P-RDO consists of the following fields:		Data Options. A P2P-RDO consists of the following fields:
	o Option Type: 0x0B (to be confirmed by IANA).		o Option Type: 0x0B (to be confirmed by IANA).
	o Option Length: 8-bit unsigned integer, representing the length in		o Option Length: An 8-bit unsigned integer, representing the length
	octets of the option, not including the Option Type and Option		in octets of the option, not including the Option Type and Option
	Length fields.		Length fields.
			o SeqNo: A 4-bit field representing the sequence number of the data
			carried by the Data Option.
			o Upper: A 4-bit field that identifies the upper layer protocol
			header with which the information in the Data field starts. A
			value 0x00 in this field identifies UDP as the upper layer
			protocol. The other values are reserved at present.
	o Data: If the Data Option is contained in a DIO, this field		o Data: If the Data Option is contained in a DIO, this field
	contains application data to be delivered to the target(s). If		contains application data to be delivered to the Target(s). If
	the Data Option is contained in a DRO, this field contains		the Data Option is contained in a DRO, this field contains
	application data to be delivered to the origin.		application data to be delivered to the Origin.
	8. The Discovery Reply Object (DRO)		8. The Discovery Reply Object (DRO)
	This section defines two new RPL Control Message types, the Discovery		This section defines two new RPL Control Message types, the Discovery
	Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the		Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the
	Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves		Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves
	one of the following functions:		one of the following functions:
	o Carry a discovered source route from a target to the origin;		o Carry a discovered Source Route from a Target to the Origin;
	o Establish a hop-by-hop route as it travels from a target to the		o Establish a Hop-by-hop Route as it travels from a Target to the
	origin.		Origin.
	A DRO message MAY serve the function of letting the routers in the		A DRO message MAY serve the function of letting the routers in the
	LLN know that a P2P-RPL route discovery is complete and no more DIO		LLN know that a P2P-RPL route discovery is complete and no more DIO
	messages need to be generated for the corresponding temporary DAG. A		messages need to be generated for the corresponding temporary DAG. A
	DRO message MAY also carry time-critical application data from the		DRO message MAY also carry time-critical application data from the
	target to the origin in one or more Data Options. A DRO message MUST		Target to the Origin in a Data Option. A DRO message MUST carry one
	carry one P2P-RDO whose Target field MUST contain a unicast IPv6		P2P-RDO whose Target field MUST contain a unicast IPv6 address of the
	address of the target that generated the DRO. A DRO message travels		Target that generated the DRO. A DRO message travels from the Target
	from the target to the origin via link-local multicast along the		to the Origin via link-local multicast along the route specified
	route specified inside the Address vector in the P2P-RDO.		inside the Address vector in the P2P-RDO.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RPLInstanceID | Version |S|A|Seq| Reserved |		| RPLInstanceID | Version |S|A|Seq| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| DODAGID |		| DODAGID |
	| |		| |
	| |		| |
	skipping to change at page 15, line 30		skipping to change at page 16, line 38
	The format of the base Discovery Reply Object (DRO) is shown in		The format of the base Discovery Reply Object (DRO) is shown in
	Figure 3. A base DRO consists of the following fields:		Figure 3. A base DRO consists of the following fields:
	o RPLInstanceID: The RPLInstanceID of the temporary DAG used for		o RPLInstanceID: The RPLInstanceID of the temporary DAG used for
	route discovery.		route discovery.
	o Version: The Version of the temporary DAG used for route		o Version: The Version of the temporary DAG used for route
	discovery. Since a temporary DAG always has value zero for the		discovery. Since a temporary DAG always has value zero for the
	Version, this field MUST always be set to zero.		Version, this field MUST always be set to zero.
	o Stop (S): This flag, when set to one by a target, indicates that		o Stop (S): This flag, when set to one by a Target, indicates that
	the P2P-RPL route discovery is over. All the routers receiving		the P2P-RPL route discovery is over. All the routers receiving
	such a DRO, including the ones not listed in the route carried		such a DRO, including the ones not listed in the route carried
	inside P2P-RDO,		inside P2P-RDO,
	* SHOULD NOT process any more DIOs received for this temporary		* SHOULD NOT process any more DIOs received for this temporary
	DAG;		DAG;
	* SHOULD NOT generate any more DIOs for this temporary DAG;		* SHOULD NOT generate any more DIOs for this temporary DAG;
	* SHOULD cancel any pending DIO transmission for this temporary		* SHOULD cancel any pending DIO transmission for this temporary
	DAG.		DAG.
	Note that the stop flag serves to stop further DIO generation/		Note that the stop flag serves to stop further DIO generation/
	processing for a P2P-RPL route discovery but it does not affect		processing for a P2P-RPL route discovery but it does not affect
	the processing of DRO messages at either the origin or the		the processing of DRO messages at either the Origin or the
	intermediate routers. In other words, a router (the origin or an		Intermediate Routers. In other words, a router (the Origin or an
	intermediate router) MUST continue to process the DRO messages		Intermediate Router) MUST continue to process the DRO messages
	even if an earlier DRO message (with same RPLInstanceID and		even if an earlier DRO message (with the same RPLInstanceID and
	DODAGID fields) had the stop flag set to one.		DODAGID fields) had the stop flag set to one.
	o Ack Required (A): This flag, when set to one by the target,		o Ack Required (A): This flag, when set to one by the Target,
	indicates that the origin MUST unicast a DRO-ACK message (defined		indicates that the Origin MUST unicast a DRO-ACK message (defined
	in Section 10) to the target when it receives the DRO.		in Section 10) to the Target when it receives the DRO.
	o Sequence Number (Seq): This 2-bit field indicates the sequence		o Sequence Number (Seq): This 2-bit field indicates the sequence
	number for the DRO. This field is relevant when the A flag is set		number for the DRO. This field is relevant when the A flag is set
	to one, i.e., the target requests an acknowledgement from the		to one, i.e., the Target requests an acknowledgement from the
	origin for a received DRO. The origin includes the RPLInstanceID,		Origin for a received DRO. The Origin includes the RPLInstanceID,
	the DODAGID and the Sequence Number of the received DRO inside the		the DODAGID and the Sequence Number of the received DRO inside the
	DRO-ACK message it sends back to the target.		DRO-ACK message it sends back to the Target.
	o Reserved: These bits are reserved for future use. These bits MUST		o Reserved: These bits are reserved for future use. These bits MUST
	be set to zero on transmission and MUST be ignored on reception.		be set to zero on transmission and MUST be ignored on reception.
	o DODAGID: The DODAGID of the temporary DAG used for route		o DODAGID: The DODAGID of the temporary DAG used for route
	discovery. The DODAGID also identifies the origin. The		discovery. The DODAGID also identifies the Origin. The
	RPLInstanceID, the Version and the DODAGID together uniquely		RPLInstanceID, the Version and the DODAGID together uniquely
	identify the temporary DAG used for route discovery and can be		identify the temporary DAG used for route discovery and can be
	copied from the DIO message advertizing the temporary DAG.		copied from the DIO message advertizing the temporary DAG.
	o Options: The DRO message:		o Options: The DRO message:
	* MUST carry one P2P-RDO that MUST specify a complete route		* MUST carry one P2P-RDO that MUST specify a complete route
	between the target and the origin;		between the Target and the Origin;
	* MAY carry one or more Metric Container Options that contains		* MAY carry one or more Metric Container Options that contains
	the aggregated routing metrics values for the route specified		the aggregated routing metrics values for the route specified
	in P2P-RDO;		in P2P-RDO;
	* MAY carry one or more Data Options to carry any time-critical		* MAY carry one Data Option to carry any time-critical
	application data to the origin.		application data to the Origin.
	8.1. Secure DRO		8.1. Secure DRO
	A Secure DRO message follows the format in Figure 7 of		A Secure DRO message follows the format in Figure 7 of [RFC6550],
	[I-D.ietf-roll-rpl], where the base format is the base DRO shown in		where the base format is the base DRO shown in Figure 3.
	Figure 3.
	8.2. Setting a P2P-RDO Carried in a Discovery Reply Object		8.2. Setting a P2P-RDO Carried in a Discovery Reply Object
	A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as		A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as
	defined in Section 7.1. Specifically, the following fields MUST be		defined in Section 7.1. Specifically, the following fields MUST be
	set as specified next:		set as specified next:
	o Reply (R): This flag MUST be set to zero on transmission and		o Reply (R): This flag MUST be set to zero on transmission and
	ignored on reception.		ignored on reception.
	skipping to change at page 17, line 16		skipping to change at page 18, line 25
	message MUST have the same value as the H flag in the P2P-RDO		message MUST have the same value as the H flag in the P2P-RDO
	inside the corresponding DIO message.		inside the corresponding DIO message.
	o Number of Routes (N): This field MUST be set to zero on		o Number of Routes (N): This field MUST be set to zero on
	transmission and ignored on reception.		transmission and ignored on reception.
	o Life Time (L): This field MUST be set to zero on transmission and		o Life Time (L): This field MUST be set to zero on transmission and
	ignored on reception.		ignored on reception.
	o MaxRank/NH: This field indicates the index of the next hop address		o MaxRank/NH: This field indicates the index of the next hop address
	in the Address vector. When a target generates a DRO message, the		in the Address vector. When a Target generates a DRO message, the
	NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 -		NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 -
	Compr).		Compr).
	o Target: This field MUST contain a unicast IPv6 address of the		o Target: This field MUST contain a unicast IPv6 address of the
	target generating the DRO.		Target generating the DRO.
	o Address[1..n]: The Address vector MUST contain a complete route		o Address[1..n]: The Address vector MUST contain a complete route
	between the origin and the target such that the first element in		between the Origin and the Target such that the first element in
	the vector contains the IPv6 address of the router next to the		the vector contains the IPv6 address of the router next to the
	origin and the last element contains the IPv6 address of the		Origin and the last element contains the IPv6 address of the
	router next to the target.		router next to the Target.
	9. P2P-RPL Route Discovery By Creating a Temporary DAG		9. P2P-RPL Route Discovery By Creating a Temporary DAG
	This section details the P2P-RPL route discovery operation.		This section details the P2P-RPL route discovery operation.
	9.1. Joining a Temporary DAG		9.1. Joining a Temporary DAG
	All the routers participating in a P2P-RPL route discovery, including		All the routers participating in a P2P-RPL route discovery, including
	the origin and the target(s), MUST join the temporary DAG being		the Origin and the Target(s), MUST join the temporary DAG being
	created for the purpose. When a router joins a temporary DAG		created for the purpose. When a router joins a temporary DAG
	advertized by a P2P mode DIO, it SHOULD maintain its membership in		advertized by a P2P mode DIO, it SHOULD maintain its membership in
	the temporary DAG for the suggested Life Time duration listed in the		the temporary DAG for the suggested Life Time duration listed in the
	P2P-RDO. The only purpose of a temporary DAG's existence is to		P2P-RDO. The only purpose of a temporary DAG's existence is to
	facilitate the P2P-RPL route discovery process. The temporary DAG		facilitate the P2P-RPL route discovery process. The temporary DAG
	MUST NOT be used to route packets. A router SHOULD detach from the		MUST NOT be used to route packets. A router SHOULD detach from the
	temporary DAG once the duration of its membership in the DAG has		temporary DAG once the duration of its membership in the DAG has
	exceeded the DAG's suggested life time. After receiving a DRO with		exceeded the DAG's life time. After receiving a DRO with the stop
	the stop flag set to one, a router SHOULD NOT send or receive any		flag set to one, a router SHOULD NOT send or receive any more DIOs
	more DIOs for this temporary DAG and SHOULD also cancel any pending		for this temporary DAG and SHOULD also cancel any pending DIO
	DIO transmission.		transmission.
	9.2. Trickle Operation For P2P Mode DIOs		9.2. Trickle Operation For P2P Mode DIOs
	An RPL router uses a Trickle timer [RFC6206] to control DIO		An RPL router uses a Trickle timer [RFC6206] to control DIO
	transmissions. The Trickle control of DIO transmissions provides		transmissions. The Trickle control of DIO transmissions provides
	quick resolution of any "inconsistency" while avoiding redundant DIO		quick resolution of any "inconsistency" while avoiding redundant DIO
	transmissions. The Trickle algorithm also imparts protection against		transmissions. The Trickle algorithm also imparts protection against
	loss of DIOs due to inherent lack of reliability in wireless		loss of DIOs due to inherent lack of reliability in LLNs. When
	communication. When controlling the transmissions of a P2P mode DIO,		controlling the transmissions of a P2P mode DIO, a Trickle timer
	a Trickle timer SHOULD follow the following rules:		SHOULD follow the following rules:
	o The receipt of a P2P mode DIO, that allows the router to advertise		o The receipt of a P2P mode DIO, that allows the router to advertise
	a better route (in terms of the routing metrics and the OF in use)		a better route (in terms of the routing metrics and the OF in use)
	than before, is considered "inconsistent" and hence resets the		than before, is considered "inconsistent" and hence resets the
	Trickle timer. Note that the first receipt of a P2P mode DIO		Trickle timer. Note that the first receipt of a P2P mode DIO
	advertising a particular temporary DAG is always considered an		advertising a particular temporary DAG is always considered an
	"inconsistent" event.		"inconsistent" event.
	o The receipt of a P2P mode DIO from a parent in the temporary DAG		o The receipt of a P2P mode DIO from a parent in the temporary DAG
	is considered neither "consistent" nor "inconsistent" if it does		is considered neither "consistent" nor "inconsistent" if it does
	skipping to change at page 19, line 6		skipping to change at page 20, line 12
	what the router advertises (or would advertise when it gets a		what the router advertises (or would advertise when it gets a
	chance to generate its DIO), is considered neither "consistent"		chance to generate its DIO), is considered neither "consistent"
	nor "inconsistent", i.e., the receipt of such a DIO has no impact		nor "inconsistent", i.e., the receipt of such a DIO has no impact
	on the Trickle operation.		on the Trickle operation.
	o The Imin parameter SHOULD be set taking in account the		o The Imin parameter SHOULD be set taking in account the
	connectivity within the network. For highly connected networks, a		connectivity within the network. For highly connected networks, a
	small Imin value (of the order of the typical transmission delay		small Imin value (of the order of the typical transmission delay
	for a DIO) may lead to congestion in the network as a large number		for a DIO) may lead to congestion in the network as a large number
	of routers reset their Trickle timers in response to the first		of routers reset their Trickle timers in response to the first
	receipt of a DIO from the origin. These routers would generate		receipt of a DIO from the Origin. These routers would generate
	their DIOs within Imin interval and cause additional routers to		their DIOs within Imin interval and cause additional routers to
	reset their trickle timers and generate more DIOs. Thus, for		reset their trickle timers and generate more DIOs. Thus, for
	highly connected networks, the Imin parameter SHOULD be set to a		highly connected networks, the Imin parameter SHOULD be set to a
	value at least one order of magnitude larger than the typical		value at least one order of magnitude larger than the typical
	transmission delay for a DIO. For sparsely connected networks,		transmission delay for a DIO. For sparsely connected networks,
	the Imin parameter can be set to a value that is a small multiple		the Imin parameter can be set to a value that is a small multiple
	of the typical transmission delay for a DIO. Note that the Imin		of the typical transmission delay for a DIO. Note that the Imin
	value has a direct impact on the time required for a P2P-RPL route		value has a direct impact on the time required for a P2P-RPL route
	discovery to complete. In general, the time required for a P2P-		discovery to complete. In general, the time required for a P2P-
	RPL route discovery would increase approximately linearly with the		RPL route discovery would increase approximately linearly with the
	skipping to change at page 19, line 40		skipping to change at page 20, line 46
	receives even a single "consistent" DIO during a timer interval.		receives even a single "consistent" DIO during a timer interval.
	This setting for the redundancy constant is designed to reduce the		This setting for the redundancy constant is designed to reduce the
	number of messages generated during a route discovery process and		number of messages generated during a route discovery process and
	is suitable for environments with low or moderate packet loss		is suitable for environments with low or moderate packet loss
	rates. In environments with high packet loss rates, a higher		rates. In environments with high packet loss rates, a higher
	value for the redundancy constant may be more suitable.		value for the redundancy constant may be more suitable.
	9.3. Processing a P2P Mode DIO		9.3. Processing a P2P Mode DIO
	The rules for DIO processing and transmission, described in Section 8		The rules for DIO processing and transmission, described in Section 8
	of RPL [I-D.ietf-roll-rpl], apply to P2P mode DIOs as well except as		of RPL [RFC6550], apply to P2P mode DIOs as well except as modified
	modified in this document.		in this document.
	The following rules for processing a received P2P mode DIO apply to		The following rules for processing a received P2P mode DIO apply to
	both intermediate routers and the target.		both Intermediate Routers and the Target.
	A router SHOULD discard a received P2P mode DIO with no further		A router SHOULD discard a received P2P mode DIO with no further
	processing if it does not have bidirectional reachability with the		processing if it does not have bidirectional reachability with the
	neighbor that generated the received DIO. Note that bidirectional		neighbor that generated the received DIO. Note that bidirectional
	reachability does not mean that the link must have the same values		reachability does not mean that the link must have the same values
	for a routing metric in both directions. A router SHOULD calculate		for a routing metric in both directions. A router SHOULD calculate
	the values of the link-level routing metrics included in the received		the values of the link-level routing metrics included in the received
	DIO taking in account the metric's value in both forward and backward		DIO taking in account the metric's value in both forward and Backward
	directions. Bidirectional reachability along a discovered route		directions. Bidirectional reachability along a discovered route
	allows the target to use this route to reach the origin. In		allows the Target to use this route to reach the Origin. In
	particular, the DRO messages travel from the target to the origin		particular, the DRO messages travel from the Target to the Origin
	along a discovered route.		along a discovered route.
	A router MUST discard a received P2P mode DIO with no further		A router MUST discard a received P2P mode DIO with no further
	processing:		processing:
	o If the DIO advertises INFINITE_RANK as defined in		o If the DIO advertises INFINITE_RANK as defined in [RFC6550].
	[I-D.ietf-roll-rpl].
	o If the integer part of the rank advertised in the DIO equals or		o If the integer part of the rank advertised in the DIO equals or
	exceeds the MaxRank limit listed in the P2P Route Discovery		exceeds the MaxRank limit listed in the P2P Route Discovery
	Option.		Option.
	o If the router cannot evaluate the mandatory route constraints		o If the router cannot evaluate the mandatory route constraints
	listed in the DIO or if the routing metric values do not satisfy		listed in the DIO or if the routing metric values do not satisfy
	one or more of the mandatory constraints.		one or more of the mandatory constraints.
	o If the router previously received a DRO message with same		o If the router previously received a DRO message with the same
	RPLInstanceID and DODAGID as the received DIO and with the stop		RPLInstanceID and DODAGID as the received DIO and with the stop
	flag set to one.		flag set to one.
	The router MUST check the target addresses listed in the P2P-RDO and		The router MUST check the Target addresses listed in the P2P-RDO and
	any RPL Target Options included in the received DIO. If one of its		any RPL Target Options included in the received DIO. If one of its
	IPv6 addresses is listed as a target address or if it belongs to the		IPv6 addresses is listed as a Target address or if it belongs to the
	multicast group specified as one of the target addresses, the router		multicast group specified as one of the Target addresses, the router
	considers itself a target and processes the received DIO as specified		considers itself a Target and processes the received DIO as specified
	in Section 9.5. Otherwise, the router considers itself an		in Section 9.5. Otherwise, the router considers itself an
	intermediate router and processes the received DIO as specified in		Intermediate Router and processes the received DIO as specified in
	Section 9.4.		Section 9.4.
	9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router		9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router
	An intermediate router MUST discard a received P2P mode DIO with no		An Intermediate Router MUST discard a received P2P mode DIO with no
	further processing if the router cannot elide Compr (as specified in		further processing if the router cannot elide Compr (as specified in
	the P2P-RDO) prefix octets from its IPv6 address.		the P2P-RDO) prefix octets from its IPv6 address.
	On receiving a P2P mode DIO, an intermediate router MUST determine		On receiving a P2P mode DIO, an Intermediate Router MUST do the
	whether this DIO advertises a better route than the router itself and		following:
	whether the receipt of the DIO would allow the router to advertise a
	better route than before. Accordingly, the router SHOULD consider		o The router updates the Data Option to be carried in the router's
	this DIO as consistent/inconsistent from Trickle perspective as		DIOs if the one in the received DIO has a higher sequence number
	described in Section 9.2. Note that the route comparison in a P2P-		than what the router currently has (or if the router currently is
	RPL route discovery is performed using the parent selection rules of		not aware of any Data Option).
	the OF in use as specified in Section 14 of RPL [I-D.ietf-roll-rpl].
	If the received DIO would allow the router to advertise a better		o The router determines whether this DIO advertises a better route
	route, the router MUST remember the route advertised (inside the P2P-		than the router itself and whether the receipt of the DIO would
	RDO) in the DIO (after adding its own IPv6 address to the route) as		allow the router to advertise a better route than before.
	well as any Data Options for inclusion in its future DIOs. When an		Accordingly, the router SHOULD consider this DIO as consistent/
	intermediate router adds itself to a route, it MUST ensure that the		inconsistent from Trickle perspective as described in Section 9.2.
	IPv6 address added to the route is reachable in both forward and		Note that the route comparison in a P2P-RPL route discovery is
	backward directions. To improve the diversity of the routes being		performed using the parent selection rules of the OF in use as
	discovered, an intermediate router SHOULD keep track of multiple		specified in Section 14 of RPL [RFC6550]. If the received DIO
	partial routes to be advertised in the P2P-RDO inside its DIO. When		would allow the router to advertise a better route, the router
	the router generates its DIO, it SHOULD randomly select the partial		MUST remember the route advertised (inside the P2P-RDO) in the DIO
	route to be included in the P2P-RDO.		(after adding its own IPv6 address to the route) for inclusion in
			its future DIOs. When an Intermediate Router adds itself to a
			route, it MUST ensure that the IPv6 address added to the route is
			reachable in both Forward and Backward directions. To improve the
			diversity of the routes being discovered, an Intermediate Router
			SHOULD keep track of multiple partial routes to be advertised in
			the P2P-RDO inside its DIO. When the router generates its DIO, it
			SHOULD randomly select the partial route to be included in the
			P2P-RDO. Note that the route accumulation in a P2P mode DIO MUST
			take place even if the Origin does not want any DRO messages to be
			generated (i.e., the R flag inside the P2P-RDO is set to zero).
			This is because the Target may still be able to use the
			accumulated route as a source route to reach the Origin.
	9.5. Additional Processing of a P2P Mode DIO At The Target		9.5. Additional Processing of a P2P Mode DIO At The Target
	The target MUST deliver the data contained in any Data Options in the		The Target MUST determine if the received DIO contains a Data Option
	received DIO to the application layer. The target MAY store the		and deliver the data to the specified upper layer protocol if the
	route contained in the P2P-RDO in the received DIO for use as a		option's sequence number is higher than that of the options in the
	source route to reach the origin. If the Reply flag inside the P2P-		previously received DIOs for this route discovery (or if the DIOs
	RDO is zero, the target MUST discard the received DIO with no further		received earlier did not have a Data Option). If this route
	processing. Otherwise, the target MAY select the route contained in		discovery involves multiple Targets, the Target MUST remember the
	the P2P-RDO to send a DRO message back to the origin. If the H flag		Data Option with highest sequence number for inclusion in its own
	inside the P2P-RDO is one, the target needs to select one route and		DIOs.
	send a DRO message along this route back to the origin. If the H
	flag is zero, the number of routes to be selected (and the number of
	DRO messages to be sent back) is given by one plus the value of the N
	field in the P2P-RDO. This document does not prescribe a particular
	method for the target to select the routes. Example methods include
	selecting each route that meets the specified routing constraints
	until the desired number have been selected or selecting the best
	routes discovered over a certain time period. If multiple routes are
	to be selected, the target SHOULD avoid selecting routes that have
	large segments in common.
	If the target selects the route contained in the P2P-RDO in the		The Target MAY store the route contained in the P2P-RDO in the
	received DIO, it sends a DRO message back to the origin (identified		received DIO for use as a Source Route to reach the Origin. The
			lifetime of this Source Route is specified by the Default Lifetime
			and Lifetime Unit parameters inside the DODAG Configuration Option
			currently in effect. This lifetime can be extended (or shortened)
			appropriately following a hint from an upper-layer protocol.
			If the Reply flag inside the P2P-RDO in the received DIO is zero, the
			Target MUST discard the received DIO with no further processing.
			Otherwise, the Target MAY select the route contained in the P2P-RDO
			to send a DRO message back to the Origin. If the H flag inside the
			P2P-RDO is one, the Target needs to select one route and send a DRO
			message along this route back to the Origin. If the H flag is zero,
			the number of routes to be selected (and the number of DRO messages
			to be sent back) is given by one plus the value of the N field in the
			P2P-RDO. This document does not prescribe a particular method for
			the Target to select the routes. Example methods include selecting
			each route that meets the specified routing constraints until the
			desired number have been selected or selecting the best routes
			discovered over a certain time period. If multiple routes are to be
			selected, the Target SHOULD avoid selecting routes that have large
			segments in common.
			If the Target selects the route contained in the P2P-RDO in the
			received DIO, it sends a DRO message back to the Origin (identified
	by the DODAGID field in the DIO). The DRO message MUST include a		by the DODAGID field in the DIO). The DRO message MUST include a
	P2P-RDO that contains the selected route inside the Address vector.		P2P-RDO that contains the selected route inside the Address vector.
	Various fields inside the P2P-RDO MUST be set as specified in		Various fields inside the P2P-RDO MUST be set as specified in
	Section 8.2. The target MAY set the A flag inside the DRO message to		Section 8.2. The Target MAY set the A flag inside the DRO message to
	one if it desires the origin to send back a DRO-ACK message on		one if it desires the Origin to send back a DRO-ACK message on
	receiving the DRO. In this case, the target waits for		receiving the DRO. In this case, the Target waits for
	DRO_ACK_WAIT_TIME duration for the DRO-ACK message to arrive.		DRO_ACK_WAIT_TIME duration for the DRO-ACK message to arrive.
	Failure to receive the DRO-ACK message within this time duration		Failure to receive the DRO-ACK message within this time duration
	causes the target to retransmit the DRO message. The target MAY		causes the Target to retransmit the DRO message. The Target MAY
	retransmit the DRO message in this fashion up to		retransmit the DRO message in this fashion up to
	MAX_DRO_RETRANSMISSIONS times. The values of DRO_ACK_WAIT_TIME and		MAX_DRO_RETRANSMISSIONS times. Both DRO_ACK_WAIT_TIME and
	MAX_DRO_RETRANSMISSIONS are defined in Section 12.		MAX_DRO_RETRANSMISSIONS are configurable parameters to be decided
			based on the characteristics of individual deployments. Note that
			all DRO transmissions and retransmissions MUST take place while the
			Target is still a part of the temporary DAG created for the route
			discovery. A Target MUST NOT transmit a DRO if it no longer belongs
			to this DAG.
	The target MAY set the stop flag inside the DRO message to one if		The Target MAY set the stop flag inside the DRO message to one if
	o this router is the only target specified in the corresponding DIO,
			o this router is the only Target specified in the corresponding DIO,
	i.e., the corresponding DIO specified a unicast address of the		i.e., the corresponding DIO specified a unicast address of the
	router as the Target inside the P2P-RDO with no additional targets		router as the Target inside the P2P-RDO with no additional Targets
	specified via RPL Target Options; and		specified via RPL Target Options; and
	o the target has already selected the desired number of routes.		o the Target has already selected the desired number of routes.
	The target MAY include a Metric Container Option in the DRO message.		The Target MAY include a Metric Container Option in the DRO message.
	This Metric Container contains the end-to-end routing metric values		This Metric Container contains the end-to-end routing metric values
	for the route specified in the P2P-RDO. The target MAY include one		for the route specified in the P2P-RDO. The Target MAY include one
	or more Data Options in the DRO message to carry time-critical		Data Option in the DRO message to carry time-critical application
	application data for the origin. The target MUST transmit the DRO		data for the Origin. Note that this Data Option is not same as the
	message via a link-local multicast.		Data Option that the Target may include in the DIOs it generates for
			this route discovery (if the route discovery involves multiple
			Targets). The Target MUST transmit the DRO message via a link-local
			multicast.
	A target MUST NOT forward a P2P mode DIO any further.		A Target MUST NOT forward a P2P mode DIO any further if no other
			Targets are to be discovered, i.e., if a unicast IPv6 address (of
			this Target) is specified as the Target inside the P2P-RDO and no
			additional Targets are specified via RPL Target Options inside the
			DIOs for this route discovery. Otherwise, the Target MUST generate
			DIOs for this route discovery as an Intermediate Router would.
	9.6. Processing a DRO At An Intermediate Router		9.6. Processing a DRO At An Intermediate Router
	When a router receives a DRO message that does not list its IPv6		If the DODAGID field in the received DRO does not list a router's own
	address in the DODAGID field, the router MUST process the received		IPv6 address, the router considers itself an Intermediate Router and
	message in the following manner:		MUST process the received message in the following manner:
			o The router MUST discard the received DRO with no further
			processing if it does not belong to the temporary DAG identified
			by the RPLInstanceID and the DODAGID fields in the DRO.
	o If the stop flag inside the received DRO is set to one, the router		o If the stop flag inside the received DRO is set to one, the router
	SHOULD NOT send or receive any more DIOs for this temporary DAG		SHOULD NOT send or receive any more DIOs for this temporary DAG
	and SHOULD cancel any pending DIO transmission.		and SHOULD cancel any pending DIO transmission.
	o An intermediate router MUST ignore any Metric Container and Data		o The router MUST ignore any Metric Container and Data Options
	Options contained in the DRO message.		contained in the DRO message.
	o If Address[NH] element inside the Route Discovery Option lists the		o If Address[NH] element inside the P2P-RDO lists the router's own
	router's own IPv6 address, the router is a part of the route		unicast IPv6 address, the router is a part of the route carried in
	carried in the P2P-RDO. In this case, the router MUST do the		the P2P-RDO. In this case, the router MUST do the following:
	following:
			* To prevent loops, the router MUST discard the DRO message with
			no further processing if the Address vector in the P2P-RDO
			includes multiple IPv6 addresses assigned to the router's
			interfaces and if such addresses do not appear back to back
			inside the Address vector.
	* If the H flag inside the P2P-RDO is one, the router MUST store		* If the H flag inside the P2P-RDO is one, the router MUST store
	the state for the forward hop-by-hop route carried inside the		the state for the forward hop-by-hop route carried inside the
	P2P-RDO. This state consists of:		P2P-RDO. This state consists of:
	+ The RPLInstanceID and the DODAGID fields of the DRO.		+ The RPLInstanceID and the DODAGID fields of the DRO.
	+ The route's destination, the target (identified by Target		+ The route's destination, the Target (identified by Target
	field inside P2P-RDO).		field inside P2P-RDO).
	+ The IPv6 address of the next hop, Address[NH+1] (unless NH		+ The IPv6 address of the next hop, Address[NH+1] (unless NH
	value equals the number of elements in the Address vector,		value equals the number of elements in the Address vector,
	in which case the target itself is the next hop).		in which case the Target itself is the next hop).
			This hop-by-hop routing state MUST expire at the end of the
			lifetime specified by the Default Lifetime and Lifetime Unit
			parameters inside the DODAG Configuration Option used in P2P
			mode DIOs for this route discovery.
	* If the router already maintains a hop-by-hop state listing the		* If the router already maintains a hop-by-hop state listing the
	target as the destination and carrying same RPLInstanceID and		Target as the destination and carrying same RPLInstanceID and
	DODAGID fields as the received DRO and the next hop information		DODAGID fields as the received DRO and the next hop information
	in the state does not match the next hop indicated in the		in the state does not match the next hop indicated in the
	received DRO, the router MUST drop the DRO message with no		received DRO, the router MUST discard the DRO message with no
	further processing.		further processing.
	* The router MUST decrement the NH field inside the P2P-RDO and		* The router MUST decrement the NH field inside the P2P-RDO and
	send the DRO further via link-local multicast.		send the DRO further via link-local multicast.
	9.7. Processing a DRO At The Origin		9.7. Processing a DRO At The Origin
	When a router receives a DRO message that lists its IPv6 address in		When a router receives a DRO message that lists its IPv6 address in
	the DODAGID field, the router recognizes itself as the origin for the		the DODAGID field, the router recognizes itself as the Origin for the
	corresponding P2P-RPL route discovery and processes the message in		corresponding P2P-RPL route discovery and processes the message in
	the following manner.		the following manner:
	The origin MUST deliver data in any Data Options in the received DRO		o The Origin MUST discard the received DRO with no further
	to the application layer.		processing if it no longer belongs to the temporary DAG identified
			by the RPLInstanceID and the DODAGID fields in the DRO.
	If the stop flag inside the received DRO is set to one, the origin		o The Origin MUST check if the received DRO contains a Data Option
	SHOULD NOT generate any more DIOs for this temporary DAG and SHOULD		with higher sequence number than what was received previously (or
	cancel any pending DIO transmission.		if this Data Option is the first one received). In that case, the
			Origin MUST deliver the data inside the Data Option to the upper
			layer protocol identified inside the Data Option.
	If the P2P-RDO inside the DRO identifies the discovered route as a		o If the stop flag inside the received DRO is set to one, the Origin
	source route (H=0), the origin MUST store in its memory the		SHOULD NOT generate any more DIOs for this temporary DAG and
	discovered route contained in the Address vector.		SHOULD cancel any pending DIO transmission.
	If the P2P-RDO inside the DRO identifies the discovered route as a		o If the P2P-RDO inside the DRO identifies the discovered route as a
	hop-by-hop route (H=1), the origin MUST store in its memory the state		Source Route (H=0), the Origin MUST store in its memory the
	for the discovered route in the manner described in Section 9.6.		discovered route contained in the Address vector. The lifetime of
			this Source Route is specified by the Default Lifetime and
			Lifetime Unit parameters inside the DODAG Configuration Option in
			the P2P mode DIOs used for this route discovery. This lifetime
			could be extended (or shortened) appropriately following a hint
			from an upper-layer protocol.
	If the received DRO message contains one or more Metric Container		o If the P2P-RDO inside the DRO identifies the discovered route as a
	Options, the origin MAY store the values of the routing metrics		Hop-by-hop Route (H=1), the Origin MUST store in its memory the
	associated with the discovered route in its memory. This information		state for the discovered route in the manner described in
	may be useful in formulating the constraints for any future P2P-RPL		Section 9.6. This hop-by-hop routing state MUST expire at the end
	route discovery to the target.		of the lifetime specified by the Default Lifetime and Lifetime
			Unit parameters inside the DODAG Configuration Option used in P2P
			mode DIOs for this route discovery. A future version of this
			document may consider specifying a signaling mechanism that will
			allow the Origin to extend (or shorten) the lifetime of a P2P-RPL
			Hop-by-hop Route following a suitable hint from an upper-layer
			protocol.
	If the A flag is set to one in the received DRO message, the origin		o If the received DRO message contains one or more Metric Container
	MUST generate a DRO-ACK message as described in Section 10 and		Options, the Origin MAY store the values of the routing metrics
	unicast the message to the target (identified by the Target field		associated with the discovered route in its memory. This
	inside the P2P-RDO). The origin MAY use the route just discovered to		information may be useful in formulating the constraints for any
	send the DRO-ACK message to the target. Section 11 describes how a		future P2P-RPL route discovery to the Target.
	packet may be forwarded along a source/hop-by-hop route discovered
	using P2P-RPL.		o If the A flag is set to one in the received DRO message, the
			Origin MUST generate a DRO-ACK message as described in Section 10
			and unicast the message to the Target (identified by the Target
			field inside the P2P-RDO). The Origin MAY use the route just
			discovered to send the DRO-ACK message to the Target. Section 11
			describes how a packet may be forwarded along a source/Hop-by-hop
			Route discovered using P2P-RPL.
	10. The Discovery Reply Object Acknowledgement (DRO-ACK)		10. The Discovery Reply Object Acknowledgement (DRO-ACK)
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RPLInstanceID | Version |Seq| Reserved |		| RPLInstanceID | Version |Seq| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| DODAGID |		| DODAGID |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Format of the base Discovery Reply Object Acknowledgement		Figure 4: Format of the base Discovery Reply Object Acknowledgement
	(DRO-ACK)		(DRO-ACK)
	A DRO message may fail to reach the origin due to a number of		A DRO message may fail to reach the Origin due to a number of
	reasons. Unlike the DIO messages that benefit from Trickle-		reasons. Unlike the DIO messages that benefit from Trickle-
	controlled retransmissions, the DRO messages are prone to loss due to		controlled retransmissions, the DRO messages are prone to loss due to
	unreliable wireless communication. Since a DRO message travels via		unreliable packet transmission in LLNs. Since a DRO message travels
	link-local multicast, it cannot use link-level acknowledgements to		via link-local multicast, it cannot use link-level acknowledgements
	improve the reliability of its transmission. Also, an intermediate		to improve the reliability of its transmission. Also, an
	router may drop the DRO message (e.g., because of its inability to		Intermediate Router may drop the DRO message (e.g., because of its
	store the state for the hop-by-hop route the DRO is establishing).		inability to store the state for the Hop-by-hop Route the DRO is
	To protect against the potential failure of a DRO message to reach		establishing). To protect against the potential failure of a DRO
	the origin, the target MAY request the origin to send back a DRO		message to reach the Origin, the Target MAY request the Origin to
	Acknowledgement (DRO-ACK) message on receiving a DRO message.		send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO
	Failure to receive such an acknowledgement within the		message. Failure to receive such an acknowledgement within the
	DRO_ACK_WAIT_TIME interval of sending the DRO message forces the		DRO_ACK_WAIT_TIME interval of sending the DRO message forces the
	target to resend the message.		Target to resend the message.
	This section defines two new RPL Control Message types: DRO		This section defines two new RPL Control Message types: DRO
	Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA)		Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA)
	and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO-		and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO-
	ACK message MUST travel as a unicast message from the origin to the		ACK message MUST travel as a unicast message from the Origin to the
	target. The format of a base DRO-ACK message is shown in Figure 4.		Target. The format of a base DRO-ACK message is shown in Figure 4.
	Various fields in a DRO-ACK message MUST have the same values as the		Various fields in a DRO-ACK message MUST have the same values as the
	corresponding fields in the DRO message. The field marked as		corresponding fields in the DRO message. The field marked as
	"Reserved" MUST be set to zero on transmission and MUST be ignored on		"Reserved" MUST be set to zero on transmission and MUST be ignored on
	reception. A Secure DRO-ACK message follows the format in Figure 7		reception. A Secure DRO-ACK message follows the format in Figure 7
	of [I-D.ietf-roll-rpl], where the base format is same as the base		of [RFC6550], where the base format is same as the base DRO-ACK shown
	DRO-ACK shown in Figure 4.		in Figure 4.
	11. Packet Forwarding Along a Route Discovered Using P2P-RPL		11. Packet Forwarding Along a Route Discovered Using P2P-RPL
	An origin MAY use a Source Routing Header (SRH)		An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a
			packet along a Source Route discovered using P2P-RPL.
	[I-D.ietf-6man-rpl-routing-header] to send a packet along a source
	route discovered using P2P-RPL.
	Travel along a hop-by-hop route, established using P2P-RPL, requires		Travel along a Hop-by-hop Route, established using P2P-RPL, requires
	specifying the RPLInstanceID and the DODAGID (of the temporary DAG		specifying the RPLInstanceID and the DODAGID (of the temporary DAG
	used for the route discovery) to identify the route. This is because		used for the route discovery) to identify the route. This is because
	a P2P-RPL route discovery does not use globally unique RPLInstanceID		a P2P-RPL route discovery does not use globally unique RPLInstanceID
	values and hence both the RPLInstanceID (a local value assigned by		values and hence both the RPLInstanceID (a local value assigned by
	the origin) and the DODAGID (an IPv6 address of the origin) are		the Origin) and the DODAGID (an IPv6 address of the Origin) are
	required to uniquely identify a P2P-RPL hop-by-hop route to a		required to uniquely identify a P2P-RPL Hop-by-hop Route to a
	particular destination.		particular destination.
	An origin MAY include an RPL option [I-D.ietf-6man-rpl-option] inside		An Origin MAY include an RPL option [RFC6553] inside the IPv6 hop-by-
	the IPv6 hop-by-hop options header of a packet to send it along a		hop options header of a packet to send it along a Hop-by-hop Route
	hop-by-hop route established using P2P-RPL. For this purpose, the		established using P2P-RPL. For this purpose, the Origin MUST set the
	origin MUST set the DODAGID of the temporary DAG used for the route		DODAGID of the temporary DAG used for the route discovery as the
	discovery as the source IPv6 address of the packet. Further, the		source IPv6 address of the packet. Further, the Origin MUST specify
	origin MUST specify inside the RPL option the RPLInstanceID of the		inside the RPL option the RPLInstanceID of the temporary DAG used for
	temporary DAG used for the route discovery and set the O flag inside		the route discovery and set the O flag inside the RPL option to one.
	the RPL option to one. On receiving this packet, an intermediate		On receiving this packet, an Intermediate Router checks the O flag
	router checks the O flag and correctly infer the source IPv6 address		and correctly infer the source IPv6 address of the packet as the
	of the packet as the DODAGID of the hop-by-hop route. The router		DODAGID of the Hop-by-hop Route. The router then uses the DODAGID,
	then uses the DODAGID, the RPLInstanceID and the destination address		the RPLInstanceID and the destination address to identify the routing
	to identify the routing state to be used to forward the packet		state to be used to forward the packet further.
	further.
	12. Constants
	This document defines the following constants:
	o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO-
	ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a
	value of 1 second.
	o MAX_DRO_RETRANSMISSIONS: The maximum number of times a DRO message
	may be retransmitted if the target does not receive a DRO-ACK in
	response. MAX_DRO_RETRANSMISSIONS has a value 2.
	13. Interoperability with Core RPL		12. Interoperability with Core RPL
	This section describes how RPL routers that implement P2P-RPL		This section describes how RPL routers that implement P2P-RPL
	interact with RPL routers that do not. In general, P2P-RPL operation		interact with RPL routers that do not. In general, P2P-RPL operation
	does not affect core RPL operation and vice versa. However, core RPL		does not affect core RPL operation and vice versa. However, core RPL
	does allow a router to join a DAG as a leaf node even if it does not		does allow a router to join a DAG as a leaf node even if it does not
	understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL		understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL
	router that does not implement P2P-RPL may conceivably join a		router that does not implement P2P-RPL may conceivably join a
	temporary DAG being created for a P2P-RPL route discovery as a leaf		temporary DAG being created for a P2P-RPL route discovery as a leaf
	node and maintain its membership even though the DAG no longer		node and maintain its membership even though the DAG no longer
	exists. This may impose a drain on the router's memory. However,		exists. This may impose a drain on the router's memory. However,
	skipping to change at page 26, line 21		skipping to change at page 28, line 32
	join a DAG whose MOP it does not understand. Moreover, RPL routers		join a DAG whose MOP it does not understand. Moreover, RPL routers
	in a particular deployment may have strict restrictions on the DAGs		in a particular deployment may have strict restrictions on the DAGs
	they may join, thereby mitigating the problem.		they may join, thereby mitigating the problem.
	The P2P-RPL mechanism described in this document works best when all		The P2P-RPL mechanism described in this document works best when all
	the RPL routers in the LLN implement P2P-RPL. In general, the		the RPL routers in the LLN implement P2P-RPL. In general, the
	ability to discover routes as well as the quality of discovered		ability to discover routes as well as the quality of discovered
	routes would deteriorate with the fraction of RPL routers that		routes would deteriorate with the fraction of RPL routers that
	implement P2P-RPL.		implement P2P-RPL.
	14. Security Considerations		13. Security Considerations
	The security considerations for the operation of P2P-RPL are similar		A P2P-RPL deployment may be susceptible to denial of service attacks
	to the ones for the operation of RPL (as described in Section 19 of		by rogue routers that initiate fake route discoveries. A rogue
	[I-D.ietf-roll-rpl]). Section 10 of RPL specification		router could join a temporary DAG and advertise false information in
	[I-D.ietf-roll-rpl] describes a variety of security mechanisms that		its DIOs in order to include itself in the discovered route(s). It
	provide data confidentiality, authentication, replay protection and		could generate bogus DRO messages carrying bad routes or maliciously
	delay protection services. Each RPL control message has a secure		modify genuine DRO messages it receives.
	version that allows the specification of the level of security and
	the algorithms used to secure the message. The mechanism defined in		In general, the security considerations for the operation of P2P-RPL
	this document is based on the use of DIOs to form a temporary DAG and		are similar to the ones for the operation of RPL (as described in
			Section 19 of [RFC6550]). Section 10 of RPL specification [RFC6550]
			describes a variety of security mechanisms that provide data
			confidentiality, authentication, replay protection and delay
			protection services. Each RPL control message has a secure version
			that allows the specification of the level of security and the
			algorithms used to secure the message. The mechanism defined in this
			document is based on the use of DIOs to form a temporary DAG and
	discover P2P routes. These DIOs can be used in their secure versions		discover P2P routes. These DIOs can be used in their secure versions
	if desired. New RPL control messages defined in this document (DRO		if desired. New RPL control messages defined in this document (DRO
	and DRO-ACK) have secure versions as well. Thus, a particular P2P-		and DRO-ACK) have secure versions as well. In addition, a P2P-RPL
	RPL deployment can analyze its security requirements and use the		deployment may use the security features provided by the link layer
	appropriate set of RPL security mechanisms that meet those		in use. Thus, a particular P2P-RPL deployment can analyze its
	requirements.		security requirements and use the appropriate set of RPL (or link
			layer) security mechanisms that meet those requirements.
	15. IANA Considerations		Since a DRO message travels along a Source Route specified inside the
			message, some of the security concerns that led to the deprecation of
			Type 0 routing header [RFC5095] may apply. To avoid the possibility
			of a DRO message traveling in a routing loop, this document requires
			each Intermediate Router to confirm that the Source Route listed
			inside the message does not contain any routing loop involving itself
			before the router could forward the message further. As specified in
			Section 9.6, this check involves the router making sure that its IPv6
			addresses do not appear multiple times inside the Source Route with
			one or more other IPv6 addresses in between.
	15.1. Additions to DIO Mode of Operation		14. IANA Considerations
			14.1. Additions to DIO Mode of Operation
	IANA is requested to allocate a new value in the "DIO Mode of		IANA is requested to allocate a new value in the "DIO Mode of
	Operation" registry for the "P2P Route Discovery Mode" described in		Operation" registry for the "P2P Route Discovery Mode" described in
	this document.		this document.
	+----------+-----------------------------------------+--------------+		+----------+-----------------------------------------+--------------+
	| MOP | Description | Reference |		| MOP | Description | Reference |
	| Value | | |		| Value | | |
	+----------+-----------------------------------------+--------------+		+----------+-----------------------------------------+--------------+
	| 4 | Reactive P2P route discovery mode of | This |		| 4 | Reactive P2P route discovery mode of | This |
	| | operation | document |		| | operation | document |
	+----------+-----------------------------------------+--------------+		+----------+-----------------------------------------+--------------+
	DIO Mode of Operation		DIO Mode of Operation
	15.2. Additions to RPL Control Message Options		14.2. Additions to RPL Control Message Options
	IANA is requested to allocate new values in the "RPL Control Message		IANA is requested to allocate new values in the "RPL Control Message
	Options" registry for the "P2P Route Discovery Option" and the "Data		Options" registry for the "P2P Route Discovery Option" and the "Data
	Option" described in this document.		Option" described in this document.
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| 10 | P2P Route Discovery | This document |		| 10 | P2P Route Discovery | This document |
	| 11 | Data | This document |		| 11 | Data | This document |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	RPL Control Message Options		RPL Control Message Options
	15.3. Additions to RPL Control Codes		14.3. Additions to RPL Control Codes
	IANA is requested to allocate new code points in the "RPL Control		IANA is requested to allocate new code points in the "RPL Control
	Codes" registry for the "Discovery Reply Object" and "Discovery Reply		Codes" registry for the "Discovery Reply Object" and "Discovery Reply
	Object Acknowledgement" (and their secure versions) described in this		Object Acknowledgement" (and their secure versions) described in this
	document.		document.
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	| Code | Description | Reference |		| Code | Description | Reference |
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	| 0x04 | Discovery Reply Object | This document |		| 0x04 | Discovery Reply Object | This document |
	| 0x05 | Discovery Reply Object Acknowledgement | This document |		| 0x05 | Discovery Reply Object Acknowledgement | This document |
	| 0x84 | Secure Discovery Reply Object | This document |		| 0x84 | Secure Discovery Reply Object | This document |
	| 0x85 | Secure Discovery Reply Object | This document |		| 0x85 | Secure Discovery Reply Object | This document |
	| | Acknowledgement | |		| | Acknowledgement | |
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	RPL Control Codes		RPL Control Codes
	16. Acknowledgements		14.4. New Registry for Upper Layer Headers inside Data Option
			This document creates a new IANA registry for the Upper Layer Header
			type inside the RPL Data Option, with the following initial content:
			+-------+-------------+---------------+
			| Value | Description | Reference |
			+-------+-------------+---------------+
			| 0x00 | UDP Header | This document |
			+-------+-------------+---------------+
			Upper Layer Header Types inside RPL Data Option
			15. Acknowledgements
	Authors gratefully acknowledge the contributions of the following		Authors gratefully acknowledge the contributions of the following
	individuals (in alphabetical order) in the development of this		individuals (in alphabetical order) in the development of this
	document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard		document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard
	Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP		Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP
	Vasseur.		Vasseur.
	17. References		16. References
	17.1. Normative References
	[I-D.ietf-roll-routing-metrics]
	Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.
	Dejean, "Routing Metrics used for Path Calculation in Low
	Power and Lossy Networks",
	draft-ietf-roll-routing-metrics-19 (work in progress),
	March 2011.
	[I-D.ietf-roll-rpl]		16.1. Normative References
	Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
	Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
	Winter, "RPL: IPv6 Routing Protocol for Low power and
	Lossy Networks", draft-ietf-roll-rpl-19 (work in
	progress), March 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.
	[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,		[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
	"The Trickle Algorithm", RFC 6206, March 2011.		"The Trickle Algorithm", RFC 6206, March 2011.
	17.2. Informative References		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
			Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	[I-D.ietf-6man-rpl-option]		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Hui, J. and J. Vasseur, "RPL Option for Carrying RPL		Lossy Networks", RFC 6550, March 2012.
	Information in Data-Plane Datagrams",
	draft-ietf-6man-rpl-option-06 (work in progress),
	December 2011.
	[I-D.ietf-6man-rpl-routing-header]		[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
	Culler, D., Hui, J., Vasseur, J., and V. Manral, "An IPv6		Barthel, "Routing Metrics Used for Path Calculation in
	Routing Header for Source Routes with RPL",		Low-Power and Lossy Networks", RFC 6551, March 2012.
	draft-ietf-6man-rpl-routing-header-07 (work in progress),
	December 2011.
	[I-D.ietf-roll-of0]		16.2. Informative References
	Thubert, P., "RPL Objective Function Zero",
	draft-ietf-roll-of0-20 (work in progress), September 2011.
	[I-D.ietf-roll-p2p-measurement]		[I-D.ietf-roll-p2p-measurement]
	Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A		Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A
	Mechanism to Measure the Quality of a Point-to-point Route		Mechanism to Measure the Quality of a Point-to-point Route
	in a Low Power and Lossy Network",		in a Low Power and Lossy Network",
	draft-ietf-roll-p2p-measurement-03 (work in progress),		draft-ietf-roll-p2p-measurement-04 (work in progress),
	March 2012.		March 2012.
	[I-D.ietf-roll-terminology]		[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	Vasseur, J., "Terminology in Low power And Lossy		of Type 0 Routing Headers in IPv6", RFC 5095,
	Networks", draft-ietf-roll-terminology-06 (work in		December 2007.
	progress), September 2011.
	[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation		[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
	Routing Requirements in Low-Power and Lossy Networks",		Routing Requirements in Low-Power and Lossy Networks",
	RFC 5826, April 2010.		RFC 5826, April 2010.
	[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,		[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
	"Building Automation Routing Requirements in Low-Power and		"Building Automation Routing Requirements in Low-Power and
	Lossy Networks", RFC 5867, June 2010.		Lossy Networks", RFC 5867, June 2010.
			[RFC6552] Thubert, P., "Objective Function Zero for the Routing
			Protocol for Low-Power and Lossy Networks (RPL)",
			RFC 6552, March 2012.
			[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
			Power and Lossy Networks (RPL) Option for Carrying RPL
			Information in Data-Plane Datagrams", RFC 6553,
			March 2012.
			[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
			Routing Header for Source Routes with the Routing Protocol
			for Low-Power and Lossy Networks (RPL)", RFC 6554,
			March 2012.
	Authors' Addresses		Authors' Addresses
	Mukul Goyal (editor)		Mukul Goyal (editor)
	University of Wisconsin Milwaukee		University of Wisconsin Milwaukee
	3200 N Cramer St		3200 N Cramer St
	Milwaukee, WI 53201		Milwaukee, WI 53201
	USA		USA
	Phone: +1 414 2295001		Phone: +1 414 2295001
	Email: mukul@uwm.edu		Email: mukul@uwm.edu
End of changes. 163 change blocks.
	475 lines changed or deleted		603 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/