< draft-ietf-roll-useofrplinfo-38.txt		draft-ietf-roll-useofrplinfo-39.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft UTN-FRM/Aalto		Internet-Draft UTN-FRM/Aalto
	Updates: 6553, 6550, 8138 (if approved) M. Richardson		Updates: 6553, 6550, 8138 (if approved) M. Richardson
	Intended status: Standards Track SSW		Intended status: Standards Track SSW
	Expires: September 24, 2020 P. Thubert		Expires: December 10, 2020 P. Thubert
	Cisco		Cisco
	March 23, 2020		June 8, 2020
	Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6		Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6
	encapsulation in the RPL Data Plane		encapsulation in the RPL Data Plane
	draft-ietf-roll-useofrplinfo-38		draft-ietf-roll-useofrplinfo-39
	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 RFC6553 (RPI Option Type), RFC6554		enumerates the cases where RFC6553 (RPI Option Type), RFC6554
	(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is		(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
	required in data plane. This analysis provides the basis on which to		required in data plane. This analysis provides the basis on which to
	design efficient compression of these headers. This document updates		design efficient compression of these headers. This document updates
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 24, 2020.		This Internet-Draft will expire on December 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 27		7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 27
	7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 28		7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 28
	7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 29		7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 29
	7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 30		7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 30
	7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 30		7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 30
	7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 31		7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 31
	7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 33		7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 33
	7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 34		7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 34
	8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 35		8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 35
	8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 37		8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 37
	8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 38		8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 37
	8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 39		8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 38
	8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 39		8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 39
	8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 40		8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 40
	8.2. Non-Storing Mode: Interaction between Leaf and Internet . 41		8.2. Non-Storing Mode: Interaction between Leaf and Internet . 41
	8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 42		8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 41
	8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 43		8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 43
	8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 44		8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 44
	8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45		8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45
	8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46		8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46
	8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46		8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46
	8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49		8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49
	8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51		8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51
	8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52		8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52
	9. Operational Considerations of supporting		9. Operational Considerations of supporting
	RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53		RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	forward and route IPv6 packets. 6LoWPAN routers are present only in		forward and route IPv6 packets. 6LoWPAN routers are present only in
	route-over topologies."		route-over topologies."
	6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border		6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border
	router located at the junction of separate 6LoWPAN networks or		router located at the junction of separate 6LoWPAN networks or
	between a 6LoWPAN network and another IP network. There may be one		between a 6LoWPAN network and another IP network. There may be one
	or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the		or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the
	responsible authority for IPv6 prefix propagation for the 6LoWPAN		responsible authority for IPv6 prefix propagation for the 6LoWPAN
	network it is serving. An isolated LoWPAN also contains a 6LBR in		network it is serving. An isolated LoWPAN also contains a 6LBR in
	the network, which provides the prefix(es) for the isolated network."		the network, which provides the prefix(es) for the isolated network."
	Flag Day: A transition that involves having a network with different		Flag Day: In this document, refers to a transition that involves
	values of RPI Option Type. Thus the network does not work correctly		having a network with different values of RPI Option Type.
	(Lack of interoperation).
	Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL-		Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL-
	aware-nodes send information to the root about their parents. Thus,		aware-nodes send information to the root about their parents. Thus,
	the root knows the topology. Because the root knows the topology,		the root knows the topology. Because the root knows the topology,
	the intermediate 6LRs do not maintain routing state and source		the intermediate 6LRs do not maintain routing state and source
	routing is needed.		routing is needed.
	Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes		Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes
	(6LRs) maintain routing state (of the children) so that source		(6LRs) maintain routing state (of the children) so that source
	routing is not needed.		routing is not needed.
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	direction, for traffic coming from an external target into the LLN,		direction, for traffic coming from an external target into the LLN,
	the parent (6LR) that injects the traffic always encapsulates to the		the parent (6LR) that injects the traffic always encapsulates to the
	root. This whole operation is transparent to intermediate routers		root. This whole operation is transparent to intermediate routers
	that only see traffic between the 6LR and the Root, and only the Root		that only see traffic between the 6LR and the Root, and only the Root
	and the 6LRs that inject external routes in the network need to be		and the 6LRs that inject external routes in the network need to be
	upgraded to add this function to the network.		upgraded to add this function to the network.
	A RUL is a special case of external target when the target is		A RUL is a special case of external target when the target is
	actually a host and it is known to support a consumed Routing Header		actually a host and it is known to support a consumed Routing Header
	and to ignore a HbH header as prescribed by [RFC8200]. The target		and to ignore a HbH header as prescribed by [RFC8200]. The target
	may have been learned through as a host route or may have been		may have been learned through an external routing protocol or may
	registered to the 6LR using [RFC8505].		have been registered to the 6LR using [RFC8505].
	In order to enable IP-in-IP all the way to a 6LN, it is beneficial		In order to enable IP-in-IP all the way to a 6LN, it is beneficial
	that the 6LN supports decapsulating IP-in-IP, but that is not assumed		that the 6LN supports decapsulating IP-in-IP, but that is not assumed
	by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a		by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a
	packet SHOULD terminate the tunnel at a parent 6LR unless it is aware		packet SHOULD terminate the tunnel at a parent 6LR unless it is aware
	that the RUL supports IP-in-IP decapsulation.		that the RUL supports IP-in-IP decapsulation.
	A node that is reachable over an external route is not expected to		A node that is reachable over an external route is not expected to
	support [RFC8138]. Whether a decapsulation took place or not and		support [RFC8138]. Whether a decapsulation took place or not and
	even when the 6LR is delivering the packet to a RUL, the 6LR that		even when the 6LR is delivering the packet to a RUL, the 6LR that
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 20 ¶
	bit is equal to '1'. The first two bits indicate that the IPv6 node		bit is equal to '1'. The first two bits indicate that the IPv6 node
	MUST skip over this option and continue processing the header		MUST skip over this option and continue processing the header
	([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and		([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and
	the third bit continues to be set to indicate that the Option Data		the third bit continues to be set to indicate that the Option Data
	may change en route. The rightmost five bits remain at 0x3(00011).		may change en route. The rightmost five bits remain at 0x3(00011).
	This ensures that a packet that leaves the RPL domain of an LLN (or		This ensures that a packet that leaves the RPL domain of an LLN (or
	that leaves the LLN entirely) will not be discarded when it contains		that leaves the LLN entirely) will not be discarded when it contains
	the RPL Option.		the RPL Option.
	With the new Option Type, if an IPv6 (intermediate) node (RPL-not-		With the new Option Type, if an IPv6 (intermediate) node (RPL-not-
	capable) receives a packet with an RPL Option, it should ignore the		capable) receives a packet with a RPL Option, it should ignore the
	Hop-by-Hop RPL Option (skip over this option and continue processing		Hop-by-Hop RPL Option (skip over this option and continue processing
	the header). This is relevant, as it was mentioned previously, in		the header). This is relevant, as it was mentioned previously, in
	the case that there is a flow from RAL to Internet (see		the case that there is a flow from RAL to Internet (see
	Section 7.2.1).		Section 7.2.1).
	This is a significant update to [RFC6553].		This is a significant update to [RFC6553].
	+-------+-------------------+-------------+------------+		+-------+-------------------+-------------+------------+
	| Hex | Binary Value | Description | Reference |		| Hex | Binary Value | Description | Reference |
	+ Value +-------------------+ + +		+ Value +-------------------+ + +
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 24 ¶
	node. The 6LN is a RPL aware router, or host (as a leaf).		node. The 6LN is a RPL aware router, or host (as a leaf).
	Additionally, for simplification purposes, it is supposed that the		Additionally, for simplification purposes, it is supposed that the
	6LBR has direct access to Internet and is the root of the DODAG, thus		6LBR has direct access to Internet and is the root of the DODAG, thus
	the 6BBR is not present in the figure.		the 6BBR is not present in the figure.
	The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no		The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no
	children hosts.		children hosts.
	The leaves marked as RUL (G and J) are devices which do not speak RPL		The leaves marked as RUL (G and J) are devices which do not speak RPL
	at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/		at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/
	DAC and efficient-ND only to participate in the network [RFC6775].		DAC and 6LoWPAN ND only to participate in the network [RFC8505]. In
	In the document these leaves (G and J) are also referred to as an		the document these leaves (G and J) are also referred to as a RUL.
	IPv6 node.
	The 6LBR ("A") in the figure is the root of the Global DODAG.		The 6LBR ("A") in the figure is the root of the Global DODAG.
	+------------+		+------------+
	| INTERNET ----------+		| INTERNET ----------+
	| | |		| | |
	+------------+ |		+------------+ |
	|		|
	|		|
	|		|
	skipping to change at page 17, line 22 ¶		skipping to change at page 17, line 22 ¶
	DODAG root MUST force it to zero when passing the packet out to the		DODAG root MUST force it to zero when passing the packet out to the
	Internet. The Internet will therefore not see any SenderRank		Internet. The Internet will therefore not see any SenderRank
	information.		information.
	Despite being legal to leave the RPI artifact in place, an		Despite being legal to leave the RPI artifact in place, an
	intermediate router that needs to add an extension header (e.g. RH3		intermediate router that needs to add an extension header (e.g. RH3
	or RPL Option) MUST still encapsulate the packet in an (additional)		or RPL Option) MUST still encapsulate the packet in an (additional)
	outer IP header. The new header is placed after this new outer IP		outer IP header. The new header is placed after this new outer IP
	header.		header.
	A corollary is that an RH3 or RPL Option can only be removed by an		A corollary is that an intermediate router can remove an RH3 or RPL
	intermediate router if it is placed in an encapsulating IPv6 Header,		Option only if it is placed in an encapsulating IPv6 Header that is
	which is addressed TO the intermediate router. When it does so, the		addressed TO this intermediate router. When doing the above, the
	whole encapsulating header must be removed. (A replacement may be		whole encapsulating header must be removed. (A replacement may be
	added). This sometimes can result in outer IP headers being		added). This sometimes can result in outer IP headers being
	addressed to the next hop router using link-local address.		addressed to the next hop router using link-local address.
	Both the RPL Option and the RH3 headers may be modified in very		Both the RPL Option and the RH3 headers may be modified in very
	specific ways by routers on the path of the packet without the need		specific ways by routers on the path of the packet without the need
	to add and remove an encapsulating header. Both headers were		to add and remove an encapsulating header. Both headers were
	designed with this modification in mind, and both the RPL RH3 and the		designed with this modification in mind, and both the RPL RH3 and the
	RPL Option are marked mutable but recoverable: so an IPsec AH		RPL Option are marked mutable but recoverable: so an IPsec AH
	security header can be applied across these headers, but it can not		security header can be applied across these headers, but it can not
	skipping to change at page 17, line 47 ¶		skipping to change at page 17, line 47 ¶
	The RPI MUST be present in every single RPL data packet.		The RPI MUST be present in every single RPL data packet.
	Prior to [RFC8138], there was significant interest in creating an		Prior to [RFC8138], there was significant interest in creating an
	exception to this rule and removing the RPI for downward flows in		exception to this rule and removing the RPI for downward flows in
	non-storing mode. This exception covered a very small number of		non-storing mode. This exception covered a very small number of
	cases, and caused significant interoperability challenges while		cases, and caused significant interoperability challenges while
	adding significant in the code and tests. The ability to compress		adding significant in the code and tests. The ability to compress
	the RPI down to three bytes or less removes much of the pressure to		the RPI down to three bytes or less removes much of the pressure to
	optimize this any further [I-D.ietf-anima-autonomic-control-plane].		optimize this any further [I-D.ietf-anima-autonomic-control-plane].
	The earlier examples are more extensive to make sure that the process		Throughout the following subsections, the examples are described in
	is clear, while later examples are more concise.		more details in the first subsections, and more concisely in the
			later ones.
	The uses cases are delineated based on the following requirements:		The uses cases are delineated based on the following IPV6 and RPL
			mandates:
	The RPI has to be in every packet that traverses the LLN.		The RPI has to be in every packet that traverses the LLN.
	- Because of the above requirement, packets from the Internet have		- Because of the above requirement, packets from the Internet have
	to be encapsulated.		to be encapsulated.
	- A Header cannot be inserted or removed on the fly inside an IPv6		- A Header cannot be inserted or removed on the fly inside an IPv6
	packet that is being routed.		packet that is being routed.
	- Extension headers may not be added or removed except by the		- Extension headers may not be added or removed except by the
	skipping to change at page 19, line 18 ¶		skipping to change at page 19, line 20 ¶
	the destination is inside the LLN by looking if the destination		the destination is inside the LLN by looking if the destination
	address is matched by the DIO's Prefix Information Option (PIO)		address is matched by the DIO's Prefix Information Option (PIO)
	option.		option.
	The following table (Figure 7) itemizes which headers are needed in		The following table (Figure 7) itemizes which headers are needed in
	each of the following scenarios. It indicates whether an IPv6-in-		each of the following scenarios. It indicates whether an IPv6-in-
	IPv6 header must be added and what destination it must be addressed		IPv6 header must be added and what destination it must be addressed
	to: (1) the final destination (the RAL node that is the target		to: (1) the final destination (the RAL node that is the target
	(tgt)), (2) the "root", or (3) the 6LR parent of a RUL.		(tgt)), (2) the "root", or (3) the 6LR parent of a RUL.
	In cases where no IPv6-in-IPv6 header is needed, the column states as		In cases where no IPv6-in-IPv6 header is needed, the column states
	"No". If the IPv6-in-IPv6 header is needed, the column shows "must".		"No", and the destination is N/A (Not Applicable). If the IPv6-in-
			IPv6 header is needed, the column shows "must".
	In all cases, the RPI is needed, since it identifies inconsistencies		In all cases, the RPI is needed, since it identifies inconsistencies
	(loops) in the routing topology. In general, the RH3 is not needed		(loops) in the routing topology. In general, the RH3 is not needed
	because it is not used in storing mode. However, there is one		because it is not used in storing mode. However, there is one
	scenario (from the root to the RUL in SM) where the RH3 can be used		scenario (from the root to the RUL in SM) where the RH3 can be used
	to indicate the RUL (Figure 11).		to point at the RUL (Figure 11).
	The leaf can be a router 6LR or a host, both indicated as 6LN. The		The leaf can be a router 6LR or a host, both indicated as 6LN. The
	root refers to the 6LBR (see Figure 6).		root refers to the 6LBR (see Figure 6).
	+---------------------+--------------+------------+----------------+		+---------------------+--------------+------------+----------------+
	| Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst|		| Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst|
	+---------------------+--------------+------------+----------------+		+---------------------+--------------+------------+----------------+
	| | RAL to root | No | No |		| | RAL to root | No | N/A |
	+ +--------------+------------+----------------+		+ +--------------+------------+----------------+
	| Leaf - Root | root to RAL | No | No |		| Leaf - Root | root to RAL | No | N/A |
	+ +--------------+------------+----------------+		+ +--------------+------------+----------------+
	| | root to RUL | must | 6LR |		| | root to RUL | must | 6LR |
	+ +--------------+------------+----------------+		+ +--------------+------------+----------------+
	| | RUL to root | must | root |		| | RUL to root | must | root |
	+---------------------+--------------+------------+----------------+		+---------------------+--------------+------------+----------------+
	| | RAL to Int | may | root |		| | RAL to Int | may | root |
	+ +--------------+------------+----------------+		+ +--------------+------------+----------------+
	| Leaf - Internet | Int to RAL | must | RAL (tgt) |		| Leaf - Internet | Int to RAL | must | RAL (tgt) |
	+ +--------------+------------+----------------+		+ +--------------+------------+----------------+
	| | RUL to Int | must | root |		| | RUL to Int | must | root |
	+ +--------------+------------+----------------+		+ +--------------+------------+----------------+
	| | Int to RUL | must | 6LR |		| | Int to RUL | must | 6LR |
	+---------------------+--------------+------------+----------------+		+---------------------+--------------+------------+----------------+
	| | RAL to RAL | No | No |		| | RAL to RAL | No | N/A |
	| Leaf - Leaf +--------------+------------+----------------+		| Leaf - Leaf +--------------+------------+----------------+
	| | RAL to RUL | No(up) | 6LR |		| | RAL to RUL | No(up) | N/A |
	| + +------------+----------------+		| + +------------+----------------+
	| | | must(down) | 6LR |		| | | must(down) | 6LR |
	| +--------------+------------+----------------+		| +--------------+------------+----------------+
	| | RUL to RAL | must(up) | root |		| | RUL to RAL | must(up) | root |
	| | +------------+----------------+		| | +------------+----------------+
	| | | must(down) | RAL |		| | | must(down) | RAL |
	| +--------------+------------+----------------+		| +--------------+------------+----------------+
	| | RUL to RUL | must(up) | root |		| | RUL to RUL | must(up) | root |
	| | +------------+----------------+		| | +------------+----------------+
	| | | must(down) | 6LR |		| | | must(down) | 6LR |
	skipping to change at page 23, line 7 ¶		skipping to change at page 23, line 7 ¶
	root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)		root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
	For example, a communication flow could be: Node A (6LBR) --> Node B		For example, a communication flow could be: Node A (6LBR) --> Node B
	(6LR_i) --> Node E (6LR_n) --> Node G (RUL)		(6LR_i) --> Node E (6LR_n) --> Node G (RUL)
	6LR_i (Node B) represents the intermediate routers from the source		6LR_i (Node B) represents the intermediate routers from the source
	(6LBR) to the destination (RUL), 1 <= i <= n, where n is the total		(6LBR) to the destination (RUL), 1 <= i <= n, where n is the total
	number of routers (6LR) that the packet goes through from the 6LBR		number of routers (6LR) that the packet goes through from the 6LBR
	(Node A) to the RUL (Node G).		(Node A) to the RUL (Node G).
	The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header.		The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and
	The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL		prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR
	(6LR_n). The 6LR parent of the RUL removes the header and sends the		parent of the RUL (6LR_n). The 6LR parent of the RUL removes the
	packet to the RUL.		header and sends the packet to the RUL.
	The Figure 10 summarizes what headers are needed for this use case.		The Figure 10 summarizes what headers are needed for this use case.
	+-----------+---------+---------+---------+-----+		+-----------+---------+---------+---------+-----+
	| Header | 6LBR | 6LR_i | 6LR_n | RUL |		| Header | 6LBR | 6LR_i | 6LR_n | RUL |
	| | src | | | dst |		| | src | | | dst |
	+-----------+---------+---------+---------+-----+		+-----------+---------+---------+---------+-----+
	| Added | IP6-IP6 | -- | -- | -- |		| Added | IP6-IP6 | -- | -- | -- |
	| headers | (RPI) | | | |		| headers | RPI | | | |
	+-----------+---------+---------+---------+-----+		+-----------+---------+---------+---------+-----+
	| Modified | -- | | -- | -- |		| Modified | -- | | -- | -- |
	| headers | | RPI | | |		| headers | | RPI | | |
	+-----------+---------+---------+---------+-----+		+-----------+---------+---------+---------+-----+
	| Removed | -- | -- | IP6-IP6 | -- |		| Removed | -- | -- | IP6-IP6 | -- |
	| headers | | | (RPI) | |		| headers | | | RPI | |
	+-----------+---------+---------+---------+-----+		+-----------+---------+---------+---------+-----+
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | IP6-IP6 | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+---------+---------+---------+-----+		+-----------+---------+---------+---------+-----+
	Figure 10: SM: Summary of the use of headers from root to RUL		Figure 10: SM: Summary of the use of headers from root to RUL
	IP-in-IP encapsulation MAY be avoided for Root to RUL communication.		IP-in-IP encapsulation MAY be avoided for Root to RUL communication.
	In SM, it can be replaced by a loose SRH header that indicates the		In SM, it can be replaced by a loose RH3 header that indicates the
	RUL, in which case the packet is routed to the 6LR as a normal SM		RUL, in which case the packet is routed to the 6LR as a normal SM
	operation, then the 6LR forwards to the RUL based on the SRH, and the		operation, then the 6LR forwards to the RUL based on the RH3, and the
	RUL ignores both the consumed SRH and the RPI, as in Non-Storing		RUL ignores both the consumed RH3 and the RPI, as in Non-Storing
	Mode.		Mode.
	The Figure 11 summarizes what headers are needed for this scenario.		The Figure 11 summarizes what headers are needed for this scenario.
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	| Header | 6LBR | 6LR_i | 6LR_n | RUL |		| Header | 6LBR | 6LR_i | 6LR_n | RUL |
	| | src | i=(1,..,n-1) | | dst |		| | src | i=(1,..,n-1) | | dst |
	| | | | | |		| | | | | |
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	| Added | RPI, RH3 | -- | -- | -- |		| Added | RPI, RH3 | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	| Modified | -- | RPI | RPI | -- |		| Modified | -- | RPI | RPI | -- |
	| headers | | | RH3(consumed) | |		| headers | | | RH3(consumed) | |
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	| Removed | -- | -- | -- | -- |		| Removed | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	| Untouched | -- | -- | -- | RPI, RH3 |		| Untouched | -- | RH3 | -- | RPI, RH3 |
	| headers | | | | (both |		| headers | | | | (both |
	| | | | | ignored) |		| | | | | ignored) |
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	Figure 11: SM: Summary of the use of headers from root to RUL without		Figure 11: SM: Summary of the use of headers from root to RUL without
	encapsulation		encapsulation
	7.1.4. SM: Example of Flow from RUL to Root		7.1.4. SM: Example of Flow from RUL to Root
	In this case the flow comprises:		In this case the flow comprises:
	RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR)		RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR)
	For example, a communication flow could be: Node G (RUL) --> Node E		For example, a communication flow could be: Node G (RUL) --> Node E
	(6LR_1)--> Node B (6LR_i)--> Node A root(6LBR)		(6LR_1)--> Node B (6LR_i)--> Node A root(6LBR)
	6LR_i represents the intermediate routers from the source (RUL) to		6LR_i represents the intermediate routers from the source (RUL) to
	the destination (6LBR), 1 <= i <= n, where n is the total number of		the destination (6LBR), 1 <= i <= n, where n is the total number of
	routers (6LR) that the packet goes through from the RUL to the 6LBR.		routers (6LR) that the packet goes through from the RUL to the 6LBR.
	When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),		When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the
	the 6LR_1 will insert an RPI, encapsulated in a IPv6-in-IPv6 header.		6LR_1 will insert encapsulate the packet in an IPv6-in-IPv6 header
	The IPv6-in-IPv6 header is addressed to the root (Node A). The root		and prepend an RPI. The IPv6-in-IPv6 header is addressed to the root
	removes the header and processes the packet.		(Node A). The root removes the header and processes the packet.
	The Figure 12 shows the table that summarizes what headers are needed		The Figure 12 shows the table that summarizes what headers are needed
	for this use case where the IPv6-in-IPv6 header is addressed to the		for this use case where the IPv6-in-IPv6 header is addressed to the
	root (Node A).		root (Node A).
	+-----------+------+--------------+----------------+-----------------+		+-----------+------+--------------+----------------+-----------------+
	| Header | RUL | 6LR_1 | 6LR_i | 6LBR dst |		| Header | RUL | 6LR_1 | 6LR_i | 6LBR dst |
	| | src | | | |		| | src | | | |
	| | node | | | |		| | node | | | |
	+-----------+------+--------------+----------------+-----------------+		+-----------+------+--------------+----------------+-----------------+
	| Added | -- | IP6-IP6(RPI) | | -- |		| Added | -- | IP6-IP6 | | -- |
	| headers | | | -- | |		| headers | | RPI | -- | |
	+-----------+------+--------------+----------------+-----------------+		+-----------+------+--------------+----------------+-----------------+
	| Modified | -- | -- | RPI | -- |		| Modified | -- | -- | RPI | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+----------------+-----------------+		+-----------+------+--------------+----------------+-----------------+
	| Removed | -- | -- | --- | IP6-IP6(RPI) |		| Removed | -- | -- | --- | IP6-IP6 |
	| headers | | | | |		| headers | | | | RPI |
	+-----------+------+--------------+----------------+-----------------+		+-----------+------+--------------+----------------+-----------------+
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | -- | IP6-IP6 | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+----------------+-----------------+		+-----------+------+--------------+----------------+-----------------+
	Figure 12: SM: Summary of the use of headers from RUL to root.		Figure 12: SM: Summary of the use of headers from RUL to root.
	7.2. SM: Interaction between Leaf and Internet.		7.2. SM: Interaction between Leaf and Internet.
	In this section is described the communication flow in storing mode		In this section is described the communication flow in storing mode
	(SM) between,		(SM) between,
	skipping to change at page 26, line 13 ¶		skipping to change at page 26, line 13 ¶
	(6LR) that the packet goes through from the RAL to the 6LBR.		(6LR) that the packet goes through from the RAL to the 6LBR.
	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. No		ignored by nodes which have not been configured to be RPI aware. No
	IPv6-in-IPv6 header is required.		IPv6-in-IPv6 header is required.
	On the other hand, the RAL may insert the RPI encapsulated in a IPv6-		On the other hand, the RAL may insert the RPI encapsulated in a IPv6-
	in-IPv6 header to the root. Thus, the root removes the RPI and send		in-IPv6 header to the root. Thus, the root removes the RPI and send
	the packet to the Internet.		the packet to the Internet.
	No IPv6-in-IPv6 header is required.
	Note: In this use case, it is used a node as a leaf, but this use		Note: In this use case, it is used a node as a leaf, but this use
	case can be also applicable to any RPL-aware-node type (e.g. 6LR)		case can be also applicable to any RPL-aware-node type (e.g. 6LR)
	The Figure 13 summarizes what headers are needed for this use case		The Figure 13 summarizes what headers are needed for this use case
	when there is no encapsulation. The Figure 14 summarizes what		when there is no encapsulation. Note that the RPI is modified by
	headers are needed when encapsulation to the root takes place.		6LBR to set the SenderRank to zero in case that it is not already
			zero. The Figure 14 summarizes what headers are needed when
			encapsulation to the root takes place.
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Header | RAL | 6LR_i | 6LBR | Internet |		| Header | RAL | 6LR_i | 6LBR | Internet |
	| | src | | | dst |		| | src | | | dst |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Added | RPI | -- | -- | -- |		| Added | RPI | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Modified | -- | RPI | -- | -- |		| Modified | -- | RPI | RPI | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Removed | -- | -- | -- | -- |		| Removed | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Untouched | -- | -- | RPI | RPI |		| Untouched | -- | -- | -- | RPI |
	| headers | | | | (Ignored) |		| headers | | | | (Ignored) |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	Figure 13: SM: Summary of the use of headers from RAL to Internet		Figure 13: SM: Summary of the use of headers from RAL to Internet
	with no encapsulation		with no encapsulation
	+-----------+----------+--------------+--------------+--------------+		+-----------+----------+--------------+--------------+--------------+
	| Header | RAL | 6LR_i | 6LBR | Internet dst |		| Header | RAL | 6LR_i | 6LBR | Internet dst |
	| | src | | | |		| | src | | | |
	+-----------+----------+--------------+--------------+--------------+		+-----------+----------+--------------+--------------+--------------+
	| Added |IP6-IP6 | -- | -- | -- |		| Added | IP6-IP6 | -- | -- | -- |
	| headers | (RPI) | | | |		| headers | RPI | | | |
	+-----------+----------+--------------+--------------+--------------+		+-----------+----------+--------------+--------------+--------------+
	| Modified | -- | RPI | -- | -- |		| Modified | -- | RPI | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+--------------+		+-----------+----------+--------------+--------------+--------------+
	| Removed | -- | -- |IP6-IP6(RPI) | -- |		| Removed | -- | -- | IP6-IP6 | -- |
	| headers | | | | |		| headers | | | RPI | |
	+-----------+----------+--------------+--------------+--------------+		+-----------+----------+--------------+--------------+--------------+
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | IP6-IP6 | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+--------------+		+-----------+----------+--------------+--------------+--------------+
	Figure 14: SM: Summary of the use of headers from RAL to Internet		Figure 14: SM: Summary of the use of headers from RAL to Internet
	with encapsulation to the root (6LBR).		with encapsulation to the root (6LBR).
	7.2.2. SM: Example of Flow from Internet to RAL		7.2.2. SM: Example of Flow from Internet to RAL
	In this case the flow comprises:		In this case the flow comprises:
	skipping to change at page 32, line 9 ¶		skipping to change at page 32, line 9 ¶
	Figure 18: SM: Summary of the Use of Headers from RAL to RAL		Figure 18: SM: Summary of the Use of Headers from RAL to RAL
	7.3.2. SM: Example of Flow from RAL to RUL		7.3.2. SM: Example of Flow from RAL to RUL
	In this case the flow comprises:		In this case the flow comprises:
	RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) -->		RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) -->
	6LR_id --> RUL (IPv6 dst node)		6LR_id --> RUL (IPv6 dst node)
	For example, a communication flow could be: Node F (RAL)--> Node D		For example, a communication flow could be: Node F (RAL)--> Node D
	--> Node B --> Node E --> Node G (RUL)		--> Node B--> Node A -->Node B --> Node E --> Node G (RUL)
	6LR_ia represents the intermediate routers from source (RAL) to the		6LR_ia represents the intermediate routers from source (RAL) to the
	common parent (the Root), 1 <= ia <= n, where n is the total number		common parent (the Root), 1 <= ia <= n, where n is the total number
	of routers (6LR) that the packet goes through from RAL to the Root.		of routers (6LR) that the packet goes through from RAL to the Root.
	6LR_id (Node E) represents the intermediate routers from the Root		6LR_id (Node E) represents the intermediate routers from the Root
	(Node B) to destination RUL (Node G). In this case, 1 <= id <= m,		(Node B) to destination RUL (Node G). In this case, 1 <= id <= m,
	where m is the total number of routers (6LR) that the packet goes		where m is the total number of routers (6LR) that the packet goes
	through from the Root down to the destination RUL.		through from the Root down to the destination RUL.
	In this case, the packet from the RAL goes to 6LBR because the route		In this case, the packet from the RAL goes to 6LBR because the route
	to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an		to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an
	RPI (RPI1) addressed to the root(6LBR). The root removes the RPI1		RPI (RPI1) addressed to the root(6LBR). The root does not removes
	and inserts an RPI2 encapsulated to the 6LR parent of the RUL, which		the RPI1 (the root cannot remove an RPI if there is no
	removes the RPI2 before pasing the packet to the RUL.		encapsulation). The root inserts an RPI2 encapsulated to the 6LR
			parent of the RUL, which removes the RPI2 before pasing the packet to
			the RUL.
	The Figure 19 summarizes what headers are needed for this use case.		The Figure 19 summarizes what headers are needed for this use case.
	+----------+-------+-------+---------+---------+---------+---------+		+----------+-------+-------+---------+---------+---------+---------+
	| Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |		| Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
	| | src | | | | | dst |		| | src | | | | | dst |
	| | node | | | | | node |		| | node | | | | | node |
	+----------+-------+-------+---------+---------+---------+---------+		+----------+-------+-------+---------+---------+---------+---------+
	| Added | | | IP6-IP6 | -- | -- | -- |		| Added | | | IP6-IP6 | -- | -- | -- |
	| headers | RPI1 | -- | (RPI2) | | | |		| headers | RPI1 | -- | (RPI2) | | | |
	skipping to change at page 34, line 49 ¶		skipping to change at page 34, line 49 ¶
	router from the RUL source (Node G) to the root (6LBR) (Node A). In		router from the RUL source (Node G) to the root (6LBR) (Node A). In
	this case, 1 <= ia <= n, where n is the total number of routers (6LR)		this case, 1 <= ia <= n, where n is the total number of routers (6LR)
	that the packet goes through from the RUL to the root. 6LR_1 refers		that the packet goes through from the RUL to the root. 6LR_1 refers
	when ia=1.		when ia=1.
	6LR_id (Node C) represents the intermediate routers from the root		6LR_id (Node C) represents the intermediate routers from the root
	(Node A) to the destination RUL dst node (Node J). In this case, 1		(Node A) to the destination RUL dst node (Node J). In this case, 1
	<= id <= m, where m is the total number of routers (6LR) that the		<= id <= m, where m is the total number of routers (6LR) that the
	packet goes through from the root to destination RUL.		packet goes through from the root to destination RUL.
	The RPI is ignored at the RUL dst node.
	The 6LR_1 (Node E) receives the packet from the RUL (Node G) and		The 6LR_1 (Node E) receives the packet from the RUL (Node G) and
	inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header		inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header
	directed to the root. The root removes the outer header including		directed to the root. The root removes the outer header including
	the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR		the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR
	father of the RUL.		father of the RUL.
	The Figure 21 shows the table that summarizes what headers are needed		The Figure 21 shows the table that summarizes what headers are needed
	for this use case.		for this use case.
	+---------+----+-------------+--------+---------+--------+-------+---+		+---------+----+-------------+--------+---------+--------+-------+---+
	skipping to change at page 40, line 4 ¶		skipping to change at page 39, line 32 ¶
	Figure 24: Non-SM: Summary of the use of headers from root to RAL		Figure 24: Non-SM: Summary of the use of headers from root to RAL
	8.1.3. Non-SM: Example of Flow from root to RUL		8.1.3. Non-SM: Example of Flow from root to RUL
	In this case the flow comprises:		In this case the flow comprises:
	root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)		root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
	For example, a communication flow could be: Node A (root) --> Node B		For example, a communication flow could be: Node A (root) --> Node B
	--> Node E --> Node G (RUL)		--> Node E --> Node G (RUL)
	6LR_i represents the intermediate routers from source to destination.		6LR_i represents the intermediate routers from source to destination.
	In this case, 1 <= i <= n, where n is the total number of routers		In this case, 1 <= i <= n, where n is the total number of routers
	(6LR) that the packet goes through from source (6LBR) to destination		(6LR) that the packet goes through from source (6LBR) to destination
	(RUL).		(RUL).
	In the 6LBR, the RH3 is added; it is then modified at each		In the 6LBR, the RH3 is added; it is then modified at each
	intermediate 6LR (6LR_1 and so on), and it is fully consumed in the		intermediate 6LR (6LR_1 and so on), and it is fully consumed in the
	last 6LR (6LR_n) but is left in place. When the RPI is added, the		last 6LR (6LR_n) but is left in place. When the RPI is added, the
	IPv6 node, which does not understand the RPI, will ignore it (per		RUL, which does not understand the RPI, will ignore it (per
	[RFC8200]); thus, encapsulation is not necessary.		[RFC8200]); thus, encapsulation is not necessary.
	The Figure 25 depicts the table that summarizes what headers are		The Figure 25 depicts the table that summarizes what headers are
	needed for this use case.		needed for this use case.
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	| Header | 6LBR | 6LR_i | 6LR_n | RUL |		| Header | 6LBR | 6LR_i | 6LR_n | RUL |
	| | src | i=(1,..,n-1) | | dst |		| | src | i=(1,..,n-1) | | dst |
	| | | | | |		| | | | | |
	+-----------+----------+--------------+----------------+----------+		+-----------+----------+--------------+----------------+----------+
	skipping to change at page 41, line 5 ¶		skipping to change at page 40, line 39 ¶
	RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst		RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst
	For example, a communication flow could be: Node G --> Node E -->		For example, a communication flow could be: Node G --> Node E -->
	Node B --> Node A (root)		Node B --> Node A (root)
	6LR_i represents the intermediate routers from source to destination.		6LR_i represents the intermediate routers from source to destination.
	In this case, 1 <= i <= n, where n is the total number of routers		In this case, 1 <= i <= n, where n is the total number of routers
	(6LR) that the packet goes through from source (RUL) to destination		(6LR) that the packet goes through from source (RUL) to destination
	(6LBR). For example, 6LR_1 (i=1) is the router that receives the		(6LBR). For example, 6LR_1 (i=1) is the router that receives the
	packets from the IPv6 node.		packets from the RUL.
	In this case, the RPI is added by the first 6LR (6LR_1) (Node E),		In this case, the RPI is added by the first 6LR (6LR_1) (Node E),
	encapsulated in an IPv6-in-IPv6 header, and modified in the		encapsulated in an IPv6-in-IPv6 header, and modified in the
	subsequent 6LRs in the flow. The RPI and the entire packet are		subsequent 6LRs in the flow. The RPI and the entire packet are
	consumed by the root.		consumed by the root.
	The Figure 26 shows the table that summarizes what headers are needed		The Figure 26 shows the table that summarizes what headers are needed
	for this use case.		for this use case.
	+---------+----+-----------------+-----------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	skipping to change at page 42, line 37 ¶		skipping to change at page 42, line 24 ¶
	when no encapsulation is used. The Figure 28 summarizes what headers		when no encapsulation is used. The Figure 28 summarizes what headers
	are needed for this use case when encapsulation to the root is used.		are needed for this use case when encapsulation to the root is used.
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Header | RAL | 6LR_i | 6LBR | Internet |		| Header | RAL | 6LR_i | 6LBR | Internet |
	| | src | | | dst |		| | src | | | dst |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Added | RPI | -- | -- | -- |		| Added | RPI | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Modified | -- | RPI | -- | -- |		| Modified | -- | RPI | RPI | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Removed | -- | -- | -- | -- |		| Removed | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	| Untouched | -- | -- | RPI | RPI |		| Untouched | -- | -- | -- | RPI |
	| headers | | | | (Ignored) |		| headers | | | | (Ignored) |
	+-----------+-----+-------+------+-----------+		+-----------+-----+-------+------+-----------+
	Figure 27: Non-SM: Summary of the use of headers from RAL to Internet		Figure 27: Non-SM: Summary of the use of headers from RAL to Internet
	with no encapsulation		with no encapsulation
	+-----------+--------------+--------------+--------------+----------+		+-----------+--------------+--------------+--------------+----------+
	| Header | RAL | 6LR_i | 6LBR | Internet |		| Header | RAL | 6LR_i | 6LBR | Internet |
	| | src | | | dst |		| | src | | | dst |
	+-----------+--------------+--------------+--------------+----------+		+-----------+--------------+--------------+--------------+----------+
	skipping to change at page 44, line 34 ¶		skipping to change at page 44, line 34 ¶
	8.2.3. Non-SM: Example of Flow from RUL to Internet		8.2.3. Non-SM: Example of Flow from RUL to Internet
	In this case the flow comprises:		In this case the flow comprises:
	RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet		RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet
	dst		dst
	For example, a communication flow could be: Node G --> Node E -->		For example, a communication flow could be: Node G --> Node E -->
	Node B --> Node A --> Internet		Node B --> Node A --> Internet
	6LR_i are the intermediate routers from source to destination, 1 <= i		6LR_i represents the intermediate routers from source to destination,
	<= n, where n is the total number of routers (6LRs) that the packet		1 <= i <= n, where n is the total number of routers (6LRs) that the
	goes through from the source (RUL) to the 6LBR, e.g., 6LR_1 (i=1).		packet goes through from the source (RUL) to the 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 RUL. As
	node. As RPL headers are added in the IPv6 node packet, the first		RPL headers are added in the RUL packet, the first 6LR (6LR_1) will
	6LR (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The		add an RPI inside a new IPv6-in-IPv6 header. The IPv6-in-IPv6 header
	IPv6-in-IPv6 header will be addressed to the root. This case is		will be addressed to the root. This case is identical to the
	identical to the storing-mode case (see Section 7.2.3).		storing-mode case (see Section 7.2.3).
	The Figure 30 shows the table that summarizes what headers are needed		The Figure 30 shows the table that summarizes what headers are needed
	for this use case.		for this use case.
	+---------+----+-------------+--------------+--------------+--------+		+---------+----+-------------+--------------+--------------+--------+
	| Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet|		| Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet|
	| |src | | [i=2,..,n] | | dst |		| |src | | [i=2,..,n] | | dst |
	| |node| | | | |		| |node| | | | |
	+---------+----+-------------+--------------+--------------+--------+		+---------+----+-------------+--------------+--------------+--------+
	| Added | -- |IP6-IP6(RPI) | -- | -- | -- |		| Added | -- |IP6-IP6(RPI) | -- | -- | -- |
	skipping to change at page 47, line 19 ¶		skipping to change at page 47, line 19 ¶
	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 to the original packet, and send the packet		node will add an RPI to the original packet, and send the packet
	upwards.		upwards.
	The originating node may put the RPI (RPI1) into an IPv6-in-IPv6		The originating node may put the RPI (RPI1) into an IPv6-in-IPv6
	header addressed to the root, so that the 6LBR can remove that		header addressed to the root, so that the 6LBR can remove that
	header. If it does not, then the RPI1 is forwarded down from the		header. If it does not, then the RPI1 is forwarded down from the
	root in the inner header to no avail.		root in the inner header to no avail.
	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 IPv6-in-IPv6 header. It should be able to remove the		add an IPv6-in-IPv6 header. It removes the RPI(RPI1), as it was
	RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to		contained in an IPv6-in-IPv6 header addressed to it. Otherwise,
	it. Otherwise, there may be an RPI buried inside the inner IP		there may be an RPI buried inside the inner IP header, which should
	header, which should get ignored. The root inserts an RPI (RPI2)		get ignored. The root inserts an RPI (RPI2) alongside the RH3.
	alongside the RH3.
	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 8.1.2, with the originating node acting as 6LBR.		Section 8.1.2, with the originating node acting as 6LBR.
	The Figure 32 shows the table that summarizes what headers are needed		The Figure 32 shows the table that summarizes what headers are needed
	for this use case when encapsulation to the root takes place.		for this use case when encapsulation to the root takes place.
	The Figure 33 shows the table that summarizes what headers are needed		The Figure 33 shows the table that summarizes what headers are needed
	for this use case when there is no encapsulation to the root. Note		for this use case when there is no encapsulation to the root. Note
	that in the Modified headers row, going up in each 6LR_ia only the		that in the Modified headers row, going up in each 6LR_ia only the
	RPI1 is changed. Going down, in each 6LR_id the IPv6 header is		RPI1 is changed. Going down, in each 6LR_id the IPv6 header is
	swapped with the SRH so both are changed alongside with the RPI2.		swapped with the RH3 so both are changed alongside with the RPI2.
	+---------+-------+----------+------------+----------+------------+		+---------+-------+----------+------------+----------+------------+
	| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL |		| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL |
	| | src | | | | dst |		| | src | | | | dst |
	+---------+-------+----------+------------+----------+------------+		+---------+-------+----------+------------+----------+------------+
	| Added |IP6-IP6| | IP6-IP6 | -- | -- |		| Added |IP6-IP6| | IP6-IP6 | -- | -- |
	| headers |(RPI1) | -- |(RH3-> RAL, | | |		| headers |(RPI1) | -- |(RH3-> RAL, | | |
	| | | | RPI2) | | |		| | | | RPI2) | | |
	+---------+-------+----------+------------+----------+------------+		+---------+-------+----------+------------+----------+------------+
	| Modified| -- | | -- | IP6-IP6 | -- |		| Modified| -- | | -- | IP6-IP6 | -- |
	skipping to change at page 48, line 43 ¶		skipping to change at page 48, line 43 ¶
	+-----------+------+--------+---------+---------+---------+		+-----------+------+--------+---------+---------+---------+
	| Modified | -- | RPI1 | -- | IP6-IP6 | -- |		| Modified | -- | RPI1 | -- | IP6-IP6 | -- |
	| headers | | | | (RH3, | |		| headers | | | | (RH3, | |
	| | | | | RPI2) | |		| | | | | RPI2) | |
	+-----------+------+--------+---------+---------+---------+		+-----------+------+--------+---------+---------+---------+
	| Removed | -- | -- | -- | -- | IP6-IP6 |		| Removed | -- | -- | -- | -- | IP6-IP6 |
	| headers | | | | | (RH3, |		| headers | | | | | (RH3, |
	| | | | | | RPI2) |		| | | | | | RPI2) |
	| | | | | | |		| | | | | | |
	+-----------+------+--------+---------+---------+---------+		+-----------+------+--------+---------+---------+---------+
	| Untouched | -- | -- | RPI1 | RPI1 | RPI |		| Untouched | -- | -- | RPI1 | RPI1 | RPI1 |
	| headers | | | | |(Ignored)|		| headers | | | | |(Ignored)|
	+-----------+------+--------+---------+---------+---------+		+-----------+------+--------+---------+---------+---------+
	Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL		Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL
	without encapsulation to the root.		without encapsulation to the root.
	8.3.2. Non-SM: Example of Flow from RAL to RUL		8.3.2. Non-SM: Example of Flow from RAL to RUL
	In this case the flow comprises:		In this case the flow comprises:
	skipping to change at page 53, line 38 ¶		skipping to change at page 53, line 38 ¶
	The above case occurs whenever traffic originates from the outside		The above case occurs whenever traffic originates from the outside
	the LLN (the "Internet" cases above), and non-storing mode is used.		the LLN (the "Internet" cases above), and non-storing mode is used.
	In non-storing mode, the RPL root knows the exact topology (as it		In non-storing mode, the RPL root knows the exact topology (as it
	must create the RH3 header) and therefore knows which 6LR is prior to		must create the RH3 header) and therefore knows which 6LR is prior to
	the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf		the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf
	Node G, or Node C is the 6LR prior to leaf Node J.		Node G, or Node C is the 6LR prior to leaf Node J.
	traffic originating from the RPL root (such as when the data		traffic originating from the RPL root (such as when the data
	collection system is co-located on the RPL root), does not require an		collection system is co-located on the RPL root), does not require an
	IPv6-in-IPv6 header (in either mode), as the packet is originating at		IPv6-in-IPv6 header (in storing or non-storing mode), as the packet
	the root, and the root can insert the RPI and RH3 headers directly		is originating at the root, and the root can insert the RPI and RH3
	into the packet, as it is formed. Such a packet is slightly smaller,		headers directly into the packet, as it is formed. Such a packet is
	but only can be sent to nodes (whether RPL aware or not), that will		slightly smaller, but only can be sent to nodes (whether RPL aware or
	tolerate the RPL artifacts.		not), that will tolerate the RPL artifacts.
	An operator that finds itself with a lot of traffic from the RPL root		An operator that finds itself with a high amount of traffic from the
	to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation		RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6
	if the leaf is not tolerant of the RPL artifacts. Such an operator		encapsulation if the leaf is not tolerant of the RPL artifacts. Such
	could otherwise omit this unnecessary header if it was certain of the		an operator could otherwise omit this unnecessary header if it was
	properties of the leaf.		certain of the properties of the leaf.
	As storing mode can not know the final path of the traffic,		As storing mode can not know the final path of the traffic,
	intolerant (that drop packets with RPL artifacts) leaf nodes can not		intolerant (that drop packets with RPL artifacts) leaf nodes can not
	be supported.		be supported.
	10. Operational considerations of introducing 0x23		10. Operational considerations of introducing 0x23
	This section describes the operational considerations of introducing		This section describes the operational considerations of introducing
	the new RPI Option Type of 0x23.		the new RPI Option Type of 0x23.
	skipping to change at page 54, line 33 ¶		skipping to change at page 54, line 33 ¶
	DODAG Configuration option has been seen by all nodes.		DODAG Configuration option has been seen by all nodes.
	Before the migration happens, all the RPL-aware nodes should support		Before the migration happens, all the RPL-aware nodes should support
	both values . The migration procedure it is triggered when the DIO		both values . The migration procedure it is triggered when the DIO
	is sent with the flag indicating the new RPI Option Type. Namely, it		is sent with the flag indicating the new RPI Option Type. Namely, it
	remains at 0x63 until it is sure that the network is capable of 0x23,		remains at 0x63 until it is sure that the network is capable of 0x23,
	then it abruptly change to 0x23. This options allows to send packets		then it abruptly change to 0x23. This options allows to send packets
	to not-RPL nodes, which should ignore the option and continue		to not-RPL nodes, which should ignore the option and continue
	processing the packets.		processing the packets.
	In case that a node join to a network that only process 0x63, it		As mentioned previously, indicating the new RPI in the DODAG
	would produce a flag day as was mentioned previously. Indicating the		Configuration option flag is a way to avoid the flag day (lack of
	new RPI in the DODAG Configuration option Flag is a way to avoid the		interoperation) in a network using 0x63 as the RPI Option Type value.
	flag day in a network. It is recommended that a network process both		It is suggested that RPL implementations accept both 0x63 and 0x23
	options to enable interoperability.		RPI Option type values when processing the header to enable
			interoperability.
	11. IANA Considerations		11. IANA Considerations
	This document updates the registration made in [RFC6553] Destination		This document updates the registration made in [RFC6553] Destination
	Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in		Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in
	Figure 38.		Figure 38.
	+-------+-------------------+------------------------+---------- -+		+-------+-------------------+------------------------+---------- -+
	| Hex | Binary Value | Description | Reference |		| Hex | Binary Value | Description | Reference |
	+ Value +-------------------+ + +		+ Value +-------------------+ + +
	skipping to change at page 60, line 50 ¶		skipping to change at page 60, line 50 ¶
	[DDOS-KREBS]		[DDOS-KREBS]
	Goodin, D., "Record-breaking DDoS reportedly delivered by		Goodin, D., "Record-breaking DDoS reportedly delivered by
	>145k hacked cameras", September 2016,		>145k hacked cameras", September 2016,
	<http://arstechnica.com/security/2016/09/botnet-of-145k-		<http://arstechnica.com/security/2016/09/botnet-of-145k-
	cameras-reportedly-deliver-internets-biggest-ddos-ever/>.		cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
	[I-D.ietf-6lo-ap-nd]		[I-D.ietf-6lo-ap-nd]
	Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,		Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
	"Address Protected Neighbor Discovery for Low-power and		"Address Protected Neighbor Discovery for Low-power and
	Lossy Networks", draft-ietf-6lo-ap-nd-20 (work in		Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in
	progress), March 2020.		progress), April 2020.
	[I-D.ietf-6lo-backbone-router]		[I-D.ietf-6lo-backbone-router]
	Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6		Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
	Backbone Router", draft-ietf-6lo-backbone-router-19 (work		Backbone Router", draft-ietf-6lo-backbone-router-20 (work
	in progress), March 2020.		in progress), March 2020.
	[I-D.ietf-6tisch-dtsecurity-zerotouch-join]		[I-D.ietf-6tisch-dtsecurity-zerotouch-join]
	Richardson, M., "6tisch Zero-Touch Secure Join protocol",		Richardson, M., "6tisch Zero-Touch Secure Join protocol",
	draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in		draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
	progress), July 2019.		progress), July 2019.
	[I-D.ietf-anima-autonomic-control-plane]		[I-D.ietf-anima-autonomic-control-plane]
	Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic		Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
	Control Plane (ACP)", draft-ietf-anima-autonomic-control-		Control Plane (ACP)", draft-ietf-anima-autonomic-control-
	plane-24 (work in progress), March 2020.		plane-24 (work in progress), March 2020.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,		Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
	and K. Watsen, "Bootstrapping Remote Secure Key		and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-38 (work in progress), March 2020.		keyinfra-41 (work in progress), April 2020.
	[I-D.ietf-intarea-tunnels]		[I-D.ietf-intarea-tunnels]
	Touch, J. and M. Townsley, "IP Tunnels in the Internet		Touch, J. and M. Townsley, "IP Tunnels in the Internet
	Architecture", draft-ietf-intarea-tunnels-10 (work in		Architecture", draft-ietf-intarea-tunnels-10 (work in
	progress), September 2019.		progress), September 2019.
	[I-D.ietf-roll-unaware-leaves]		[I-D.ietf-roll-unaware-leaves]
	Thubert, P. and M. Richardson, "Routing for RPL Leaves",		Thubert, P. and M. Richardson, "Routing for RPL Leaves",
	draft-ietf-roll-unaware-leaves-13 (work in progress),		draft-ietf-roll-unaware-leaves-15 (work in progress),
	March 2020.		April 2020.
	[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, <https://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <https://www.rfc-editor.org/info/rfc2473>.		December 1998, <https://www.rfc-editor.org/info/rfc2473>.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
End of changes. 57 change blocks.
	106 lines changed or deleted		109 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/