< draft-ietf-roll-useofrplinfo-06.txt		draft-ietf-roll-useofrplinfo-07.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational M. Richardson		Intended status: Informational M. Richardson
	Expires: January 19, 2017 SSW		Expires: January 21, 2017 SSW
	P. Thubert		P. Thubert
	Cisco		Cisco
	July 18, 2016		July 20, 2016
	When to use RFC 6553, 6554 and IPv6-in-IPv6		When to use RFC 6553, 6554 and IPv6-in-IPv6
	draft-ietf-roll-useofrplinfo-06		draft-ietf-roll-useofrplinfo-07
	Abstract		Abstract
	This document looks at different data flows through LLN (Low-Power		This document looks at different data flows through LLN (Low-Power
	and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power		and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
	and Lossy Networks) is used to establish routing. The document		and Lossy Networks) is used to establish routing. The document
	enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6		enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
	encapsulation is required. This analysis provides the basis on which		encapsulation is required. This analysis provides the basis on which
	to design efficient compression of these headers.		to design efficient compression of these headers.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 January 19, 2017.		This Internet-Draft will expire on January 21, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 20 ¶		skipping to change at page 2, line 20 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Requirements Language . . . . . . . . . . . . 3		2. Terminology and Requirements Language . . . . . . . . . . . . 3
	2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 4		2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 4
	3. Sample/reference topology . . . . . . . . . . . . . . . . . . 4		3. Sample/reference topology . . . . . . . . . . . . . . . . . . 4
	4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 9		5.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 9
	5.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 10		5.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 10
	5.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 11		5.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 11
	5.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 12		5.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 11
	5.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 12		5.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 12
	5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 13		5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 12
	5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 14		5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 13
	5.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 14		5.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 14
	5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 15		5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 14
	5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 16		5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 15
	5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 18		5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 15
	5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-		5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
	leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 19		leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 20		6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 20		6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 17
	6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 21		6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 17
	6.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 21		6.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 18
	6.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 22		6.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 19
	6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 23		6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 19
	6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 23		6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 20
	6.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 24		6.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 21
	6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 25		6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 21
	6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 25		6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 22
	6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 26		6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 23
	6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 27		6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 24
	6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-		6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
	leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 28		leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7. Observations about the problem . . . . . . . . . . . . . . . 28		7. Observations about the problem . . . . . . . . . . . . . . . 25
	7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 28		7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 25
	7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 29		7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 26
	8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 30		8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 26
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 30		10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	12.1. Normative References . . . . . . . . . . . . . . . . . . 30		12.1. Normative References . . . . . . . . . . . . . . . . . . 27
	12.2. Informative References . . . . . . . . . . . . . . . . . 31		12.2. Informative References . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)		RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
	[RFC6550] is a routing protocol for constrained networks. RFC 6553		[RFC6550] is a routing protocol for constrained networks. RFC 6553
	[RFC6553] defines the "RPL option" (RPI), carried within the IPv6		[RFC6553] defines the "RPL option" (RPI), carried within the IPv6
	Hop-by-Hop header to quickly identify inconsistencies (loops) in the		Hop-by-Hop header to quickly identify inconsistencies (loops) in the
	routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route		routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route
	Header" (RH3), an IPv6 Extension Header to deliver datagrams within a		Header" (RH3), an IPv6 Extension Header to deliver datagrams within a
	RPL routing domain, particularly in non-storing mode.		RPL routing domain, particularly in non-storing mode.
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 9 ¶
	This document is in part motivated by the work that is ongoing at the		This document is in part motivated by the work that is ongoing at the
	6TiSCH working group. The 6TiSCH architecture		6TiSCH working group. The 6TiSCH architecture
	[I-D.ietf-6tisch-architecture] draft explains the network		[I-D.ietf-6tisch-architecture] draft explains the network
	architecture of a 6TiSCH network.		architecture of a 6TiSCH network.
	4. Use cases		4. Use cases
	In data plane context a combination of RFC6553, RFC6554 and IPv6-in-		In data plane context a combination of RFC6553, RFC6554 and IPv6-in-
	IPv6 encapsulation is going to be analyzed for the following traffic		IPv6 encapsulation is going to be analyzed for the following traffic
	flows:		flows.
			This version of the document assumes the changes in
			[I-D.ietf-6man-rfc2460bis] are passed.
	RPL-aware-leaf to root		RPL-aware-leaf to root
	root to RPL-aware-leaf		root to RPL-aware-leaf
	not-RPL-aware-leaf to root		not-RPL-aware-leaf to root
	root to not-RPL-aware-leaf		root to not-RPL-aware-leaf
	RPL-aware-leaf to Internet		RPL-aware-leaf to Internet
	Internet to RPL-aware-leaf		Internet to RPL-aware-leaf
	not-RPL-aware-leaf to Internet		not-RPL-aware-leaf to Internet
	Internet to not-RPL-aware-leaf		Internet to not-RPL-aware-leaf
	RPL-aware-leaf to RPL-aware-leaf		RPL-aware-leaf to RPL-aware-leaf (storing and non-storing)
	RPL-aware-leaf to not-RPL-aware-leaf		RPL-aware-leaf to not-RPL-aware-leaf (non-storing)
	not-RPL-aware-leaf to RPL-aware-leaf		not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing)
	not-RPL-aware-leaf to not-RPL-aware-leaf		not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing)
	This document assumes a rule that a Header cannot be inserted or		This document assumes the rule that a Header cannot be inserted or
	removed on the fly inside an IPv6 packet that is being routed. A		removed on the fly inside an IPv6 packet that is being routed. This
	fundamental precept of the IPv6 architecture as outlined in [RFC2460]		is a fundamental precept of the IPv6 architecture as outlined in
	is that Extensions may not be added or removed except by the sender		[RFC2460] is that Extensions may not be added or removed except by
	or the receiver.		the sender or the receiver. (A revision to RFC2460 considered
			changing this rule, but has kept it)
	Note: current discussions on [I-D.ietf-6man-rfc2460bis] related to		But, options in the Hop-by-Hop option which are marked with option
	extensions headers may affect some cases in this document (Ticket		type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD
	nro. 9) in 6man. [TO DO].		be ignored when received by a host or router which does not
			understand that option.
	A second important thing is that packets with a Hop-by-Hop option		This means that in general, any packet that leaves the RPL domain of
	which are marked with option type 01 ([RFC2460] section 4.2) must be		an LLN (or leaves the LLN entirely) will NOT be discarded, even if it
	discarded if received by a host or router which does not understand		has the [RFC6553] RPL Option Header known as the RPI or [RFC6554]
	that option. This means that in general, any packet that leaves the		SRH3 Extension Header (S)RH3.
	RPL domain of an LLN (or leaves the LLN entirely) is likely to be
	discarded if it still contains an [RFC6553] RPL Option Header known
	as the RPI.
	The combination of these two rules means that the arrangement of		With abolition of one of these rules it means that the RPI Hop-by-Hop
	headers must be done so that traffic intended to exit the RPL domain		option MAY be left in place even if the end host does host understand
	can have the RPI option removed prior to leaving the RPL domain.		it. This collapses many of the cases above (where it says "or")
	An intermediate router that needs to add a header must encapsulate		An intermediate router that needs to add an extension header (SHR3 or
	the packet in an (additional) outer IP header where the new header		RPI Option) must encapsulate the packet in an (additional) outer IP
	can be placed.		header where the new header can be placed.
	This also means that a Header can only be removed by an intermediate		This also means that a Header can only be removed by an intermediate
	router if it is placed in an encapsulating IPv6 Header, and in that		router if it is placed in an encapsulating IPv6 Header, and in that
	case, the whole encapsulating header must be removed - a replacement		case, the whole encapsulating header must be removed - a replacement
	may be added. Further, an intermediate router can only remove such		may be added. Further, an intermediate router can only remove such
	an outer header if that outer header has the router as the		an outer header if that outer header has the router as the
	destination!		destination!
	Both RPI and RH3 headers may be modified by routers on the path of		Both RPI and RH3 headers may be modified by routers on the path of
	the packet without the need to add or remove an encapsulating header.		the packet without the need to add to remove an encapsulating header.
	Both headers were designed with this modification in mind, and both		Both headers were designed with this modification in mind, and both
	the RPL RH and the RPL option are marked mutable but recoverable, so		the RPL RH and the RPL option are marked mutable but recoverable, so
	an IPsec AH security header can be applied across these headers, but		an IPsec AH security header can be applied across these headers, but
	it may not secure all the values in those headers.		it may not secure all the values in those headers.
	RPI should be present in every single RPL data packet. There is one		RPI should be present in every single RPL data packet. There is one
	exception in non-storing mode: when a packet is going down from the		exception in non-storing mode: when a packet is going down from the
	root. In a downward non-storing mode, the entire route is written,		root. In a downward non-storing mode, the entire route is written,
	so there can be no loops by construction, nor any confusion about		so there can be no loops by construction, nor any confusion about
	which forwarding table to use. There may be cases (such as in		which forwarding table to use. There may be cases (such as in
	6tisch) where the instanceID may still be needed to pick an		6tisch) where the instanceID may still be needed to pick an
	appropriate priority or channel at each hop.		appropriate priority or channel at each hop.
	The applicability for storing (RPL-SM) and non-Storing (RPL-NSM)
	modes for the previous cases is showed as follows:
	In the tables present in this document, the term "RPL aware leaf" is		In the tables present in this document, the term "RPL aware leaf" is
	has been shortened to "Raf", and "not-RPL aware leaf" has been		has been shortened to "Raf", and "not-RPL aware leaf" has been
	shortened to "~Raf" to make the table fit in available space.		shortened to "~Raf" to make the table fit in available space.
	The earlier examples are more extensive to make sure that the process		The earlier examples are more extensive to make sure that the process
	is clear, while later examples are more consise.		is clear, while later examples are more consise.
	5. Storing mode		5. Storing mode
	In storing mode (fully stateful), the sender cannot determine whether		In storing mode (fully stateful), the sender cannot determine whether
	skipping to change at page 10, line 16 ¶		skipping to change at page 10, line 16 ¶
	RPL-aware-leaf (6LN) --> 6LR --> 6LR,... --> root (6LBR)		RPL-aware-leaf (6LN) --> 6LR --> 6LR,... --> root (6LBR)
	As it was mentioned In this document 6LRs, 6LBR are always full-		As it was mentioned In this document 6LRs, 6LBR are always full-
	fledge RPL routers.		fledge RPL routers.
	The 6LN inserts the RPI header, and sends the packet to 6LR which		The 6LN inserts the RPI header, and sends the packet to 6LR which
	decrements the rank in RPI and sends the packet up. When the packet		decrements the rank in RPI and sends the packet up. When the packet
	arrives at 6LBR, the RPI is removed and the packet is processed.		arrives at 6LBR, the RPI is removed and the packet is processed.
			No IP-in-IP header is required.
	The RPI header can be removed by the 6LBR because the packet is		The RPI header can be removed by the 6LBR because the packet is
	addressed to the 6LBR. The 6LN must know that it is communicating		addressed to the 6LBR. The 6LN must know that it is communicating
	with the 6LBR to make use of this scenario. The 6LN can know the		with the 6LBR to make use of this scenario. The 6LN can know the
	address of the 6LBR because it knows the address of the root via the		address of the 6LBR because it knows the address of the root via the
	DODAGID in the DIO messages.		DODAGID in the DIO messages.
	+-------------------+-----+------+------+		+-------------------+-----+------+------+
	| Header | 6LN | 6LR | 6LBR |		| Header | 6LN | 6LR | 6LBR |
	+-------------------+-----+------+------+		+-------------------+-----+------+------+
	| Inserted headers | RPI | -- | -- |		| Inserted headers | RPI | -- | -- |
	skipping to change at page 11, line 23 ¶		skipping to change at page 11, line 23 ¶
	+-------------------+------+-------+------+		+-------------------+------+-------+------+
	Storing: Summary of the use of headers from root to RPL-aware-leaf		Storing: Summary of the use of headers from root to RPL-aware-leaf
	5.3. Example of Flow from root to not-RPL-aware-leaf		5.3. Example of Flow from root to not-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	root (6LBR)--> 6LR --> not-RPL-aware-leaf (6LN)		root (6LBR)--> 6LR --> not-RPL-aware-leaf (6LN)
	The question in this scenario is how the root knows how to address		As the RPI extension can be ignored by the not-RPL-aware leaf, this
	the IPv6-in-IPv6 header. It can not know that the destination isn't		situation is identical to the previous scenario.
	RPL aware, so it must insert an IPv6 header that can be removed on
	the last RPL aware node. Since the root can not know in a storing
	network where the last RPL aware node is, the IPv6-in-IPv6 header
	must be added hop-by-hop along the path from root to leaf.
	The root (6LBR) uses IPv6-in-IPv6 encapsulation to transmit
	information not related with the RPL domain. In the 6LBR the RPI
	header is inserted into an IPv6-in-IPv6 header addressed to the last
	6LR, which removes the header before it passes the packet to the IPv6
	node (6LN).
	An alternative option is to add an attribute in the RPL Target Option
	to indicate that the target is not RPL aware: future work may explore
	this possibility.
	+-------------------+---------------+---------------+------+		+-------------------+------+-----+------+
	| Header | 6LBR | 6LR | IPv6 |		| Header | 6LBR | 6LR | IPv6 |
	+-------------------+---------------+---------------+------+		+-------------------+------+-----+------+
	| Inserted headers | IP-in-IP(RPI) | -- | -- |		| Inserted headers | -- | -- | -- |
	| Removed headers | -- | IP-in-IP(RPI) | -- |		| Removed headers | -- | -- | -- |
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | -- | -- |		| Modified headers | -- | -- | -- |
	| Untouched headers | -- | -- | -- |		| Untouched headers | -- | -- | -- |
	+-------------------+---------------+---------------+------+		+-------------------+------+-----+------+
	Storing: Summary of the use of headers from root to not-RPL-aware-		Storing: Summary of the use of headers from root to not-RPL-aware-
	leaf		leaf
	5.4. Example of Flow from not-RPL-aware-leaf to root		5.4. Example of Flow from not-RPL-aware-leaf to root
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware-leaf (6LN) --> 6LR --> root (6LBR)		not-RPL-aware-leaf (6LN) --> 6LR --> root (6LBR)
	skipping to change at page 12, line 31 ¶		skipping to change at page 12, line 20 ¶
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | -- | -- |		| Modified headers | -- | -- | -- |
	| Untouched headers | -- | -- | -- |		| Untouched headers | -- | -- | -- |
	+-------------------+------+----------------+---------------+		+-------------------+------+----------------+---------------+
	Storing: Summary of the use of headers from not-RPL-aware-leaf to		Storing: Summary of the use of headers from not-RPL-aware-leaf to
	root		root
	5.5. Example of Flow from RPL-aware-leaf to Internet		5.5. Example of Flow from RPL-aware-leaf to Internet
	RPL information from RFC 6553 should not go out to Internet as it		RPL information from RFC 6553 MAY go out to Internet as it will be
	will cause the packet to be discarded at the first non-RPI aware		ignored by nodes which have not been configured to be RPI aware.
	router. The 6LBR must be able to take this information out before
	sending the packet upwards to the Internet. This requires the RPI
	header be placed in an IP-in-IP header that the root can remove.
	In this case the flow comprises:		In this case the flow comprises:
	RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) --> Internet		RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) --> Internet
	The 6LN will insert the RPI in a IPv6-in-IPv6 in a outer header,		No IP-in-IP header is required.
	which may be addressed to the 6LBR (root), or alternatively, it could
	be addressed hop-by-hop.
	+-----------------+---------------+------+---------------+----------+		+-------------------+------+------+------+----------+
	| Header | 6LN | 6LR | 6LBR | Internet |		| Header | 6LN | 6LR | 6LBR | Internet |
	+-----------------+---------------+------+---------------+----------+		+-------------------+------+------+------+----------+
	| Inserted | IP-in-IP(RPI) | -- | -- | -- |		| Inserted headers | RPI | -- | -- | -- |
	| headers | | | | |		| Removed headers | -- | -- | -- | -- |
	| Removed headers | -- | -- | IP-in-IP(RPI) | -- |		| Re-added headers | -- | -- | -- | -- |
	| Re-added | -- | -- | -- | -- |		| Modified headers | -- | RPI | -- | -- |
	| headers | | | | |		| Untouched headers | -- | -- | -- | -- |
	| Modified | -- | RPI | -- | -- |		+-------------------+------+------+------+----------+
	| headers | | | | |
	| Untouched | -- | -- | -- | -- |
	| headers | | | | |
	+-----------------+---------------+------+---------------+----------+
	Storing: Summary of the use of headers from RPL-aware-leaf to		Storing: Summary of the use of headers from RPL-aware-leaf to
	Internet		Internet
	5.6. Example of Flow from Internet to RPL-aware-leaf		5.6. Example of Flow from Internet to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR --> RPL-aware-leaf (6LN)		Internet --> root (6LBR) --> 6LR --> RPL-aware-leaf (6LN)
	skipping to change at page 14, line 44 ¶		skipping to change at page 14, line 12 ¶
	Storing: Summary of the use of headers from not-RPL-aware-leaf to		Storing: Summary of the use of headers from not-RPL-aware-leaf to
	Internet		Internet
	5.8. Example of Flow from Internet to non-RPL-aware-leaf		5.8. Example of Flow from Internet to non-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR --> not-RPL-aware-leaf (6LN)		Internet --> root (6LBR) --> 6LR --> not-RPL-aware-leaf (6LN)
	The 6LBR will have to add an RPI header within an IP-in-IP header.		The 6LBR will have to add an RPI header within an IP-in-IP header.
	The IP-in-IP will need to be addressed hop-by-hop along the path as		The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
	in storing mode, the 6LBR has no idea if the 6LN is RPL aware or not,		RPI inside.
	nor what the closest attached 6LR node is.
	The 6LBR MAY set the flow label on the inner IP-in-IP header to zero		The 6LBR MAY set the flow label on the inner IP-in-IP header to zero
	in order to aid in compression, as the packet will not emerge again		in order to aid in compression, as the packet will not emerge again
	from the LLN.		from the LLN.
	+-----------------+----------+---------------+---------------+------+		+-----------------+----------+---------------+---------------+------+
	| Header | Internet | 6LBR | 6LR | IPv6 |		| Header | Internet | 6LBR | 6LR | IPv6 |
	+-----------------+----------+---------------+---------------+------+		+-----------------+----------+---------------+---------------+------+
	| Inserted | -- | IP-in-IP(RPI) | -- | -- |		| Inserted | -- | IP-in-IP(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	skipping to change at page 15, line 37 ¶		skipping to change at page 14, line 51 ¶
	In this case the flow comprises:		In this case the flow comprises:
	6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN		6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN
	This case is assumed in the same RPL Domain. In the common parent,		This case is assumed in the same RPL Domain. In the common parent,
	the direction of RPI is changed (from increasing to decreasing the		the direction of RPI is changed (from increasing to decreasing the
	rank).		rank).
	While the 6LR nodes will update the RPI, no node needs to add or		While the 6LR nodes will update the RPI, no node needs to add or
	remove the RPI, so no IP-in-IP headers are necessary. The ability to		remove the RPI, so no IP-in-IP headers are necessary. This may be
	do this depends upon the sending the 6LN to know that the destination		done regardless of where the destination is, as the included RPI will
	is: a) inside the LLN, and b) RPL capable.		be ignored by the receiver.
	The sender can determine if the destination is inside the LLN by
	looking if the destination address is matched by the DIO's PIO
	option. This check may be modified by the use of backbone routers,
	but in this case it is assumed that the backbone routers are RPL
	capable and so can process the RPI header correctly.
	The other check, that the destination is RPL capable is not currently
	discernible by the sender. This information is necessary to
	distinguish this test case from Section 5.10.
	+-------------+-------+---------------+---------------+-----+-------+		+-------------+-------+---------------+---------------+-----+-------+
	| Header | 6LN | 6LR | 6LR (common | 6LR | 6LN |		| Header | 6LN | 6LR | 6LR (common | 6LR | 6LN |
	| | src | | parent) | | dst |		| | src | | parent) | | dst |
	+-------------+-------+---------------+---------------+-----+-------+		+-------------+-------+---------------+---------------+-----+-------+
	| Inserted | RPI | -- | -- | -- | -- |		| Inserted | RPI | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	| Removed | -- | -- | -- | -- | RPI |		| Removed | -- | -- | -- | -- | RPI |
	| headers | | | | | |		| headers | | | | | |
	| Re-added | -- | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- | -- |
	skipping to change at page 16, line 31 ¶		skipping to change at page 15, line 33 ¶
	Storing: Summary of the use of headers for RPL-aware-leaf to RPL-		Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
	aware-leaf		aware-leaf
	5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf		5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	6LN --> 6LR --> common parent (6LR) --> 6LR --> not-RPL-aware 6LN		6LN --> 6LR --> common parent (6LR) --> 6LR --> not-RPL-aware 6LN
	The sender, being aware out of band, that the receiver is not RPL		This situation is identical to the situation Section 5.9
	aware, adds an RPI header inside an IP-in-IP header. The IP-in-IP
	header needs to be addressed on a hop-by-hop basis so that the last
	6LR can remove the RPI header.
	,---.
	/ \
	( 6LR2 ) IP3,RPI,IP,ULP
	,-" .
	,-" `---' `.
	,' `.
	,---. ,-" `,---.
	/ +" / \
	( 6LR1 ) Remove the IP3,RPI( 6LR3 )
	\ / \ /
	/---' `---'|
	/ IP2,RPI,IP,ULP \
	/ |
	/ \
	,---+-. |
	/ \ +--+----+
	( 6LN ) | |
	\ / | IPv6 | IP,ULP
	`-----' | |
	IP1,RPI,IP,ULP +-------+
	Figure 3: Solution IPv6-in-IPv6 in each hop
	As we mentioned previously, packets with a Hop-by-Hop option which
	are marked with option type 01 ([RFC2460] section 4.2) must be
	discarded if received by a host or router which does not understand
	that option. This means that in general, any packet that leaves the
	RPL domain of an LLN (or leaves the LLN entirely) is likely to be
	discarded if it still contains an [RFC6553] RPL Option Header known
	as the RPI. For this case, if the definition of the Option Type
	field of RPL Option '01' were changed so that it isn't a "discard if
	not recognized", then no IP-in-IP header would be necessary. This
	change is an incompatible on-the-wire change and would require some
	kind of flag day, possibly a change that is done simultaenously with
	an updated 6LoRH compress.
	+--------+------------+------------+------------+------------+------+
	| Header | 6LN | 6LR | 6LR | 6LR | IPv6 |
	| | | | (common | | |
	| | | | parent) | | |
	+--------+------------+------------+------------+------------+------+
	| Insert | IP-in- | -- | -- | -- | -- |
	| ed hea | IP(RPI) | | | | |
	| ders | | | | | |
	| Remove | -- | -- | -- | IP-in- | -- |
	| d head | | | | IP(RPI) | |
	| ers | | | | | |
	| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |
	| header | | | | | |
	| s | | | | | |
	| Modifi | -- | IP-in- | IP-in- | -- | -- |
	| ed hea | | IP(RPI) | IP(RPI) | | |
	| ders | | | | | |
	| Untouc | -- | -- | -- | -- | -- |
	| hed he | | | | | |
	| aders | | | | | |
	+--------+------------+------------+------------+------------+------+
	Storing: Summary of the use of headers from RPL-aware-leaf to not-
	RPL-aware-leaf
	5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf		5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware 6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN		not-RPL-aware 6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN
	The 6LR receives the packet from the the IPv6 node and inserts and		The 6LR receives the packet from the the IPv6 node and inserts and
	the RPI header encapsulated in IPv6-in-IPv6 header. The IP-in-IP		the RPI header encapsulated in IPv6-in-IPv6 header. The IP-in-IP
	header could be addressed to the 6LN if the destination is known to		header is addressed to the destinion 6LN.
	the RPL aware, otherwise it must send the packet using a hop-by-hop
	IP-in-IP header. Similar considerations apply from section
	Section 5.10.
	+--------+------+------------+------------+------------+------------+		+--------+------+------------+------------+------------+------------+
	| Header | IPv6 | 6LR | common | 6LR | 6LN |		| Header | IPv6 | 6LR | common | 6LR | 6LN |
	| | | | parent | | |		| | | | parent | | |
	| | | | (6LR) | | |		| | | | (6LR) | | |
	+--------+------+------------+------------+------------+------------+		+--------+------+------------+------------+------------+------------+
	| Insert | -- | IP-in- | -- | -- | -- |		| Insert | -- | IP-in- | -- | -- | -- |
	| ed hea | | IP(RPI) | | | |		| ed hea | | IP(RPI) | | | |
	| ders | | | | | |		| ders | | | | | |
	| Remove | -- | -- | -- | -- | IP-in- |		| Remove | -- | -- | -- | -- | IP-in- |
	skipping to change at page 19, line 38 ¶		skipping to change at page 16, line 38 ¶
	Storing: Summary of the use of headers from not-RPL-aware-leaf to		Storing: Summary of the use of headers from not-RPL-aware-leaf to
	RPL-aware-leaf		RPL-aware-leaf
	5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf		5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware 6LN (IPv6 node)--> 6LR --> root (6LBR) --> 6LR --> not-		not-RPL-aware 6LN (IPv6 node)--> 6LR --> root (6LBR) --> 6LR --> not-
	RPL-aware 6LN (IPv6 node)		RPL-aware 6LN (IPv6 node)
	This flow combines the problems of the two previous sections. There		This flow is identical to Section 5.11
	is no choice at the first 6LR: it must insert an RPI, and to do that
	it must add an IP-in-IP header. That IP-in-IP header must be
	addressed on a hop-by-hop basis.
	+----------+-----+-------------+--------------+--------------+------+
	| Header | IPv | 6LR | 6LR (common | 6LR | IPv6 |
	| | 6 | | parent) | | dst |
	| | src | | | | |
	+----------+-----+-------------+--------------+--------------+------+
	| Inserted | -- | IP-in- | -- | -- | -- |
	| headers | | IP(RPI) | | | |
	| Removed | -- | -- | -- | IP-in- | -- |
	| headers | | | | IP(RPI) | |
	| Re-added | -- | IP-in- | IP-in- | IP-in- | -- |
	| headers | | IP(RPI) | IP(RPI) | IP(RPI) | |
	| Modified | -- | -- | -- | -- | -- |
	| headers | | | | | |
	| Untouche | -- | -- | -- | -- | -- |
	| d | | | | | |
	| headers | | | | | |
	+----------+-----+-------------+--------------+--------------+------+
	Storing: Summary of the use of headers from not-RPL-aware-leaf to
	not-RPL-aware-leaf
	6. Non Storing mode		6. Non Storing mode
	+--------------+------+------+-----------+---------------+		+--------------+------+------+-----------+---------------+
	| Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst |		| Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst |
	+--------------+------+------+-----------+---------------+		+--------------+------+------+-----------+---------------+
	| Raf to root | Yes | No | No | -- |		| Raf to root | Yes | No | No | -- |
	| root to Raf | Yes | Yes | No | -- |		| root to Raf | Yes | Yes | No | -- |
	| root to ~Raf | No | Yes | Yes | 6LR |		| root to ~Raf | No | Yes | Yes | 6LR |
	| ~Raf to root | Yes | No | Yes | root |		| ~Raf to root | Yes | No | Yes | root |
	| Raf to Int | Yes | No | Yes | root |		| Raf to Int | Yes | No | Yes | root |
	| Int to Raf | opt | Yes | Yes | dst |		| Int to Raf | opt | Yes | Yes | dst |
	| ~Raf to Int | Yes | No | Yes | root |		| ~Raf to Int | Yes | No | Yes | root |
	skipping to change at page 30, line 19 ¶		skipping to change at page 27, line 11 ¶
	In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-		In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-
	RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise		RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
	an IP-in-IP and RPI compression headers. The type of this case is		an IP-in-IP and RPI compression headers. The type of this case is
	critical since IP-in-IP is encapsulating a RPI header.		critical since IP-in-IP is encapsulating a RPI header.
	+--+-----+---+--------------+-----------+-------------+-------------+		+--+-----+---+--------------+-----------+-------------+-------------+
	|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |		|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
	+--+-----+---+--------------+-----------+-------------+-------------+		+--+-----+---+--------------+-----------+-------------+-------------+
	Figure 4: Critical IP-in-IP (RPI).		Figure 3: Critical IP-in-IP (RPI).
	9. IANA Considerations		9. IANA Considerations
	There are no IANA considerations related to this document.		There are no IANA considerations related to this document.
	10. Security Considerations		10. Security Considerations
	The security considerations covering of [RFC6553] and [RFC6554] apply		The security considerations covering of [RFC6553] and [RFC6554] apply
	when the packets get into RPL Domain.		when the packets get into RPL Domain.
	skipping to change at page 30, line 43 ¶		skipping to change at page 27, line 35 ¶
	Network (ITN) METRICS project (grant agreement No. 607728).		Network (ITN) METRICS project (grant agreement No. 607728).
	The authors would like to acknowledge the review, feedback, and		The authors would like to acknowledge the review, feedback, and
	comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van		comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van
	der Stok, Xavier Vilajosana and Thomas Watteyne.		der Stok, Xavier Vilajosana and Thomas Watteyne.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
			[I-D.ietf-6man-rfc2460bis]
			Deering, D. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", draft-ietf-6man-rfc2460bis-05 (work
			in progress), June 2016.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[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,
	skipping to change at page 31, line 26 ¶		skipping to change at page 28, line 26 ¶
	<http://www.rfc-editor.org/info/rfc6553>.		<http://www.rfc-editor.org/info/rfc6553>.
	[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6		[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554,		for Low-Power and Lossy Networks (RPL)", RFC 6554,
	DOI 10.17487/RFC6554, March 2012,		DOI 10.17487/RFC6554, March 2012,
	<http://www.rfc-editor.org/info/rfc6554>.		<http://www.rfc-editor.org/info/rfc6554>.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-6man-rfc2460bis]
	Deering, D. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", draft-ietf-6man-rfc2460bis-05 (work
	in progress), June 2016.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
	in progress), June 2016.		in progress), June 2016.
	[I-D.ietf-roll-routing-dispatch]		[I-D.ietf-roll-routing-dispatch]
	Thubert, P., Bormann, C., Toutain, L., and R. Cragie,		Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
	"6LoWPAN Routing Header", draft-ietf-roll-routing-		"6LoWPAN Routing Header", draft-ietf-roll-routing-
	dispatch-00 (work in progress), March 2016.		dispatch-00 (work in progress), March 2016.
End of changes. 36 change blocks.
	229 lines changed or deleted		103 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/