< draft-ietf-roll-useofrplinfo-09.txt		draft-ietf-roll-useofrplinfo-10.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 6550 (if approved) M. Richardson		Updates: 6550 (if approved) M. Richardson
	Intended status: Standards Track SSW		Intended status: Standards Track SSW
	Expires: April 24, 2017 P. Thubert		Expires: June 15, 2017 P. Thubert
	Cisco		Cisco
	October 21, 2016		December 12, 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-09		draft-ietf-roll-useofrplinfo-10
	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 April 24, 2017.		This Internet-Draft will expire on June 15, 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 17 ¶		skipping to change at page 2, line 17 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. 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 . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 9		5.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 10
	5.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 10		5.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 11
	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 . . . . . 12
	5.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 11		5.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 12
	5.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 12		5.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 13
	5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 12		5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 14
	5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 13		5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 14
	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 . . . 15
	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 . . 16
	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 17
	5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 17		5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 18
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18		leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 19		6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 20
	6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 20		6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 21
	6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 20		6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 22
	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 . . . . . 22
	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 . . . . . 23
	6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 23		6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 24
	6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 23		6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 25
	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 . . . 25
	6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 25		6.8. Example of Flow from Internet to not-RPL-aware-leaf . . . 26
	6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 26		6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 27
	6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 27		6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28
	6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 28		6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 29		leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	7. Observations about the cases . . . . . . . . . . . . . . . . 30		7. Observations about the cases . . . . . . . . . . . . . . . . 31
	7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 30		7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31
	7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 31		7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32
	8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 31		8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 32		10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	12.1. Normative References . . . . . . . . . . . . . . . . . . 32		12.1. Normative References . . . . . . . . . . . . . . . . . . 33
	12.2. Informative References . . . . . . . . . . . . . . . . . 33		12.2. Informative References . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	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 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Terminology defined in [RFC7102] applies to this document: LBR, LLN,		Terminology defined in [RFC7102] applies to this document: LBR, LLN,
	RPL, RPL Domain and ROLL.		RPL, RPL Domain and ROLL.
	RPL-node: It is device which implements RPL, thus we can say that the		RPL-node: It is device which implements RPL, thus we can say that the
	device is RPL-capable or RPL-aware. Please note that the device can		device is RPL-capable or RPL-aware. Please note that the device can
	be found inside the LLN or outside LLN. In this document a RPL-node		be found inside the LLN or outside LLN. In this document a RPL-node
	which is a leaf is called RPL-aware-leaf.		which is a leaf of a DODAG is called RPL-aware-leaf.
	RPL-not-capable: It is device which do not implement RPL, thus we can		RPL-not-capable: It is device which do not implement RPL, thus we can
	say that the device is not-RPL-aware. Please note that the device		say that the device is not-RPL-aware. Please note that the device
	can be found inside the LLN. In this document a not-RPL-node which		can be found inside the LLN. In this document a not-RPL-node which
	is a leaf is called not-RPL-aware-leaf.		is a leaf of a DODAG is called not-RPL-aware-leaf.
	2.1. hop-by-hop IPv6-in-IPv6 headers		2.1. hop-by-hop IPv6-in-IPv6 headers
	The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header		The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
	that originates from a node to an adjacent node, using the addresses		that originates from a node to an adjacent node, using the addresses
	(usually the GUA or ULA, but could use the link-local addresses) of		(usually the GUA or ULA, but could use the link-local addresses) of
	each node. If the packet must traverse multiple hops, then it must		each node. If the packet must traverse multiple hops, then it must
	be decapsulated at each hop, and then re-encapsulated again in a		be decapsulated at each hop, and then re-encapsulated again in a
	similar fashion.		similar fashion.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 33 ¶
	| | | | |		| | | | |
	| | | | |		| | | | |
	| 21 | 22 | 23 | 24 | 25		| 21 | 22 | 23 | 24 | 25
	+-+---+ +-+---+ +--+--+ +- --+ +---+-+		+-+---+ +-+---+ +--+--+ +- --+ +---+-+
	|Leaf | | | | | |Leaf| |Leaf |		|Leaf | | | | | |Leaf| |Leaf |
	| 6LN | | | | | | 6LN| | 6LN |		| 6LN | | | | | | 6LN| | 6LN |
	+-----+ +-----+ +-----+ +----+ +-----+		+-----+ +-----+ +-----+ +----+ +-----+
	Figure 2: A reference RPL Topology.		Figure 2: A reference RPL Topology.
	In Figure 2 is showed the reference RPL Topology for this document.		Figure 2 shows the reference RPL Topology for this document. The
	The numbers in or above the nodes are there so that they may be		numbers in or above the nodes are there so that they may be
	referenced in subsequent sections. In the figure, a 6LN can be a		referenced in subsequent sections. In the figure, a 6LN can be a
	router or a host. The 6LN leafs marked as (21) is a RPL host that		router or a host. The 6LN leafs marked as (21) is a RPL host that
	does not have forwarding capability and (25) is a RPL router. The		does not have forwarding capability and (25) is a RPL router. The
	leaf marked 6LN (24) is a device which does not speak RPL at all		leaf marked 6LN (24) is a device which does not speak RPL at all
	(not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and		(not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and
	efficient-ND only to participate in the network [RFC6775]. In the		efficient-ND only to participate in the network [RFC6775]. In the
	document this leaf (24) is often named IPv6 node. The 6LBR in the		document this leaf (24) is often named IPv6 node. The 6LBR in the
	figure is the root of the Global DODAG.		figure is the root of the Global DODAG.
	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
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 15 ¶
	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		This version of the document assumes the changes in
	[I-D.ietf-6man-rfc2460bis] are passed (at the time to write this		[I-D.ietf-6man-rfc2460bis] are passed (at the time to write this
	specification, the draft is on version 05).		specification, the draft is on version 05).
			The uses cases describe the communication between RPL-aware-nodes,
			with the root (6LBR), and with Internet. This document also describe
			the communication between nodes acting as leaf that does not
			understand RPL and they are part of hte LLN. We name these nodes as
			not-RPL-aware-leaf.(e.g. section 5.4- Flow from not-RPL-aware-leaf to
			root) We describe also how is the communication inside of the LLN
			when it has the final destination addressed outside of the LLN e.g.
			with destination to Internet. (e.g. section 5.7- Flow from not-RPL-
			aware-leaf to Internet)
			The uses cases comprise as follow:
	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
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 18 ¶
	But, options in the Hop-by-Hop option which are marked with option		But, options in the Hop-by-Hop option which are marked with option
	type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD		type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD
	be ignored when received by a host or router which does not		be ignored when received by a host or router which does not
	understand that option.		understand that option.
	This means that in general, any packet that leaves the RPL domain of		This means that in general, any packet that leaves the RPL domain of
	an LLN (or leaves the LLN entirely) will NOT be discarded, when it		an LLN (or leaves the LLN entirely) will NOT be discarded, when it
	has the [RFC6553] RPL Option Header known as the RPI or [RFC6554]		has the [RFC6553] RPL Option Header known as the RPI or [RFC6554]
	SRH3 Extension Header (S)RH3.		SRH3 Extension Header (S)RH3.
	The recent change to the second of these rules it means that the RPI		The recent change to the second of these rules means that the RPI
	Hop-by-Hop option MAY be left in place even if the end host does not		Hop-by-Hop option MAY be left in place even if the end host does not
	understand it.		understand it.
	NOTE: There is some possible security risk when the RPI information		NOTE: There is some possible security risk when the RPI information
	is released to the Internet. At this point this is a theoretical		is released to the Internet. At this point this is a theoretical
	situation. It is clear that the RPI option would waste some network		situation. It is clear that the RPI option would waste some network
	bandwidth when it escapes.		bandwidth when it escapes.
	An intermediate router that needs to add an extension header (SHR3 or		An intermediate router that needs to add an extension header (SHR3 or
	RPI Option) must encapsulate the packet in an (additional) outer IP		RPI Option) must encapsulate the packet in an (additional) outer IP
	skipping to change at page 8, line 50 ¶		skipping to change at page 9, line 13 ¶
	which forwarding table to use (as the root has already made all		which forwarding table to use (as the root has already made all
	routing decisions). There still may be cases (such as in 6tisch)		routing decisions). There still may be cases (such as in 6tisch)
	where the instanceID portion of the RPI header may still be needed to		where the instanceID portion of the RPI header may still be needed to
	pick an appropriate priority or channel at each hop.		pick an appropriate priority or channel at each hop.
	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 concise.
	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
	the destination is RPL-capable and thus would need an IP-in-IP		the destination is RPL-capable and thus would need an IP-in-IP
	header. The IP-in-IP header needs to be addressed on a hop-by-hop		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. Additionally,		basis so that the last 6LR can remove the RPI header. Additionally,
	The sender can determine if the destination is inside the LLN by		The sender can determine if the destination is inside the LLN by
	looking if the destination address is matched by the DIO's PIO		looking if the destination address is matched by the DIO's PIO
	option.		option.
	The following table summarizes what headers are needed in the		The following table summarizes what headers are needed in the
	following scenarios, and indicates when the IP-in-IP header must be		following scenarios, and indicates when the IP-in-IP header must be
	inserted on a hop-by-hop basis, and when it can target the		inserted on a hop-by-hop basis, and when it can target the
	destination node directly. There are three possible situations: hop-		destination node directly. There are these possible situations: hop-
	by-hop necessary (indicated by "hop"), or destination address		by-hop necessary (indicated by "hop"), or destination address
	possible (indicated by "dst"). In all cases hop by hop can be used.		possible (indicated by "dst"). In all cases hop by hop can be used.
	In cases where no IP-in-IP header is needed, the column is left		In cases where no IP-in-IP header is needed, the column is left
	blank.		blank.
	The leaf can be a router 6LR or a host, both indicated as 6LN.		In all cases the RPI headers are needed, since it identifies
			inconsistencies (loops) in the routing topology. In all cases the
			RH3 is not need because we do not indicate the route in stroing mode.
	+--------------+-------+-------+-----------+---------------+		The leaf can be a router 6LR or a host, both indicated as 6LN
	| Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst |		(Figure 2).
	+--------------+-------+-------+-----------+---------------+
	| Raf to root | Yes | No | No | -- |
	| root to Raf | Yes | No | No | -- |
	| root to ~Raf | Yes | No | No | -- |
	| ~Raf to root | Yes | No | Yes | root |
	| Raf to Int | Yes | No | No | -- |
	| Int to Raf | Yes | No | Yes | raf |
	| ~Raf to Int | Yes | No | Yes | root |
	| Int to ~Raf | Yes | No | Yes | hop |
	| Raf to Raf | Yes | No | No | -- |
	| Raf to ~Raf | Yes | No | No | -- |
	| ~Raf to Raf | Yes | No | Yes | dst |
	| ~Raf to ~Raf | Yes | No | Yes | hop |
	+--------------+-------+-------+-----------+---------------+
	Table 1: Headers needed in Storing mode: RPI, RH3, IP-in-IP		+--------------+-----------+---------------+
	encapsulation		| Use Case | IP-in-IP | IP-in-IP dst |
			+--------------+-----------+---------------+
			| Raf to root | No | -- |
			| root to Raf | No | -- |
			| root to ~Raf | No | -- |
			| ~Raf to root | Yes | root |
			| Raf to Int | No | -- |
			| Int to Raf | Yes | raf |
			| ~Raf to Int | root | raf |
			| ~Raf to Int | Yes | root |
			| Int to ~Raf | Yes | hop |
			| Raf to Raf | No | -- |
			| Raf to ~Raf | No | -- |
			| ~Raf to Raf | Yes | dst |
			| ~Raf to ~Raf | Yes | hop |
			+--------------+-----------+---------------+
			Table 1: IP-in-IP encapsulation in Storing mode
	5.1. Example of Flow from RPL-aware-leaf to root		5.1. Example of Flow from RPL-aware-leaf to root
	In storing mode, RFC 6553 (RPI) is used to send RPL Information		In storing mode, RFC 6553 (RPI) is used to send RPL Information
	instanceID and rank information.		instanceID and rank information.
	As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does		As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does
	not generally issue DIO messages; a leaf node accepts DIO messages		not generally issue DIO messages; a leaf node accepts DIO messages
	from upstream. (When the inconsistency in routing occurs, a leaf		from upstream. (When the inconsistency in routing occurs, a leaf
	node will generate a DIO with an infinite rank, to fix it). It may		node will generate a DIO with an infinite rank, to fix it). It may
	issue DAO and DIS messages though it generally ignores DAO and DIS		issue DAO and DIS messages though it generally ignores DAO and DIS
	messages.		messages.
	In this case the flow comprises:		In this case the flow comprises:
	RPL-aware-leaf (6LN) --> 6LR1,... --> 6LRN --> root (6LBR)		RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LN) to destination (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.		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_i | 6LBR |
	+-------------------+-----+------+------+		+-------------------+-----+-------+------+
	| Inserted headers | RPI | -- | -- |		| Inserted headers | RPI | -- | -- |
	| Removed headers | -- | -- | RPI |		| Removed headers | -- | -- | RPI |
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | RPI | -- |		| Modified headers | -- | RPI | -- |
	| Untouched headers | -- | -- | -- |		| Untouched headers | -- | -- | -- |
	+-------------------+-----+------+------+		+-------------------+-----+-------+------+
	Storing: Summary of the use of headers from RPL-aware-leaf to root		Storing: Summary of the use of headers from RPL-aware-leaf to root
	5.2. Example of Flow from root to RPL-aware-leaf		5.2. Example of Flow from root to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	root (6LBR) --> 6LR1,... --> 6LRN --> RPL-aware-leaf (6LN)		root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LBR) to destination (6LN).
	In this case the 6LBR inserts RPI header and sends the packet down,		In this case the 6LBR inserts RPI header and sends the packet down,
	the 6LR is going to increment the rank in RPI (examines instanceID		the 6LR is going to increment the rank in RPI (examines instanceID
	for multiple tables), the packet is processed in 6LN and RPI removed.		for multiple tables), the packet is processed in 6LN and RPI removed.
	No IP-in-IP header is required.		No IP-in-IP header is required.
	+-------------------+------+-------+------+		+-------------------+------+-------+------+
	| Header | 6LBR | 6LR | 6LN |		| Header | 6LBR | 6LR_i | 6LN |
	+-------------------+------+-------+------+		+-------------------+------+-------+------+
	| Inserted headers | RPI | -- | -- |		| Inserted headers | RPI | -- | -- |
	| Removed headers | -- | -- | RPI |		| Removed headers | -- | -- | RPI |
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | RPI | -- |		| Modified headers | -- | RPI | -- |
	| Untouched headers | -- | -- | -- |		| Untouched headers | -- | -- | -- |
	+-------------------+------+-------+------+		+-------------------+------+-------+------+
	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) --> 6LR1,... --> 6LRN --> not-RPL-aware-leaf (IPv6)		root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LBR) to destination (IPv6).
	As the RPI extension can be ignored by the not-RPL-aware leaf, this		As the RPI extension can be ignored by the not-RPL-aware leaf, this
	situation is identical to the previous scenario.		situation is identical to the previous scenario.
	+-------------------+------+-----------+----------------+		+-------------------+------+-------+----------------+
	| Header | 6LBR | 6LR(1..N) | 6LN |		| Header | 6LBR | 6LR_i | IPv6 |
	+-------------------+------+-----------+----------------+		+-------------------+------+-------+----------------+
	| Inserted headers | RPI | -- | -- |		| Inserted headers | RPI | -- | -- |
	| Removed headers | -- | -- | -- |		| Removed headers | -- | -- | -- |
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | RPI | -- |		| Modified headers | -- | RPI | -- |
	| Untouched headers | -- | -- | RPI (Ignored) |		| Untouched headers | -- | -- | RPI (Ignored) |
	+-------------------+------+-----------+----------------+		+-------------------+------+-------+----------------+
	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 (IPv6) --> 6LR1,... --> 6LRN --> root (6LBR)		not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR)
	When the packet arrives from IPv6 node to 6LR, the 6LR1 will insert		6LR_i are the intermediate routers from source to destination. In
	an RPI header, encapsuladed in a IPv6-in-IPv6 header. The IPv6-in-		this case, "1 < i >= n", n is the number of routers (6LR) that the
	IPv6 header can be addressed to the next hop, or to the root. The		packet go through from source (IPv6) to destination (6LBR). For
	root removes the header and processes the packet.		example, 6LR_1 (i=1) is the router that receives the packets from the
			IPv6 node.
			When the packet arrives from IPv6 node to 6LR_1, the 6LR_1 will
			insert a RPI header, encapsuladed in a IPv6-in-IPv6 header. The
			IPv6-in-IPv6 header can be addressed to the next hop, or to the root.
			The root removes the header and processes the packet.
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	| Header | IPv6 | 6LR1 | 6LRN | 6LBR |		| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	| Inserted | -- | IP-in-IP(RPI) | -- | -- |		| Inserted | -- | IP-in-IP(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Removed | -- | -- | -- | IP-in-IP(RPI) |		| Removed | -- | -- | -- | IP-in-IP(RPI) |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | -- | IP-in-IP(RPI) | -- |		| Modified | -- | -- | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- |
	skipping to change at page 12, line 30 ¶		skipping to change at page 13, line 30 ¶
	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 MAY go out to Internet as it will be		RPL information from RFC 6553 MAY go out to Internet as it will be
	ignored by nodes which have not been configured to be RPI aware.		ignored by nodes which have not been configured to be RPI aware.
	In this case the flow comprises:		In this case the flow comprises:
	RPL-aware-leaf (6LN) --> 6LR1,... --> 6LRN --> root (6LBR) -->		RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet
	Internet
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LN) to 6LBR.
	No IP-in-IP header is required.		No IP-in-IP header is required.
	+-------------------+------+-----------+------+----------------+		Note: In this use case we use a node as leaf, but this use case can
	| Header | 6LN | 6LR(1..N) | 6LBR | Internet |		be also applicable to any RPL-node type (e.g. 6LR)
	+-------------------+------+-----------+------+----------------+
	| Inserted headers | RPI | -- | -- | -- |		+-------------------+------+-------+------+----------------+
	| Removed headers | -- | -- | -- | -- |		| Header | 6LN | 6LR_i | 6LBR | Internet |
	| Re-added headers | -- | -- | -- | -- |		+-------------------+------+-------+------+----------------+
	| Modified headers | -- | RPI | -- | -- |		| Inserted headers | RPI | -- | -- | -- |
	| Untouched headers | -- | -- | -- | RPI (Ignored) |		| Removed headers | -- | -- | -- | -- |
	+-------------------+------+-----------+------+----------------+		| Re-added headers | -- | -- | -- | -- |
			| Modified headers | -- | RPI | -- | -- |
			| Untouched headers | -- | -- | -- | RPI (Ignored) |
			+-------------------+------+-------+------+----------------+
	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) --> 6LR1,... --> 6LRN --> RPL-aware-leaf		Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
	(6LN)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from 6LBR to destination(6LN).
	When the packet arrives from Internet to 6LBR the RPI header is added		When the packet arrives from Internet to 6LBR the RPI header is added
	in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the		in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the
	rank in the RPI. When the packet arrives at 6LN the RPI header is		rank in the RPI. When the packet arrives at 6LN the RPI header is
	removed and the packet processed.		removed and the packet processed.
	+----------+---------+--------------+---------------+---------------+		+----------+---------+--------------+---------------+---------------+
	| Header | Interne | 6LBR | 6LR(1...N) | 6LN |		| Header | Interne | 6LBR | 6LR_i | 6LN |
	| | t | | | |		| | t | | | |
	+----------+---------+--------------+---------------+---------------+		+----------+---------+--------------+---------------+---------------+
	| Inserted | -- | IP-in- | -- | -- |		| Inserted | -- | IP-in- | -- | -- |
	| headers | | IP(RPI) | | |		| headers | | IP(RPI) | | |
	| Removed | -- | -- | -- | IP-in-IP(RPI) |		| Removed | -- | -- | -- | IP-in-IP(RPI) |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | -- | IP-in-IP(RPI) | -- |		| Modified | -- | -- | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	skipping to change at page 13, line 37 ¶		skipping to change at page 14, line 44 ¶
	| headers | | | | |		| headers | | | | |
	+----------+---------+--------------+---------------+---------------+		+----------+---------+--------------+---------------+---------------+
	Storing: Summary of the use of headers from Internet to RPL-aware-		Storing: Summary of the use of headers from Internet to RPL-aware-
	leaf		leaf
	5.7. Example of Flow from not-RPL-aware-leaf to Internet		5.7. Example of Flow from not-RPL-aware-leaf to Internet
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware-leaf (IPv6) --> 6LR1,... --> 6LRN --> root (6LBR) -->		not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
	Internet		Internet
	The 6LR1 node will add an IP-in-IP(RPI) header addressed either to		6LR_i are the intermediate routers from source to destination. In
	the root, or hop-by-hop such that the root can remove the RPI header		this case, "1 < i >= n", n is the number of routers (6LR) that the
	before passing upwards.		packet go through from source(IPv6) to 6LBR.
			The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed
			either to the root, or hop-by-hop such that the root can remove the
			RPI header before passing upwards.
	The originating node will ideally leave the IPv6 flow label as zero		The originating node will ideally leave the IPv6 flow label as zero
	so that it can be better compressed through the LLN, and the 6LBR		so that the packet can be better compressed through the LLN. The
	will set the flow label to a non-zero value when sending to the		6LBR will set the flow label of the packet to a non-zero value when
	Internet.		sending to the Internet.
	+---------+-----+-------------+-------------+-------------+---------+		+---------+-----+-------------+-------------+-------------+---------+
	| Header | IPv | 6LR1 | 6LBN | 6LBR | Interne |		| Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne |
	| | 6 | | | | t |		| | 6 | | [i=2,..,n]_ | | t |
	+---------+-----+-------------+-------------+-------------+---------+		+---------+-----+-------------+-------------+-------------+---------+
	| Inserte | -- | IP-in- | -- | -- | -- |		| Inserte | -- | IP-in- | -- | -- | -- |
	| d | | IP(RPI) | | | |		| d | | IP(RPI) | | | |
	| headers | | | | | |		| headers | | | | | |
	| Removed | -- | -- | -- | IP-in- | -- |		| Removed | -- | -- | -- | IP-in- | -- |
	| headers | | | | IP(RPI) | |		| headers | | | | IP(RPI) | |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| headers | | | | | |		| headers | | | | | |
	| Modifie | -- | -- | IP-in- | -- | -- |		| Modifie | -- | -- | IP-in- | -- | -- |
	skipping to change at page 14, line 32 ¶		skipping to change at page 15, line 41 ¶
	| headers | | | | | |		| 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
	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) --> 6LR1,... --> 6LRN --> not-RPL-aware-leaf		Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
	(IPv6)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 < i >= n", n is the number of routers (6LR) that the
			packet go through from 6LBR to not-RPL-aware-leaf (IPv6).
	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 can be addressed to the not-RPL-aware-leaf, leaving the		The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
	RPI inside.		RPI inside.
	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.
	from the LLN.
	+-----------+----------+---------------+---------------+------------+		+-----------+----------+---------------+---------------+------------+
	| Header | Internet | 6LBR | 6LR(1...N) | IPv6 |		| Header | Internet | 6LBR | 6LR_i | IPv6 |
	+-----------+----------+---------------+---------------+------------+		+-----------+----------+---------------+---------------+------------+
	| Inserted | -- | IP-in-IP(RPI) | -- | -- |		| Inserted | -- | IP-in-IP(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Removed | -- | -- | IP-in-IP(RPI) | -- |		| Removed | -- | -- | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | -- | IP-in-IP(RPI) | -- |		| Modified | -- | -- | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	| Untouched | -- | -- | -- | RPI |		| Untouched | -- | -- | -- | RPI |
	skipping to change at page 15, line 31 ¶		skipping to change at page 16, line 31 ¶
	aware-leaf		aware-leaf
	5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf		5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf
	In [RFC6550] RPL allows a simple one-hop optimization for both		In [RFC6550] RPL allows a simple one-hop optimization for both
	storing and non-storing networks. A node may send a packet destined		storing and non-storing networks. A node may send a packet destined
	to a one-hop neighbor directly to that node. Section 9 in [RFC6550].		to a one-hop neighbor directly to that node. Section 9 in [RFC6550].
	In this case the flow comprises:		In this case the flow comprises:
	6LN --> 6LR1 --> common parent (6LRx) --> 6LRN --> 6LN		6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN
			6LR_ia are the intermediate routers from source to the common parent
			(6LR_x) In this case, "1 <= ia >= n", n is the number of routers
			(6LR) that the packet go through from 6LN to the common parent
			(6LR_x).
			6LR_id are the intermediate routers from the common parent (6LR_x) to
			destination 6LN. In this case, "1 <= id >= m", m is the number of
			routers (6LR) that the packet go through from the common parent
			(6LR_x) to destination 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. This may be		remove the RPI, so no IP-in-IP headers are necessary. This may be
	done regardless of where the destination is, as the included RPI will		done regardless of where the destination is, as the included RPI will
	be ignored by the receiver.		be ignored by the receiver.
	+------------+-------+---------------+---------------+------+-------+		+---------------+--------+--------+---------------+--------+--------+
	| Header | 6LN | 6LR1 | 6LRx (common | 6LRN | 6LN |		| Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN |
	| | src | | parent) | | dst |		| | src | | parent) | | dst |
	+------------+-------+---------------+---------------+------+-------+		+---------------+--------+--------+---------------+--------+--------+
	| Inserted | RPI | -- | -- | -- | -- |		| Inserted | RPI | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	| Removed | -- | -- | -- | -- | RPI |		| Removed | -- | -- | -- | -- | RPI |
	| headers | | | | | |		| headers | | | | | |
	| Re-added | -- | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	| Modified | -- | RPI | RPI | -- | -- |		| Modified | -- | RPI | RPI | RPI | -- |
	| headers | | (decreasing | (increasing | | |		| headers | | | | | |
	| | | rank) | rank) | | |		| Untouched | -- | -- | -- | -- | -- |
	| Untouched | -- | -- | -- | -- | -- |		| headers | | | | | |
	| headers | | | | | |		+---------------+--------+--------+---------------+--------+--------+
	+------------+-------+---------------+---------------+------+-------+
	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 --> 6LR1 --> common parent (6LRx) --> 6LRN --> not-RPL-aware 6LN		6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware
	(IPv6)		6LN (IPv6)
			6LR_ia are the intermediate routers from source (6LN) to the common
			parent (6LR_x) In this case, "1 <= ia >= n", n is the number of
			routers (6LR) that the packet go through from 6LN to the common
			parent (6LR_x).
			6LR_id are the intermediate routers from the common parent (6LR_x) to
			destination not-RPL-aware 6LN (IPv6). In this case, "1 <= id >= m",
			m is the number of routers (6LR) that the packet go through from the
			common parent (6LR_x) to destination 6LN.
	This situation is identical to the previous situation Section 5.9		This situation is identical to the previous situation Section 5.9
	+-----------+-----+-------------+-------------+------+--------------+		+-----------+------+--------+---------------+--------+--------------+
	| Header | 6LN | 6LR1 | 6LRx | 6LRN | IPv6 |		| Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 |
	| | src | | (common | | |		| | src | | parent) | | |
	| | | | parent) | | |		+-----------+------+--------+---------------+--------+--------------+
	+-----------+-----+-------------+-------------+------+--------------+		| Inserted | RPI | -- | -- | -- | -- |
	| Inserted | RPI | -- | -- | -- | -- |		| headers | | | | | |
	| headers | | | | | |		| Removed | -- | -- | -- | -- | RPI |
	| Removed | -- | -- | -- | -- | RPI |		| headers | | | | | |
	| headers | | | | | |		| Re-added | -- | -- | -- | -- | -- |
	| Re-added | -- | -- | -- | -- | -- |		| headers | | | | | |
	| headers | | | | | |		| Modified | -- | RPI | RPI | RPI | -- |
	| Modified | -- | RPI | RPI | -- | -- |		| headers | | | | | |
	| headers | | (decreasing | (increasing | | |		| Untouched | -- | -- | -- | -- | RPI(Ignored) |
	| | | rank) | rank) | | |		| headers | | | | | |
	| Untouched | -- | -- | -- | -- | RPI(Ignored) |		+-----------+------+--------+---------------+--------+--------------+
	| headers | | | | | |
	+-----------+-----+-------------+-------------+------+--------------+
	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.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 (IPv6) --> 6LR1 --> common parent (6LRx) --> 6LRN		not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) -->
	--> 6LN		6LR_id --> 6LN
	The 6LR1 receives the packet from the the IPv6 node and inserts and		6LR_ia are the intermediate routers from source (not-RPL-aware 6LN
	the RPI header encapsulated in IPv6-in-IPv6 header. The IP-in-IP		(IPv6)) to the common parent (6LR_x) In this case, "1 <= ia >= n", n
	header is addressed to the destination 6LN.		is the number of routers (6LR) that the packet go through from source
			to the common parent.
			6LR_id are the intermediate routers from the common parent (6LR_x) to
			destination 6LN. In this case, "1 <= id >= m", m is the number of
			routers (6LR) that the packet go through from the common parent
			(6LR_x) to destination 6LN.
			The 6LR_ia (ia=1) receives the packet from the the IPv6 node and
			inserts and the RPI header encapsulated in IPv6-in-IPv6 header. The
			IP-in-IP header is addressed to the destination 6LN.
	+--------+------+------------+------------+------------+------------+		+--------+------+------------+------------+------------+------------+
	| Header | IPv6 | 6LR1 | common | 6LRn | 6LN |		| Header | IPv6 | 6LR_ia | common | 6LR_id | 6LN |
	| | | | parent | | |		| | | | parent | | |
	| | | | (6LRx) | | |		| | | | (6LRx) | | |
	+--------+------+------------+------------+------------+------------+		+--------+------+------------+------------+------------+------------+
	| Insert | -- | IP-in- | -- | -- | -- |		| Insert | -- | IP-in- | -- | -- | -- |
	| ed hea | | IP(RPI) | | | |		| ed hea | | IP(RPI) | | | |
	| ders | | | | | |		| ders | | | | | |
	| Remove | -- | -- | -- | -- | IP-in- |		| Remove | -- | -- | -- | -- | IP-in- |
	| d head | | | | | IP(RPI) |		| d head | | | | | IP(RPI) |
	| ers | | | | | |		| ers | | | | | |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	skipping to change at page 18, line 35 ¶		skipping to change at page 19, line 35 ¶
	| aders | | | | | |		| aders | | | | | |
	+--------+------+------------+------------+------------+------------+		+--------+------+------------+------------+------------+------------+
	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 src)--> 6LR1 --> 6LR2 --> root (6LBR) -->		not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> root (6LBR) -->
	6LRn --> not-RPL-aware 6LN (IPv6 dst)		6LR_id --> not-RPL-aware 6LN (IPv6 dst)
			6LR_ia are the intermediate routers from source (not-RPL-aware 6LN
			(IPv6 src)) to the root (6LBR) In this case, "1 < ia >= n", n is the
			number of routers (6LR) that the packet go through from IPv6 src to
			the root.
			6LR_id are the intermediate routers from the root to destination
			(IPv6 dst). In this case, "1 <= id >= m", m is the number of routers
			(6LR) that the packet go through from the root to destination (IPv6
			dst).
	This flow is identical to Section 5.11		This flow is identical to Section 5.11
	The 6LR receives the packet from the the IPv6 node and inserts the		The 6LR_1 receives the packet from the the IPv6 node and inserts the
	RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-		RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-
	IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-		IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-
	IPv6 header and insert another one (RPIb) with destination to 6LRn		IPv6 header and insert another one (RPIb) with destination to 6LR_m
	node.		node.
	+-------+-----+-----------+-----------+-----------+-----------+-----+		+-------+-----+-----------+-----------+-----------+-----------+-----+
	| Heade | IPv | 6LR1 | 6LR2 | 6LBR | 6LRn | IPv |		| Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv |
	| r | 6 | | | | | 6 |		| r | 6 | | | | | 6 |
	| | src | | | | | dst |		| | src | | | | | dst |
	+-------+-----+-----------+-----------+-----------+-----------+-----+		+-------+-----+-----------+-----------+-----------+-----------+-----+
	| Inser | -- | IP-in- | -- | IP-in- | -- | -- |		| Inser | -- | IP-in- | -- | IP-in- | -- | -- |
	| ted h | | IP(RPIa) | | IP(RPIb) | | |		| ted h | | IP(RPI_a) | | IP(RPI_b) | | |
	| eader | | | | | | |		| eader | | | | | | |
	| s | | | | | | |		| s | | | | | | |
	| Remov | -- | -- | -- | -- | -- | -- |		| Remov | -- | -- | -- | -- | -- | -- |
	| ed he | | | | | | |		| ed he | | | | | | |
	| aders | | | | | | |		| aders | | | | | | |
	| Re- | -- | -- | -- | -- | IP-in- | -- |		| Re- | -- | -- | -- | -- | IP-in- | -- |
	| added | | | | | IP(RPIb) | |		| added | | | | | IP(RPI_b) | |
	| heade | | | | | | |		| heade | | | | | | |
	| rs | | | | | | |		| rs | | | | | | |
	| Modif | -- | -- | IP-in- | -- | IP-in- | -- |		| Modif | -- | -- | IP-in- | -- | IP-in- | -- |
	| ied h | | | IP(RPIa) | | IP(RPIb) | |		| ied h | | | IP(RPI_a) | | IP(RPI_b) | |
	| eader | | | | | | |		| eader | | | | | | |
	| s | | | | | | |		| s | | | | | | |
	| Untou | -- | -- | -- | -- | -- | -- |		| Untou | -- | -- | -- | -- | -- | -- |
	| ched | | | | | | |		| ched | | | | | | |
	| heade | | | | | | |		| heade | | | | | | |
	| rs | | | | | | |		| rs | | | | | | |
	+-------+-----+-----------+-----------+-----------+-----------+-----+		+-------+-----+-----------+-----------+-----------+-----------+-----+
	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
	non-RPL-aware-leaf		non-RPL-aware-leaf
	skipping to change at page 20, line 30 ¶		skipping to change at page 21, line 30 ¶
	Table 2: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP		Table 2: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
	encapsulation		encapsulation
	6.1. Example of Flow from RPL-aware-leaf to root		6.1. Example of Flow from RPL-aware-leaf to root
	In non-storing mode the leaf node uses default routing to send		In non-storing mode the leaf node uses default routing to send
	traffic to the root. The RPI header must be included to avoid/detect		traffic to the root. The RPI header must be included to avoid/detect
	loops.		loops.
	RPL-aware-leaf (6LN) --> 6LR --> root (6LBR)		RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LN) to destination (6LBR).
	This situation is the same case as storing mode.		This situation is the same case as storing mode.
	+-------------------+-----+------+------+		+-------------------+-----+-------+------+
	| Header | 6LN | 6LR | 6LBR |		| Header | 6LN | 6LR_i | 6LBR |
	+-------------------+-----+------+------+		+-------------------+-----+-------+------+
	| Inserted headers | RPI | -- | -- |		| Inserted headers | RPI | -- | -- |
	| Removed headers | -- | -- | RPI |		| Removed headers | -- | -- | RPI |
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | RPI | -- |		| Modified headers | -- | RPI | -- |
	| Untouched headers | -- | -- | -- |		| Untouched headers | -- | -- | -- |
	+-------------------+-----+------+------+		+-------------------+-----+-------+------+
	Non Storing: Summary of the use of headers from RPL-aware-leaf to		Non Storing: Summary of the use of headers from RPL-aware-leaf to
	root		root
	6.2. Example of Flow from root to RPL-aware-leaf		6.2. Example of Flow from root to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	root (6LBR)--> 6LR --> RPL-aware-leaf (6LN)		root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LBR) to destination (6LN).
	The 6LBR will insert an RH3, and may optionally insert an RPI header.		The 6LBR will insert an RH3, and may optionally insert an RPI header.
	No IP-in-IP header is necessary as the traffic originates with an RPL		No IP-in-IP header is necessary as the traffic originates with an RPL
	aware node, the 6LBR. The destination is known to RPL-aware because,		aware node, the 6LBR. The destination is known to RPL-aware because,
	the root knows the whole topology in non-storing mode.		the root knows the whole topology in non-storing mode.
	+-------------------+-----------------+------+----------+		+-------------------+-----------------+-------+----------+
	| Header | 6LBR | 6LR | 6LN |		| Header | 6LBR | 6LR_i | 6LN |
	+-------------------+-----------------+------+----------+		+-------------------+-----------------+-------+----------+
	| Inserted headers | (opt: RPI), RH3 | -- | -- |		| Inserted headers | (opt: RPI), RH3 | -- | -- |
	| Removed headers | -- | -- | RH3,RPI |		| Removed headers | -- | -- | RH3,RPI |
	| Re-added headers | -- | -- | -- |		| Re-added headers | -- | -- | -- |
	| Modified headers | -- | RH3 | -- |		| Modified headers | -- | RH3 | -- |
	| Untouched headers | -- | -- | -- |		| Untouched headers | -- | -- | -- |
	+-------------------+-----------------+------+----------+		+-------------------+-----------------+-------+----------+
	Non Storing: Summary of the use of headers from root to RPL-aware-		Non Storing: Summary of the use of headers from root to RPL-aware-
	leaf		leaf
	6.3. Example of Flow from root to not-RPL-aware-leaf		6.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)--> 6LR1...-->6LRn --> not-RPL-aware-leaf (IPv6)		root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
	In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR1 and		6LR_i are the intermediate routers from source to destination. In
	so on) and it is fully consumed in the last 6LR (6LRn), but left		this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LBR) to destination (IPv6).
			In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR_1
			and so on) and it is fully consumed in the last 6LR (6LR_n), but left
	there. If RPI is left present, the IPv6 node which does not		there. If RPI is left present, the IPv6 node which does not
	understand it will ignore it (following 2460bis), thus encapsulation		understand it will ignore it (following 2460bis), thus encapsulation
	is not necesary. Due the complete knowledge of the topology at the		is not necesary. Due the complete knowledge of the topology at the
	root, the 6LBR is able to address the IP-in-IP header to the last		root, the 6LBR is able to address the IP-in-IP header to the last
	6LR.		6LR.
	+----------------+--------------+--------------+-------------+------+		+---------------+-------------+---------------+--------------+------+
	| Header | 6LBR | 6LR1 | 6LRn | IPv6 |		| Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 |
	+----------------+--------------+--------------+-------------+------+		+---------------+-------------+---------------+--------------+------+
	| Inserted | (opt: RPI), | -- | -- | -- |		| Inserted | (opt: RPI), | -- | -- | -- |
	| headers | RH3 | | | |		| headers | RH3 | | | |
	| Removed | -- | RH3 | -- | -- |		| Removed | -- | RH3 | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | (opt: RPI), | (opt: RPI), | -- |		| Modified | -- | (opt: RPI), | (opt: RPI), | -- |
	| headers | | RH3 | RH3 | |		| headers | | RH3 | RH3 | |
	| Untouched | -- | -- | -- | RPI |		| Untouched | -- | -- | -- | RPI |
	| headers | | | | |		| headers | | | | |
	+----------------+--------------+--------------+-------------+------+		+---------------+-------------+---------------+--------------+------+
	Non Storing: Summary of the use of headers from root to not-RPL-		Non Storing: Summary of the use of headers from root to not-RPL-
	aware-leaf		aware-leaf
	6.4. Example of Flow from not-RPL-aware-leaf to root		6.4. Example of Flow from not-RPL-aware-leaf to root
	In this case the flow comprises:		In this case the flow comprises:
	IPv6-node --> 6LR1 ...--> 6LRn --> root (6LBR)		not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 < i >= n", n is the number of routers (6LR) that the
			packet go through from source (IPv6) to destination (6LBR). For
			example, 6LR_1 (i=1) is the router that receives the packets from the
			IPv6 node.
	In this case the RPI is added by the first 6LR (6LR1), encapsulated		In this case the RPI is added by the first 6LR (6LR1), encapsulated
	in an IP-in-IP header, and is modified in the followings 6LRs. The		in an IP-in-IP header, and is modified in the followings 6LRs. The
	RPI and entire packet is consumed by the root.		RPI and entire packet is consumed by the root.
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	| Header | IPv6 | 6LR1 | 6LR2 | 6LBR |		| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	| Inserted | -- | IP-in-IP(RPI) | -- | -- |		| Inserted | -- | IP-in-IP(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Removed | -- | -- | -- | IP-in-IP(RPI) |		| Removed | -- | -- | -- | IP-in-IP(RPI) |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | IP-in-IP(RPI) | IP-in-IP(RPI) | -- |		| Modified | -- | IP-in-IP(RPI) | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	Non Storing: Summary of the use of headers from not-RPL-aware-leaf to		Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
	root		root
	6.5. Example of Flow from RPL-aware-leaf to Internet		6.5. Example of Flow from RPL-aware-leaf to Internet
	In this case the flow comprises:		In this case the flow comprises:
	RPL-aware-leaf (6LN) --> 6LR1 ...--> 6LRn --> root (6LBR) -->		RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet
	Internet
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from source (6LN) to 6LBR.
	This case is identical to storing-mode case.		This case is identical to storing-mode case.
	The IPv6 flow label should be set to zero to aid in compression, and		The IPv6 flow label should be set to zero to aid in compression, and
	the 6LBR will set it to a non-zero value when sending towards the		the 6LBR will set it to a non-zero value when sending towards the
	Internet.		Internet.
	+-------------------+------+-----------+------+----------------+		+-------------------+------+-------+------+----------------+
	| Header | 6LN | 6LR(1..N) | 6LBR | Internet |		| Header | 6LN | 6LR_i | 6LBR | Internet |
	+-------------------+------+-----------+------+----------------+		+-------------------+------+-------+------+----------------+
	| Inserted headers | RPI | -- | -- | -- |		| Inserted headers | RPI | -- | -- | -- |
	| Removed headers | -- | -- | -- | -- |		| Removed headers | -- | -- | -- | -- |
	| Re-added headers | -- | -- | -- | -- |		| Re-added headers | -- | -- | -- | -- |
	| Modified headers | -- | RPI | -- | -- |		| Modified headers | -- | RPI | -- | -- |
	| Untouched headers | -- | -- | -- | RPI (Ignored) |		| Untouched headers | -- | -- | -- | RPI (Ignored) |
	+-------------------+------+-----------+------+----------------+		+-------------------+------+-------+------+----------------+
	Non Storing: Summary of the use of headers from RPL-aware-leaf to		Non Storing: Summary of the use of headers from RPL-aware-leaf to
	Internet		Internet
	6.6. Example of Flow from Internet to RPL-aware-leaf		6.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) --> 6LR1...--> 6LRn --> RPL-aware-leaf (6LN)		Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 <= i >= n", n is the number of routers (6LR) that the
			packet go through from 6LBR to destination(6LN).
	The 6LBR must add an RH3 header. As the 6LBR will know the path and		The 6LBR must add an RH3 header. As the 6LBR will know the path and
	address of the target node, it can address the IP-in-IP header to		address of the target node, it can address the IP-in-IP header to
	that node. The 6LBR will zero the flow label upon entry in order to		that node. The 6LBR will zero the flow label upon entry in order to
	aid compression.		aid compression.
	The RPI may be added or not, it is optional.		The RPI may be added or not, it is optional.
	+--------+-------+----------------+----------------+----------------+		+--------+-------+----------------+----------------+----------------+
	| Header | Inter | 6LBR | 6LR | 6LN |		| Header | Inter | 6LBR | 6LR_i | 6LN |
	| | net | | | |		| | net | | | |
	+--------+-------+----------------+----------------+----------------+		+--------+-------+----------------+----------------+----------------+
	| Insert | -- | IP-in-IP(RH3,o | -- | -- |		| Insert | -- | IP-in-IP(RH3,o | -- | -- |
	| ed hea | | pt:RPI) | | |		| ed hea | | pt:RPI) | | |
	| ders | | | | |		| ders | | | | |
	| Remove | -- | -- | -- | IP-in-IP(RH3,o |		| Remove | -- | -- | -- | IP-in-IP(RH3,o |
	| d head | | | | pt:RPI) |		| d head | | | | pt:RPI) |
	| ers | | | | |		| ers | | | | |
	| Re- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- |
	| added | | | | |		| added | | | | |
	skipping to change at page 24, line 34 ¶		skipping to change at page 25, line 51 ¶
	| aders | | | | |		| aders | | | | |
	+--------+-------+----------------+----------------+----------------+		+--------+-------+----------------+----------------+----------------+
	Non Storing: Summary of the use of headers from Internet to RPL-		Non Storing: Summary of the use of headers from Internet to RPL-
	aware-leaf		aware-leaf
	6.7. Example of Flow from not-RPL-aware-leaf to Internet		6.7. Example of Flow from not-RPL-aware-leaf to Internet
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware-leaf (IPv6) --> 6LR1..--> 6LRn --> root (6LBR) -->		not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
	Internet		Internet
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 < i >= n", n is the number of routers (6LR) that the
			packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1).
	In this case the flow label is recommended to be zero in the IPv6		In this case the flow label is recommended to be zero in the IPv6
	node. As RPL headers are added in the IPv6 node, the first 6LN will		node. As RPL headers are added in the IPv6 node, the first 6LR
	add an RPI header inside a new IP-in-IP header. The IP-in-IP header		(6LR_1) will add an RPI header inside a new IP-in-IP header. The IP-
	will be addressed to the root. This case is identical to the		in-IP header will be addressed to the root. This case is identical
	storing-mode case (Section 5.7).		to the storing-mode case (Section 5.7).
	+---------+-----+-------------+-------------+-------------+---------+		+---------+-----+-------------+-------------+-------------+---------+
	| Header | IPv | 6LR1 | 6LRn | 6LBR | Interne |		| Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne |
	| | 6 | | | | t |		| | 6 | | [i=2,..,n]_ | | t |
	+---------+-----+-------------+-------------+-------------+---------+		+---------+-----+-------------+-------------+-------------+---------+
	| Inserte | -- | IP-in- | -- | -- | -- |		| Inserte | -- | IP-in- | -- | -- | -- |
	| d | | IP(RPI) | | | |		| d | | IP(RPI) | | | |
	| headers | | | | | |		| headers | | | | | |
	| Removed | -- | -- | -- | IP-in- | -- |		| Removed | -- | -- | -- | IP-in- | -- |
	| headers | | | | IP(RPI) | |		| headers | | | | IP(RPI) | |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| headers | | | | | |		| headers | | | | | |
	| Modifie | -- | -- | IP-in- | -- | -- |		| Modifie | -- | -- | IP-in- | -- | -- |
	| d | | | IP(RPI) | | |		| d | | | IP(RPI) | | |
	| headers | | | | | |		| headers | | | | | |
	| Untouch | -- | -- | -- | -- | -- |		| Untouch | -- | -- | -- | -- | -- |
	| ed | | | | | |		| ed | | | | | |
	| headers | | | | | |		| headers | | | | | |
	+---------+-----+-------------+-------------+-------------+---------+		+---------+-----+-------------+-------------+-------------+---------+
	Non Storing: Summary of the use of headers from not-RPL-aware-leaf to		Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
	Internet		Internet
	6.8. Example of Flow from Internet to non-RPL-aware-leaf		6.8. Example of Flow from Internet to not-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR1...--> 6LRn --> not-RPL-aware-leaf		Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
	(IPv6)
			6LR_i are the intermediate routers from source to destination. In
			this case, "1 < i >= n", n is the number of routers (6LR) that the
			packet go through from 6LBR to not-RPL-aware-leaf (IPv6).
	The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR		The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR
	will know the path, and will recognize that the final node is not an		will know the path, and will recognize that the final node is not an
	RPL capable node as it will have received the connectivity DAO from		RPL capable node as it will have received the connectivity DAO from
	the nearest 6LR. The 6LBR can therefore make the IP-in-IP header		the nearest 6LR. The 6LBR can therefore make the IP-in-IP header
	destination be the last 6LR. The 6LBR will set to zero the flow		destination be the last 6LR. The 6LBR will set to zero the flow
	label upon entry in order to aid compression.		label upon entry in order to aid compression.
	+--------+-------+-----------------+------------+------------+------+		+--------+-------+----------------+------------+-------------+------+
	| Header | Inter | 6LBR | 6LR1 | 6LRn | IPv6 |		| Header | Inter | 6LBR | 6LR_1 | 6LR_i(i=2,. | IPv6 |
	| | net | | | | |		| | net | | | .,n) | |
	+--------+-------+-----------------+------------+------------+------+		+--------+-------+----------------+------------+-------------+------+
	| Insert | -- | IP-in- | -- | -- | -- |		| Insert | -- | IP-in-IP(RH3,o | -- | -- | -- |
	| ed hea | | IP(RH3,opt:RPI) | | | |		| ed hea | | pt:RPI) | | | |
	| ders | | | | | |		| ders | | | | | |
	| Remove | -- | -- | -- | IP-in- | -- |		| Remove | -- | -- | -- | IP-in- | -- |
	| d head | | | | IP(RH3, | |		| d head | | | | IP(RH3, | |
	| ers | | | | RPI) | |		| ers | | | | RPI) | |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| header | | | | | |		| header | | | | | |
	| s | | | | | |		| s | | | | | |
	| Modifi | -- | -- | IP-in- | IP-in- | -- |		| Modifi | -- | -- | IP-in- | IP-in- | -- |
	| ed hea | | | IP(RH3, | IP(RH3, | |		| ed hea | | | IP(RH3, | IP(RH3, | |
	| ders | | | RPI) | RPI) | |		| ders | | | RPI) | RPI) | |
	| Untouc | -- | -- | -- | -- | RPI |		| Untouc | -- | -- | -- | -- | RPI |
	| hed he | | | | | |		| hed he | | | | | |
	| aders | | | | | |		| aders | | | | | |
	+--------+-------+-----------------+------------+------------+------+		+--------+-------+----------------+------------+-------------+------+
	NonStoring: Summary of the use of headers from Internet to non-RPL-		NonStoring: Summary of the use of headers from Internet to non-RPL-
	aware-leaf		aware-leaf
	6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf		6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	6LN --> 6LR1 --> root (6LBR) --> 6LRN --> 6LN		6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst
			6LR_ia are the intermediate routers from source to the root In this
			case, "1 <= ia >= n", n is the number of routers (6LR) that the
			packet go through from 6LN to the root.
			6LR_id are the intermediate routers from the root to the destination.
			In this case, "1 <= ia >= m", m is the number of the intermediate
			routers (6LR).
	This case involves only nodes in same RPL Domain. The originating		This case involves only nodes in same RPL Domain. The originating
	node will add an RPI header to the original packet, and send the		node will add an RPI header to the original packet, and send the
	packet upwards.		packet upwards.
	The originating node SHOULD put the RPI into an IP-in-IP header		The originating node SHOULD put the RPI into an IP-in-IP header
	addressed to the root, so that the 6LBR can remove that header. If		addressed to the root, so that the 6LBR can remove that header. If
	it does not, then additional resources are wasted on the way down to		it does not, then additional resources are wasted on the way down to
	carry the useless RPI option.		carry the useless RPI option.
	The 6LBR will need to insert an RH3 header, which requires that it		The 6LBR will need to insert an RH3 header, which requires that it
	add an IP-in-IP header. It SHOULD be able to remove the RPI, as it		add an IP-in-IP header. It SHOULD be able to remove the RPI, as it
	was contained in an IP-in-IP header addressed to it. Otherwise,		was contained in an IP-in-IP header addressed to it. Otherwise,
	there MAY be an RPI header buried inside the inner IP header, which		there MAY be an RPI header buried inside the inner IP header, which
	should get ignored.		should get ignored.
	Networks that use the RPL P2P extension [RFC6997] are essentially		Networks that use the RPL P2P extension [RFC6997] are essentially
	non-storing DODAGs and fall into this scenario or scenario		non-storing DODAGs and fall into this scenario or scenario
	Section 6.2, with the originating node acting as 6LBR.		Section 6.2, with the originating node acting as 6LBR.
	+---------+-------------+------+--------------+------+--------------+		+---------+-------------+------+--------------+-------+-------------+
	| Header | 6LN src | 6LR1 | 6LBR | 6LRN | 6LN dst |		| Header | 6LN src | 6LR_ | 6LBR | 6LR_i | 6LN dst |
	+---------+-------------+------+--------------+------+--------------+		| | | ia | | d | |
	| Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |		+---------+-------------+------+--------------+-------+-------------+
	| d | IP(RPI1) | | to 6LN, opt | | |		| Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |
	| headers | | | RPI2) | | |		| d | IP(RPI1) | | to 6LN, opt | | |
	| Removed | -- | -- | IP-in- | -- | IP-in- |		| headers | | | RPI2) | | |
	| headers | | | IP(RPI1) | | IP(RH3, opt |		| Removed | -- | -- | IP-in- | -- | IP-in- |
	| | | | | | RPI2) |		| headers | | | IP(RPI1) | | IP(RH3, opt |
	| Re- | -- | -- | -- | -- | -- |		| | | | | | RPI2) |
	| added | | | | | |		| Re- | -- | -- | -- | -- | -- |
	| headers | | | | | |		| added | | | | | |
	| Modifie | -- | -- | -- | -- | -- |		| headers | | | | | |
	| d | | | | | |		| Modifie | -- | -- | -- | -- | -- |
	| headers | | | | | |		| d | | | | | |
	| Untouch | -- | -- | -- | -- | -- |		| headers | | | | | |
	| ed | | | | | |		| Untouch | -- | -- | -- | -- | -- |
	| headers | | | | | |		| ed | | | | | |
	+---------+-------------+------+--------------+------+--------------+		| headers | | | | | |
			+---------+-------------+------+--------------+-------+-------------+
	Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-		Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
	aware-leaf		aware-leaf
	6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf		6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	6LN --> 6LR1 --> root (6LBR) --> 6LRn --> not-RPL-aware (IPv6)		6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6)
	As in the previous case, the 6LN will insert an RPI (RPI1) header		6LR_ia are the intermediate routers from source to the root In this
			case, "1 <= ia >= n", n is the number of intermediate routers (6LR)
			6LR_id are the intermediate routers from the root to the destination.
			In this case, "1 <= ia >= m", m is the number of the intermediate
			routers (6LR).
			As in the previous case, the 6LN will insert an RPI (RPI_1) header
	which MUST be in an IP-in-IP header addressed to the root so that the		which MUST be in an IP-in-IP header addressed to the root so that the
	6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a		6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a
	new IP-in-IP header addressed to the 6LN destination node. The RPI		new IP-in-IP header addressed to the 6LN destination node. The RPI
	is optional from 6LBR to 6LRn (RPI2).		is optional from 6LBR to 6LR_id (RPI_2).
	+--------+------------+------------+------------+------------+------+		+--------+-----------+------------+-------------+------------+------+
	| Header | 6LN | 6LR1 | 6LBR | 6LRn | IPv6 |		| Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 |
	+--------+------------+------------+------------+------------+------+		+--------+-----------+------------+-------------+------------+------+
	| Insert | IP-in- | -- | IP-in- | -- | -- |		| Insert | IP-in- | -- | IP-in- | -- | -- |
	| ed hea | IP(RPI1) | | IP(RH3, | | |		| ed hea | IP(RPI1) | | IP(RH3, opt | | |
	| ders | | | opt RPI2) | | |		| ders | | | RPI_2) | | |
	| Remove | -- | -- | IP-in- | IP-in- | -- |		| Remove | -- | -- | IP-in- | IP-in- | -- |
	| d head | | | IP(RPI1) | IP(RH3, | |		| d head | | | IP(RPI_1) | IP(RH3, | |
	| ers | | | | opt RPI2) | |		| ers | | | | opt RPI_2) | |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| header | | | | | |		| header | | | | | |
	| s | | | | | |		| s | | | | | |
	| Modifi | -- | IP-in- | -- | IP-in- | -- |		| Modifi | -- | IP-in- | -- | IP-in- | -- |
	| ed hea | | IP(RPI1) | | IP(RH3, | |		| ed hea | | IP(RPI_1) | | IP(RH3, | |
	| ders | | | | opt RPI2) | |		| ders | | | | opt RPI_2) | |
	| Untouc | -- | -- | -- | -- | opt |		| Untouc | -- | -- | -- | -- | opt |
	| hed he | | | | | RPI2 |		| hed he | | | | | RPI_ |
	| aders | | | | | |		| aders | | | | | 2 |
	+--------+------------+------------+------------+------------+------+		+--------+-----------+------------+-------------+------------+------+
	Non Storing: Summary of the use of headers from RPL-aware-leaf to		Non Storing: Summary of the use of headers from RPL-aware-leaf to
	not-RPL-aware-leaf		not-RPL-aware-leaf
	6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf		6.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 (IPv6) --> 6LR1 --> root (6LBR) --> 6LRn --> 6LN		not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id -->
			6LN
			6LR_ia are the intermediate routers from source to the root In this
			case, "1 <= ia >= n", n is the number of intermediate routers (6LR)
			6LR_id are the intermediate routers from the root to the destination.
			In this case, "1 <= ia >= m", m is the number of the intermediate
			routers (6LR).
	This scenario is mostly identical to the previous one. The RPI is		This scenario is mostly identical to the previous one. The RPI is
	added by the first 6LR (6LR1) inside an IP-in-IP header addressed to		added by the first 6LR (6LR_1) inside an IP-in-IP header addressed to
	the root. The 6LBR will remove this RPI, and add it's own IP-in-IP		the root. The 6LBR will remove this RPI, and add it's own IP-in-IP
	header containing an RH3 header and optional RPI (RPI2).		header containing an RH3 header and optional RPI (RPI_2).
	+--------+-----+------------+-------------+------------+------------+		+--------+-----+------------+-------------+------------+------------+
	| Header | IPv | 6LR1 | 6LBR | 6LRn | 6LN |		| Header | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN |
	| | 6 | | | | |		| | 6 | | | | |
	+--------+-----+------------+-------------+------------+------------+		+--------+-----+------------+-------------+------------+------------+
	| Insert | -- | IP-in- | IP-in- | -- | -- |		| Insert | -- | IP-in- | IP-in- | -- | -- |
	| ed hea | | IP(RPI1) | IP(RH3, opt | | |		| ed hea | | IP(RPI_1) | IP(RH3, opt | | |
	| ders | | | RPI2) | | |		| ders | | | RPI_2) | | |
	| Remove | -- | -- | IP-in- | -- | IP-in- |		| Remove | -- | -- | IP-in- | -- | IP-in- |
	| d head | | | IP(RPI1) | | IP(RH3, |		| d head | | | IP(RPI_1) | | IP(RH3, |
	| ers | | | | | opt RPI2) |		| ers | | | | | opt RPI_2) |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| header | | | | | |		| header | | | | | |
	| s | | | | | |		| s | | | | | |
	| Modifi | -- | -- | -- | IP-in- | -- |		| Modifi | -- | -- | -- | IP-in- | -- |
	| ed hea | | | | IP(RH3, | |		| ed hea | | | | IP(RH3, | |
	| ders | | | | opt RPI2) | |		| ders | | | | opt RPI_2) | |
	| Untouc | -- | -- | -- | -- | -- |		| Untouc | -- | -- | -- | -- | -- |
	| hed he | | | | | |		| hed he | | | | | |
	| aders | | | | | |		| aders | | | | | |
	+--------+-----+------------+-------------+------------+------------+		+--------+-----+------------+-------------+------------+------------+
	Non Storing: Summary of the use of headers from not-RPL-aware-leaf to		Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
	RPL-aware-leaf		RPL-aware-leaf
	6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf		6.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 src)--> 6LR1 --> root (6LBR) --> 6LRn -->		not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id -->
	not-RPL-aware (IPv6 dst)		not-RPL-aware (IPv6 dst)
			6LR_ia are the intermediate routers from source to the root In this
			case, "1 <= ia >= n", n is the number of intermediate routers (6LR)
			6LR_id are the intermediate routers from the root to the destination.
			In this case, "1 <= ia >= m", m is the number of the intermediate
			routers (6LR).
	This scenario is the combination of the previous two cases.		This scenario is the combination of the previous two cases.
	+---------+-----+--------------+--------------+--------------+------+		+---------+-----+--------------+---------------+-------------+------+
	| Header | IPv | 6LR1 | 6LBR | 6LRn | IPv6 |		| Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 |
	| | 6 | | | | dst |		| | 6 | | | | dst |
	| | src | | | | |		| | src | | | | |
	+---------+-----+--------------+--------------+--------------+------+		+---------+-----+--------------+---------------+-------------+------+
	| Inserte | -- | IP-in- | IP-in- | -- | -- |		| Inserte | -- | IP-in- | IP-in-IP(RH3) | -- | -- |
	| d | | IP(RPI1) | IP(RH3) | | |		| d | | IP(RPI_1) | | | |
	| headers | | | | | |		| headers | | | | | |
	| Removed | -- | -- | IP-in- | IP-in- | -- |		| Removed | -- | -- | IP-in- | IP-in- | -- |
	| headers | | | IP(RPI1) | IP(RH3, opt | |		| headers | | | IP(RPI_1) | IP(RH3, opt | |
	| | | | | RPI2) | |		| | | | | RPI_2) | |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| headers | | | | | |		| headers | | | | | |
	| Modifie | -- | -- | -- | -- | -- |		| Modifie | -- | -- | -- | -- | -- |
	| d | | | | | |		| d | | | | | |
	| headers | | | | | |		| headers | | | | | |
	| Untouch | -- | -- | -- | -- | -- |		| Untouch | -- | -- | -- | -- | -- |
	| ed | | | | | |		| ed | | | | | |
	| headers | | | | | |		| headers | | | | | |
	+---------+-----+--------------+--------------+--------------+------+		+---------+-----+--------------+---------------+-------------+------+
	Non Storing: Summary of the use of headers from not-RPL-aware-leaf to		Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
	not-RPL-aware-leaf		not-RPL-aware-leaf
	7. Observations about the cases		7. Observations about the cases
	7.1. Storing mode		7.1. Storing mode
	[I-D.ietf-roll-routing-dispatch] shows that this hop-by-hop IP-in-IP		[I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP
	header can be compressed down to {TBD} bytes.		header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header
			as described in Section 7 of the document.
	There are potential significant advantages to having a single code		There are potential significant advantages to having a single code
	path that always processes IP-in-IP headers with no options.		path that always processes IP-in-IP headers with no options.
	Thanks to the relaxation of the RFC2406 rule about discarding unknown		Thanks to the relaxation of the RFC2406 rule about discarding unknown
	Hop-by-Hop options, there is no longer any uncertainty about when to		Hop-by-Hop options, there is no longer any uncertainty about when to
	use an IPIP header in the storing mode case. The RPI header SHOULD		use an IPIP header in the storing mode case. The RPI header SHOULD
	always be added when 6LRs originate packets (without IPIP headers),		always be added when 6LRs originate packets (without IPIP headers),
	and IPIP headers should always be added (addressed to the root when		and IPIP headers should always be added (addressed to the root when
	on the way up, to the end-host when on the way down) when a 6LR finds		on the way up, to the end-host when on the way down) when a 6LR finds
	it needs to insert an RPI header. (XXX - this is a problem for		it needs to insert an RPI header.
	storing mode optimization)
	In order to support the above two cases with full generality, the		In order to support the above two cases with full generality, the
	different situations (always do IP-in-IP vs never use IP-in-IP)		different situations (always do IP-in-IP vs never use IP-in-IP)
	should be signaled in the RPL protocol itself.		should be signaled in the RPL protocol itself.
	7.2. Non-Storing mode		7.2. Non-Storing mode
	In the non-storing case, dealing with non-RPL aware leaf nodes is		In the non-storing case, dealing with non-RPL aware leaf nodes is
	much easier as the 6LBR (DODAG root) has complete knowledge about the		much easier as the 6LBR (DODAG root) has complete knowledge about the
	connectivity of all DODAG nodes, and all traffic flows through the		connectivity of all DODAG nodes, and all traffic flows through the
	skipping to change at page 32, line 25 ¶		skipping to change at page 33, line 25 ¶
	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]		[I-D.ietf-6man-rfc2460bis]
	Deering, S. and R. Hinden, "Internet Protocol, Version 6		Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", draft-ietf-6man-rfc2460bis-07 (work		(IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work
	in progress), October 2016.		in progress), November 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, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	skipping to change at page 33, line 21 ¶		skipping to change at page 34, line 21 ¶
	12.2. Informative References		12.2. Informative References
	[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-02 (work in progress), October 2016.		dispatch-05 (work in progress), October 2016.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", RFC 4443,		Protocol Version 6 (IPv6) Specification", RFC 4443,
	DOI 10.17487/RFC4443, March 2006,		DOI 10.17487/RFC4443, March 2006,
	<http://www.rfc-editor.org/info/rfc4443>.		<http://www.rfc-editor.org/info/rfc4443>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
End of changes. 91 change blocks.
	336 lines changed or deleted		485 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/