draft-ietf-roll-p2p-rpl-13.txt		draft-ietf-roll-p2p-rpl-14.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: December 6, 2012 E. Baccelli		Expires: April 20, 2013 E. Baccelli
	M. Philipp		M. Philipp
	INRIA		INRIA
	A. Brandt		A. Brandt
	Sigma Designs		Sigma Designs
	J. Martocci		J. Martocci
	Johnson Controls		Johnson Controls
	June 4, 2012		October 17, 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-13		draft-ietf-roll-p2p-rpl-14
	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 meet specified		routers in the LLN such that the discovered routes meet specified
	metrics constraints.		metrics constraints.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 December 6, 2012.		This Internet-Draft will expire on April 20, 2013.
	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 46		skipping to change at page 2, line 46
	9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 27		9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 27
	10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 28		10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 28
	11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 29		11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 29
	12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 29		12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 29
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 30		13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 31		14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 31
	14.2. Additions to RPL Control Message Options . . . . . . . . . 31		14.2. Additions to RPL Control Message Options . . . . . . . . . 31
	14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 32		14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 32
	14.4. New Registry for Upper Layer Protocol Types Inside		14.4. New Registry for Upper Layer Protocol Types Inside
	Data Option . . . . . . . . . . . . . . . . . . . . . . . 32		Data Option . . . . . . . . . . . . . . . . . . . . . . . 33
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 33		16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
	16.2. Informative References . . . . . . . . . . . . . . . . . . 34		16.2. Informative References . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	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 [RFC6550] provides paths along a Directed Acyclic Graph		protocol [RFC6550] provides paths along a Directed Acyclic Graph
	(DAG) rooted at a single router in the network. Establishment and		(DAG) rooted at a single router in the network. Establishment and
	maintenance of a DAG is performed by routers in the LLN using DODAG		maintenance of a DAG is performed by routers in the LLN using 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.
	skipping to change at page 10, line 8		skipping to change at page 10, line 8
	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
	Discovery Mode (or P2P mode, for short), with value 4 (to be		Discovery Mode (or P2P mode, for short), with value TBD1. A DIO
	confirmed by IANA). A DIO message, listing P2P mode as the MOP, is		message, listing P2P mode as the MOP, is identified as performing a
	identified as performing a P2P-RPL route discovery by creating a		P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO
	temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route		MUST carry one and only one P2P Route Discovery Option (specified in
	Discovery Option (specified in Section 7.1).		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 [RFC6550]. The Origin MUST NOT use the same		Section 5.1 of [RFC6550]. The Origin MUST NOT use the same
	RPLInstanceID in two or more concurrent route discoveries. When		RPLInstanceID in two or more concurrent route discoveries. When
	initiating a new route discovery to a particular Target, the		initiating a new route discovery to a particular Target, the
	skipping to change at page 13, line 16		skipping to change at page 13, line 16
	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)
	-		-
	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 = 10 | Option Length |R|H| N | Compr | L |MaxRank/NH |		| Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Target |		| Target |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Address[1..n] |		| Address[1..n] |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Format of P2P Route Discovery Option (P2P-RDO)		Figure 1: Format of P2P Route Discovery Option (P2P-RDO)
	The format of a P2P Route Discovery Option (P2P-RDO) is illustrated		The format of a P2P Route Discovery Option (P2P-RDO) is illustrated
	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: TBD2.
	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
	skipping to change at page 16, line 12		skipping to change at page 16, line 12
	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 | UpperLayerPrt | Data |		| Type = TBD3 | Option Length | UpperLayerPrt | 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 Data		DIO and a DRO (defined in Section 8) message MAY carry one Data
	Option. A P2P-RDO consists of the following fields:		Option. A P2P-RDO consists of the following fields:
	o Option Type: 0x0B (to be confirmed by IANA).		o Option Type: TBD3.
	o Option Length: An 8-bit unsigned integer, representing the length		o Option Length: An 8-bit unsigned integer, representing the length
	in 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 Upper Layer Protocol: An 8-bit field that identifies the upper		o Upper Layer Protocol: An 8-bit field that identifies the upper
	layer protocol header with which the information in the Data field		layer protocol header with which the information in the Data field
	starts. A value 0x00 in this field identifies UDP as the upper		starts. A value 0x00 in this field identifies UDP as the upper
	layer protocol while the value 0xFF is reserved for Private Use as		layer protocol while the value 0xFF is reserved for Private Use as
	defined in [RFC5226]. The other values are Unassigned [RFC5226]		defined in [RFC5226]. The other values are Unassigned [RFC5226]
	skipping to change at page 17, line 9		skipping to change at page 17, line 9
	it MUST include the same Data Option in all retransmissions of this		it MUST include the same Data Option in all retransmissions of this
	DRO message and MUST NOT include a different Data Option in any other		DRO message and MUST NOT include a different Data Option in any other
	DRO messages it generates for this route discovery. Also, an		DRO messages it generates for this route discovery. Also, an
	Intermediate Router, which needs to forward a received DRO message		Intermediate Router, which needs to forward a received DRO message
	further, MUST include in the forwarded message a verbatim copy of the		further, MUST include in the forwarded message a verbatim copy of the
	Data Option found inside the received message.		Data Option found inside the received message.
	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 TBD4, and the Secure DRO, with code
	Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves		TBD5. 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
	skipping to change at page 28, line 50		skipping to change at page 28, line 50
	Intermediate Router may drop the DRO message (e.g., because of its		Intermediate Router may drop the DRO message (e.g., because of its
	inability to store the state for the Hop-by-hop Route the DRO is		inability to store the state for the Hop-by-hop Route the DRO is
	establishing). To protect against the potential failure of a DRO		establishing). To protect against the potential failure of a DRO
	message to reach the Origin, the Target MAY request the Origin to		message to reach the Origin, the Target MAY request the Origin to
	send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO		send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO
	message. 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 TBD6) and Secure DRO-ACK (with
	and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO-		code TBD7). A DRO-ACK message MUST travel as a unicast message from
	ACK message MUST travel as a unicast message from the Origin to the		the Origin to the Target. The format of a base DRO-ACK message is
	Target. The format of a base DRO-ACK message is shown in Figure 4.		shown in Figure 4. Various fields in a DRO-ACK message MUST have the
	Various fields in a DRO-ACK message MUST have the same values as the		same values as the corresponding fields in the DRO message. The
	corresponding fields in the DRO message. The field marked as		field marked as "Reserved" MUST be set to zero on transmission and
	"Reserved" MUST be set to zero on transmission and MUST be ignored on		MUST be ignored on reception. A Secure DRO-ACK message follows the
	reception. A Secure DRO-ACK message follows the format in Figure 7		format in Figure 7 of [RFC6550], where the base format is same as the
	of [RFC6550], where the base format is same as the base DRO-ACK shown		base 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) [RFC6554] to send a		An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a
	packet along a Source Route discovered using P2P-RPL.		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
	skipping to change at page 31, line 15		skipping to change at page 31, line 14
	before the router could forward the message further. As specified in		before the router could forward the message further. As specified in
	Section 9.6, this check involves the router making sure that its IPv6		Section 9.6, this check involves the router making sure that its IPv6
	addresses do not appear multiple times inside the Source Route with		addresses do not appear multiple times inside the Source Route with
	one or more other IPv6 addresses in between.		one or more other IPv6 addresses in between.
	14. IANA Considerations		14. IANA Considerations
	14.1. Additions to Mode of Operation		14.1. Additions to Mode of Operation
	This document defines a new Mode of Operation, entitled "P2P Route		This document defines a new Mode of Operation, entitled "P2P Route
	Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode		Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode
	of Operation" space [to be removed upon publication:		of Operation" space [to be removed upon publication:
	http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550].		http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is
			requested to allocate a suitable value to TBD1. The string TBD1 in
			this document should be replaced by the allocated value. The
			previous two sentences should be removed before publication.
	+-------+---------------------------------------+---------------+		+-------+---------------------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+---------------------------------------+---------------+		+-------+---------------------------------------+---------------+
	| 4 | P2P Route Discovery Mode of Operation | This document |		| TBD1 | P2P Route Discovery Mode of Operation | This document |
	+-------+---------------------------------------+---------------+		+-------+---------------------------------------+---------------+
	Mode of Operation		Mode of Operation
	14.2. Additions to RPL Control Message Options		14.2. Additions to RPL Control Message Options
	This document defines two new RPL options:		This document defines two new RPL options:
	o "P2P Route Discovery Option" (see Section 7.1), assigned a value		o "P2P Route Discovery Option" (see Section 7.1), assigned a value
	of 0x0A from the "RPL Control Message Options" space [to be		TBD2 from the "RPL Control Message Options" space [to be removed
	removed upon publication: http://www.iana.org/assignments/rpl/		upon publication: http://www.iana.org/assignments/rpl/
	rpl.xml#control-message-options] [RFC6550].		rpl.xml#control-message-options] [RFC6550]. IANA is requested to
			allocate a suitable value to TBD2. The string TBD2 in this
			document should be replaced by the allocated value. The previous
			two sentences should be removed before publication.
	o "Data Option" (see Section 7.2), assigned a value of 0x0B from the		o "Data Option" (see Section 7.2), assigned a value TBD3 from the
	"RPL Control Message Options" space [to be removed upon		"RPL Control Message Options" space [to be removed upon
	publication: http://www.iana.org/assignments/rpl/		publication: http://www.iana.org/assignments/rpl/
	rpl.xml#control-message-options] [RFC6550].		rpl.xml#control-message-options] [RFC6550]. IANA is requested to
			allocate a suitable value to TBD3. The string TBD3 in this
			document should be replaced by the allocated value. The previous
			two sentences should be removed before publication.
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| 0x0A | P2P Route Discovery | This document |		| TBD2 | P2P Route Discovery | This document |
	| 0x0B | Data | This document |		| TBD3 | Data | This document |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	RPL Control Message Options		RPL Control Message Options
	14.3. Additions to RPL Control Codes		14.3. Additions to RPL Control Codes
	This document defines the following new RPL messages:		This document defines the following new RPL messages:
	o "Discovery Reply Object" (see Section 8), assigned a value of 0x04		o "Discovery Reply Object" (see Section 8), assigned a value TBD4
	from the "RPL Control Codes" space [to be removed upon		from the "RPL Control Codes" space [to be removed upon
	publication:		publication:
	http://www.iana.org/assignments/rpl/rpl.xml#control-codes]		http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
	[RFC6550].		[RFC6550]. IANA is requested to allocate TBD4 from the range
			0x00-0x7F to indicate a message without security enabled. The
			string TBD4 in this document should be replaced by the allocated
			value. The previous two sentences should be removed before
			publication.
	o "Discovery Reply Object Acknowledgement" (see Section 10),		o "Secure Discovery Reply Object" (see Section 8.1), assigned a
	assigned a value of 0x05 from the "RPL Control Codes" space [to be		value TBD5 from the "RPL Control Codes" space [to be removed upon
	removed upon publication:		publication:
	http://www.iana.org/assignments/rpl/rpl.xml#control-codes]		http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
	[RFC6550].		[RFC6550]. IANA is requested to allocate TBD5 from the range
			0x80-0xFF to indicate a message with security enabled. The string
			TBD5 in this document should be replaced by the allocated value.
			The previous two sentences should be removed before publication.
	o "Secure Discovery Reply Object" (see Section 8.1), assigned a		o "Discovery Reply Object Acknowledgement" (see Section 10),
	value of 0x84 from the "RPL Control Codes" space [to be removed		assigned a value TBD6 from the "RPL Control Codes" space [to be
	upon publication:		removed upon publication:
	http://www.iana.org/assignments/rpl/rpl.xml#control-codes]		http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
	[RFC6550].		[RFC6550]. IANA is requested to allocate TBD6 from the range
			0x00-0x7F to indicate a message without security enabled. The
			string TBD6 in this document should be replaced by the allocated
			value. The previous two sentences should be removed before
			publication.
	o "Secure Discovery Reply Object Acknowledgement" (see Section 10),		o "Secure Discovery Reply Object Acknowledgement" (see Section 10),
	assigned a value of 0x85 from the "RPL Control Codes" space [to be		assigned a value TBD7 from the "RPL Control Codes" space [to be
	removed upon publication:		removed upon publication:
	http://www.iana.org/assignments/rpl/rpl.xml#control-codes]		http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
	[RFC6550].		[RFC6550]. IANA is requested to allocate TBD7 from the range
			0x80-0xFF to indicate a message with security enabled. The string
			TBD7 in this document should be replaced by the allocated value.
			The previous two sentences should be removed before publication.
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	| Code | Description | Reference |		| Code | Description | Reference |
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	| 0x04 | Discovery Reply Object | This document |		| TBD4 | Discovery Reply Object | This document |
	| 0x05 | Discovery Reply Object Acknowledgement | This document |		| TBD5 | Secure Discovery Reply Object | This document |
	| 0x84 | Secure Discovery Reply Object | This document |		| TBD6 | Discovery Reply Object Acknowledgement | This document |
	| 0x85 | Secure Discovery Reply Object | This document |		| TBD7 | Secure Discovery Reply Object | This document |
	| | Acknowledgement | |		| | Acknowledgement | |
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	RPL Control Codes		RPL Control Codes
	14.4. New Registry for Upper Layer Protocol Types Inside Data Option		14.4. New Registry for Upper Layer Protocol Types Inside Data Option
	The Data Option (see Section 7.2) defines an 8-bit "Upper Layer		The Data Option (see Section 7.2) defines an 8-bit "Upper Layer
	Protocol" field, for which IANA is requested to create and maintain a		Protocol" field, for which IANA is requested to create and maintain a
	new registry titled "Upper Layer Protocol Types Inside RPL Data		new registry titled "Upper Layer Protocol Types Inside RPL Data
	skipping to change at page 34, line 15		skipping to change at page 34, line 37
	[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.		[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
	Barthel, "Routing Metrics Used for Path Calculation in		Barthel, "Routing Metrics Used for Path Calculation in
	Low-Power and Lossy Networks", RFC 6551, March 2012.		Low-Power and Lossy Networks", RFC 6551, March 2012.
	16.2. Informative References		16.2. Informative References
	[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-05 (work in progress),		draft-ietf-roll-p2p-measurement-06 (work in progress),
	May 2012.		September 2012.
	[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation		[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	of Type 0 Routing Headers in IPv6", RFC 5095,		of Type 0 Routing Headers in IPv6", RFC 5095,
	December 2007.		December 2007.
	[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,
End of changes. 31 change blocks.
	58 lines changed or deleted		79 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/