draft-ietf-roll-aodv-rpl-06.txt		draft-ietf-roll-aodv-rpl-07.txt
	ROLL S. Anamalamudi		ROLL S. Anamalamudi
	Internet-Draft SRM University-AP		Internet-Draft SRM University-AP
	Intended status: Standards Track M. Zhang		Intended status: Standards Track M. Zhang
	Expires: September 8, 2019 Huawei Technologies		Expires: October 14, 2019 Huawei Technologies
	C. Perkins		C. Perkins
	Futurewei		Futurewei
	S.V.R.Anand		S.V.R.Anand
	Indian Institute of Science		Indian Institute of Science
	B. Liu		B. Liu
	Huawei Technologies		Huawei Technologies
	March 7, 2019		April 12, 2019
	Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)		Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)
	draft-ietf-roll-aodv-rpl-06		draft-ietf-roll-aodv-rpl-07
	Abstract		Abstract
	Route discovery for symmetric and asymmetric Point-to-Point (P2P)		Route discovery for symmetric and asymmetric Point-to-Point (P2P)
	traffic flows is a desirable feature in Low power and Lossy Networks		traffic flows is a desirable feature in Low power and Lossy Networks
	(LLNs). For that purpose, this document specifies a reactive P2P		(LLNs). For that purpose, this document specifies a reactive P2P
	route discovery mechanism for both hop-by-hop routing and source		route discovery mechanism for both hop-by-hop routing and source
	routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL		routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
	protocol. Paired Instances are used to construct directional paths,		protocol. Paired Instances are used to construct directional paths,
	in case some of the links between source and target node are		in case some of the links between source and target node are
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 8, 2019.		This Internet-Draft will expire on October 14, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19		9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19
	9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19		9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 20		10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	13.1. Normative References . . . . . . . . . . . . . . . . . . 21		13.1. Normative References . . . . . . . . . . . . . . . . . . 21
	13.2. Informative References . . . . . . . . . . . . . . . . . 22		13.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 23		Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 23
	Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24		Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24
	B.1. Changes from version 05 to version 06 . . . . . . . . . . 24		B.1. Changes from version 06 to version 07 . . . . . . . . . . 24
	B.2. Changes from version 04 to version 05 . . . . . . . . . . 24		B.2. Changes from version 05 to version 06 . . . . . . . . . . 24
	B.3. Changes from version 03 to version 04 . . . . . . . . . . 24		B.3. Changes from version 04 to version 05 . . . . . . . . . . 24
	B.4. Changes from version 02 to version 03 . . . . . . . . . . 24		B.4. Changes from version 03 to version 04 . . . . . . . . . . 24
			B.5. Changes from version 02 to version 03 . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy		RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy
	Networks)) is a IPv6 distance vector routing protocol designed to		Networks)) is a IPv6 distance vector routing protocol designed to
	support multiple traffic flows through a root-based Destination-		support multiple traffic flows through a root-based Destination-
	Oriented Directed Acyclic Graph (DODAG). Typically, a router does		Oriented Directed Acyclic Graph (DODAG). Typically, a router does
	not have routing information for most other routers. Consequently,		not have routing information for most other routers. Consequently,
	for traffic between routers within the DODAG (i.e., Point-to-Point		for traffic between routers within the DODAG (i.e., Point-to-Point
	(P2P) traffic) data packets either have to traverse the root in non-		(P2P) traffic) data packets either have to traverse the root in non-
	storing mode, or traverse a common ancestor in storing mode. Such		storing mode, or traverse a common ancestor in storing mode. Such
	P2P traffic is thereby likely to traverse longer routes and may		P2P traffic is thereby likely to traverse longer routes and may
	suffer severe congestion near the DAG root [RFC6997], [RFC6998].		suffer severe congestion near the DAG root (for more information see
			[RFC6997], [RFC6998]).
	To discover better paths for P2P traffic flows in RPL, P2P-RPL		To discover better paths for P2P traffic flows in RPL, P2P-RPL
	[RFC6997] specifies a temporary DODAG where the source acts as a		[RFC6997] specifies a temporary DODAG where the source acts as a
	temporary root. The source initiates DIOs encapsulating the P2P		temporary root. The source initiates DIOs encapsulating the P2P
	Route Discovery option (P2P-RDO) with an address vector for both hop-		Route Discovery option (P2P-RDO) with an address vector for both hop-
	by-hop mode (H=1) and source routing mode (H=0). Subsequently, each		by-hop mode (H=1) and source routing mode (H=0). Subsequently, each
	intermediate router adds its IP address and multicasts the P2P mode		intermediate router adds its IP address and multicasts the P2P mode
	DIOs, until the message reaches the Target Node, which then sends the		DIOs, until the message reaches the Target Node, which then sends the
	"Discovery Reply" object. P2P-RPL is efficient for source routing,		"Discovery Reply" object. P2P-RPL is efficient for source routing,
	but much less efficient for hop-by-hop routing due to the extra		but much less efficient for hop-by-hop routing due to the extra
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 38 ¶
	RPL messages, namely RREQ for Route Request, and RREP for Route		RPL messages, namely RREQ for Route Request, and RREP for Route
	Reply. AODV-RPL currently omits some features compared to AODV -- in		Reply. AODV-RPL currently omits some features compared to AODV -- in
	particular, flagging Route Errors, blacklisting unidirectional links,		particular, flagging Route Errors, blacklisting unidirectional links,
	multihoming, and handling unnumbered interfaces.		multihoming, and handling unnumbered interfaces.
	2. Terminology		2. 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]. This document uses the following terms:		[RFC2119], [RFC8174]. This document uses the following terms:
	AODV		AODV
	Ad Hoc On-demand Distance Vector Routing[RFC3561].		Ad Hoc On-demand Distance Vector Routing[RFC3561].
	AODV-RPL Instance		AODV-RPL Instance
	Either the RREQ-Instance or RREP-Instance		Either the RREQ-Instance or RREP-Instance
	Asymmetric Route		Asymmetric Route
	The route from the OrigNode to the TargNode can traverse different		The route from the OrigNode to the TargNode can traverse different
	nodes than the route from the TargNode to the OrigNode. An		nodes than the route from the TargNode to the OrigNode. An
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	Address Vector		Address Vector
	Only present when the 'H' bit is set to 0. For an asymmetric		Only present when the 'H' bit is set to 0. For an asymmetric
	route, the Address Vector represents the IPv6 addresses of the		route, the Address Vector represents the IPv6 addresses of the
	route that the RREP-DIO has passed. For a symmetric route, it is		route that the RREP-DIO has passed. For a symmetric route, it is
	the Address Vector when the RREQ-DIO arrives at the TargNode,		the Address Vector when the RREQ-DIO arrives at the TargNode,
	unchanged during the transmission to the OrigNode.		unchanged during the transmission to the OrigNode.
	4.3. AODV-RPL DIO Target Option		4.3. AODV-RPL DIO Target Option
	The AODV-RPL Target (ART) Option is defined based on the Target		The AODV-RPL Target (ART) Option is based on the Target Option in
	Option in core RPL [RFC6550]: the Destination Sequence Number of the		core RPL [RFC6550]. The Flags field is replaced by the Destination
	TargNode is added.		Sequence Number of the TargNode and the Prefix Length field is
			reduced to 7 bits so that the value is limited to be no greater than
			127.
	A RREQ-DIO message MUST carry at least one ART Options. A RREP-DIO		A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
	message MUST carry exactly one ART Option.		message MUST carry exactly one ART Option.
	OrigNode can include multiple TargNode addresses via multiple AODV-		OrigNode can include multiple TargNode addresses via multiple AODV-
	RPL Target Options in the RREQ-DIO, for routes that share the same		RPL Target Options in the RREQ-DIO, for routes that share the same
	constraints. This reduces the cost to building only one DODAG.		constraints. This reduces the cost to building only one DODAG.
	Furthermore, a single Target Option can be used for different		Furthermore, a single Target Option can be used for different
	TargNode addresses if they share the same prefix; in that case the		TargNode addresses if they share the same prefix; in that case the
	use of the destination sequence number is not defined in this		use of the destination sequence number is not defined in this
	document.		document.
	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 | Option Length | Dest SeqNo | Prefix Length |		| Type | Option Length | Dest SeqNo |r|Prefix Length|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ |		+ |
	| Target Prefix (Variable Length) |		| Target Prefix / Address (Variable Length) |
	. .		. .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Target option format for AODV-RPL MoP		Figure 3: Target option format for AODV-RPL MoP
	Type		Type
	The type assigned to the ART Option		The type assigned to the ART Option
			Option Length
			Length of the option in octets excluding the Type and Length
			fields
	Dest SeqNo		Dest SeqNo
	In RREQ-DIO, if nonzero, it is the last known Sequence Number for		In RREQ-DIO, if nonzero, it is the last known Sequence Number for
	TargNode for which a route is desired. In RREP-DIO, it is the		TargNode for which a route is desired. In RREP-DIO, it is the
	destination sequence number associated to the route.		destination sequence number associated to the route.
			r
			A one-bit reserved field. This field MUST be initialized to zero
			by the sender and MUST be ignored by the receiver.
			Prefix Length
			7-bit unsigned integer. Number of valid leading bits in the IPv6
			Prefix. If Prefix Length is 0, then the value in the Target
			Prefix / Address field represents an IPv6 address, not a prefix.
			Target Prefix / Address
			(variable-length field) An IPv6 destination address or prefix.
			The Prefix Length field contains the number of valid leading bits
			in the prefix. The bits in the Target Prefix / Address field
			after the prefix length (if any) MUST be set to zero on
			transmission and MUST be ignored on receipt.
	5. Symmetric and Asymmetric Routes		5. Symmetric and Asymmetric Routes
	In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode,		In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode,
	R is an intermediate router, and T is the TargNode. If the RREQ-DIO		R is an intermediate router, and T is the TargNode. If the RREQ-DIO
	arrives over an interface that is known to be symmetric, and the 'S'		arrives over an interface that is known to be symmetric, and the 'S'
	bit is set to 1, then it remains as 1, as illustrated in Figure 4.		bit is set to 1, then it remains as 1, as illustrated in Figure 4.
	If an intermediate router sends out RREQ-DIO with the 'S' bit set to		If an intermediate router sends out RREQ-DIO with the 'S' bit set to
	1, then all the one-hop links on the route from the OrigNode O to		1, then all the one-hop links on the route from the OrigNode O to
	this router meet the requirements of route discovery, and the route		this router meet the requirements of route discovery, and the route
	can be used symmetrically.		can be used symmetrically.
	skipping to change at page 21, line 44 ¶		skipping to change at page 21, line 44 ¶
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
	Demand Distance Vector (AODV) Routing", RFC 3561,
	DOI 10.17487/RFC3561, July 2003,
	<https://www.rfc-editor.org/info/rfc3561>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing		[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
	Protocol for Low-Power and Lossy Networks (RPL)",		Protocol for Low-Power and Lossy Networks (RPL)",
	RFC 6552, DOI 10.17487/RFC6552, March 2012,		RFC 6552, DOI 10.17487/RFC6552, March 2012,
	<https://www.rfc-editor.org/info/rfc6552>.		<https://www.rfc-editor.org/info/rfc6552>.
	[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	"A Mechanism to Measure the Routing Metrics along a Point-		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	to-Point Route in a Low-Power and Lossy Network",		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	RFC 6998, DOI 10.17487/RFC6998, August 2013,
	<https://www.rfc-editor.org/info/rfc6998>.
	13.2. Informative References		13.2. Informative References
	[I-D.thubert-roll-asymlink]		[I-D.thubert-roll-asymlink]
	Thubert, P., "RPL adaptation for asymmetrical links",		Thubert, P., "RPL adaptation for asymmetrical links",
	draft-thubert-roll-asymlink-02 (work in progress),		draft-thubert-roll-asymlink-02 (work in progress),
	December 2011.		December 2011.
	[Perlman83]		[Perlman83]
	Perlman, R., "Fault-Tolerant Broadcast of Routing		Perlman, R., "Fault-Tolerant Broadcast of Routing
	Information", December 1983.		Information", December 1983.
			[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
			Demand Distance Vector (AODV) Routing", RFC 3561,
			DOI 10.17487/RFC3561, July 2003,
			<https://www.rfc-editor.org/info/rfc3561>.
	[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and		[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
	D. Barthel, Ed., "Routing Requirements for Urban Low-Power		D. Barthel, Ed., "Routing Requirements for Urban Low-Power
	and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May		and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
	2009, <https://www.rfc-editor.org/info/rfc5548>.		2009, <https://www.rfc-editor.org/info/rfc5548>.
	[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.		[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
	Phinney, "Industrial Routing Requirements in Low-Power and		Phinney, "Industrial Routing Requirements in Low-Power and
	Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October		Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
	2009, <https://www.rfc-editor.org/info/rfc5673>.		2009, <https://www.rfc-editor.org/info/rfc5673>.
	skipping to change at page 23, line 11 ¶		skipping to change at page 23, line 11 ¶
	"Building Automation Routing Requirements in Low-Power and		"Building Automation Routing Requirements in Low-Power and
	Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June		Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
	2010, <https://www.rfc-editor.org/info/rfc5867>.		2010, <https://www.rfc-editor.org/info/rfc5867>.
	[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and		[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
	J. Martocci, "Reactive Discovery of Point-to-Point Routes		J. Martocci, "Reactive Discovery of Point-to-Point Routes
	in Low-Power and Lossy Networks", RFC 6997,		in Low-Power and Lossy Networks", RFC 6997,
	DOI 10.17487/RFC6997, August 2013,		DOI 10.17487/RFC6997, August 2013,
	<https://www.rfc-editor.org/info/rfc6997>.		<https://www.rfc-editor.org/info/rfc6997>.
			[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
			"A Mechanism to Measure the Routing Metrics along a Point-
			to-Point Route in a Low-Power and Lossy Network",
			RFC 6998, DOI 10.17487/RFC6998, August 2013,
			<https://www.rfc-editor.org/info/rfc6998>.
	Appendix A. Example: ETX/RSSI Values to select S bit		Appendix A. Example: ETX/RSSI Values to select S bit
	We have tested the combination of "RSSI(downstream)" and "ETX		We have tested the combination of "RSSI(downstream)" and "ETX
	(upstream)" to determine whether the link is symmetric or asymmetric		(upstream)" to determine whether the link is symmetric or asymmetric
	at the intermediate nodes. The example of how the ETX and RSSI		at the intermediate nodes. The example of how the ETX and RSSI
	values are used in conjuction is explained below:		values are used in conjuction is explained below:
	Source---------->NodeA---------->NodeB------->Destination		Source---------->NodeA---------->NodeB------->Destination
	Figure 8: Communication link from Source to Destination		Figure 8: Communication link from Source to Destination
	skipping to change at page 24, line 7 ¶		skipping to change at page 24, line 11 ¶
	models, one can determine a relationship between RSSI and ETX		models, one can determine a relationship between RSSI and ETX
	representable as an expression or a mapping table. Such a		representable as an expression or a mapping table. Such a
	relationship in turn can be used to estimate ETX value at nodeA for		relationship in turn can be used to estimate ETX value at nodeA for
	link NodeB--->NodeA from the received RSSI from NodeB. Whenever		link NodeB--->NodeA from the received RSSI from NodeB. Whenever
	nodeA determines that the link towards the nodeB is bi-directional		nodeA determines that the link towards the nodeB is bi-directional
	asymmetric then the "S" bit is set to "S=0". Later on, the link from		asymmetric then the "S" bit is set to "S=0". Later on, the link from
	NodeA to Destination is asymmetric with "S" bit remains to "0".		NodeA to Destination is asymmetric with "S" bit remains to "0".
	Appendix B. Changelog		Appendix B. Changelog
	B.1. Changes from version 05 to version 06		B.1. Changes from version 06 to version 07
			o Added definitions for all fields of the ART option (see
			Section 4.3). Modified definition of Prefix Length to prohibit
			Prefix Length values greater than 127.
			o Modified the language from [RFC6550] Target Option definition so
			that the trailing zero bits of the Prefix Length are no longer
			described as "reserved".
			o Reclassified RFC 3561 and RFC 6998 as Informative.
			o Added citation to RFC 8174 to Terminology section.
			B.2. Changes from version 05 to version 06
	o Added Security Considerations based on the security mechanisms		o Added Security Considerations based on the security mechanisms
	defined in RFC 6550.		defined in RFC 6550.
	o Clarified the nature of improvements due to P2P route discovery		o Clarified the nature of improvements due to P2P route discovery
	versus bidirectional asymmetric route discovery.		versus bidirectional asymmetric route discovery.
	o Editorial improvements and corrections.		o Editorial improvements and corrections.
	B.2. Changes from version 04 to version 05		B.3. Changes from version 04 to version 05
	o Add description for sequence number operations.		o Add description for sequence number operations.
	o Extend the residence duration L in section 4.1.		o Extend the residence duration L in section 4.1.
	o Change AODV-RPL Target option to ART option.		o Change AODV-RPL Target option to ART option.
	B.3. Changes from version 03 to version 04		B.4. Changes from version 03 to version 04
	o Updated RREP option format. Remove the 'T' bit in RREP option.		o Updated RREP option format. Remove the 'T' bit in RREP option.
	o Using the same RPLInstanceID for RREQ and RREP, no need to update		o Using the same RPLInstanceID for RREQ and RREP, no need to update
	[RFC6550].		[RFC6550].
	o Explanation of Shift field in RREP.		o Explanation of Shift field in RREP.
	o Multiple target options handling during transmission.		o Multiple target options handling during transmission.
	B.4. Changes from version 02 to version 03		B.5. Changes from version 02 to version 03
	o Include the support for source routing.		o Include the support for source routing.
	o Import some features from [RFC6997], e.g., choice between hop-by-		o Import some features from [RFC6997], e.g., choice between hop-by-
	hop and source routing, the "L" bit which determines the duration		hop and source routing, the "L" bit which determines the duration
	of residence in the DAG, MaxRank, etc.		of residence in the DAG, MaxRank, etc.
	o Define new target option for AODV-RPL, including the Destination		o Define new target option for AODV-RPL, including the Destination
	Sequence Number in it. Move the TargNode address in RREQ option		Sequence Number in it. Move the TargNode address in RREQ option
	and the OrigNode address in RREP option into ADOV-RPL Target		and the OrigNode address in RREP option into ADOV-RPL Target
End of changes. 21 change blocks.
	30 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/