rfc9008v1.txt		rfc9008.txt
	skipping to change at line 125 ¶		skipping to change at line 125 ¶
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	13.2. Informative References		13.2. Informative References
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	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. [RFC6553]		[RFC6550] is a routing protocol for constrained networks. [RFC6553]
	defines the RPL Option carried within the IPv6 Hop-by-Hop header to		defines the RPL Option carried within the IPv6 Hop-by-Hop Options
	carry the RPLInstanceID and quickly identify inconsistencies (loops)		header to carry the RPLInstanceID and quickly identify
	in the routing topology. The RPL Option is commonly referred to as		inconsistencies (loops) in the routing topology. The RPL Option is
	the RPL Packet Information (RPI), although the RPI is the routing		commonly referred to as the RPL Packet Information (RPI), although
	information that is defined in [RFC6550] and transported in the RPL		the RPI is the routing information that is defined in [RFC6550] and
	Option. RFC 6554 [RFC6554] defines the "RPL Source Route Header"		transported in the RPL Option. RFC 6554 [RFC6554] defines the "RPL
	(RH3), an IPv6 extension header to deliver datagrams within a RPL		Source Route Header" (RH3), an IPv6 extension header to deliver
	routing domain, particularly in Non-Storing mode.		datagrams within a RPL routing domain, particularly in Non-Storing
			mode.
	These various items are referred to as RPL artifacts, and they are		These various items are referred to as RPL artifacts, and they are
	seen on all of the data plane traffic that occurs in RPL-routed		seen on all of the data plane traffic that occurs in RPL-routed
	networks; they do not, in general, appear on the RPL control plane at		networks; they do not, in general, appear on the RPL control plane at
	all, which is mostly hop-by-hop traffic (one exception being		all, which is mostly hop-by-hop traffic (one exception being
	Destination Advertisement Object (DAO) messages in Non-Storing mode).		Destination Advertisement Object (DAO) messages in Non-Storing mode).
	It has become clear from attempts to do multi-vendor		It has become clear from attempts to do multi-vendor
	interoperability, and from a desire to compress as many of the above		interoperability, and from a desire to compress as many of the above
	artifacts as possible, that not all implementers agree when artifacts		artifacts as possible, that not all implementers agree when artifacts
	skipping to change at line 207 ¶		skipping to change at line 208 ¶
	Consumed: A Routing Header is consumed when the Segments Left field		Consumed: A Routing Header is consumed when the Segments Left field
	is zero, which indicates that the destination in the IPv6 header		is zero, which indicates that the destination in the IPv6 header
	is the final destination of the packet and that the hops in the		is the final destination of the packet and that the hops in the
	Routing Header have been traversed.		Routing Header have been traversed.
	RPL Leaf: An IPv6 host that is attached to a RPL router and obtains		RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
	connectivity through a RPL Destination-Oriented Directed Acyclic		connectivity through a RPL Destination-Oriented Directed Acyclic
	Graph (DODAG). As an IPv6 node, a RPL leaf is expected to ignore		Graph (DODAG). As an IPv6 node, a RPL leaf is expected to ignore
	a consumed Routing Header, and as an IPv6 host, it is expected to		a consumed Routing Header, and as an IPv6 host, it is expected to
	ignore a Hop-by-Hop header. Thus, a RPL leaf can correctly		ignore a Hop-by-Hop Options header. Thus, a RPL leaf can
	receive a packet with RPL artifacts. On the other hand, a RPL		correctly receive a packet with RPL artifacts. On the other hand,
	leaf is not expected to generate RPL artifacts or to support IP-		a RPL leaf is not expected to generate RPL artifacts or to support
	in-IP encapsulation. For simplification, this document uses the		IP-in-IP encapsulation. For simplification, this document uses
	standalone term leaf to mean a RPL leaf.		the standalone term leaf to mean a RPL leaf.
	RPL Packet Information (RPI): The information defined abstractly in		RPL Packet Information (RPI): The information defined abstractly in
	[RFC6550] to be placed in IP packets. The term is commonly used,		[RFC6550] to be placed in IP packets. The term is commonly used,
	including in this document, to refer to the RPL Option [RFC6553]		including in this document, to refer to the RPL Option [RFC6553]
	that transports that abstract information in an IPv6 Hop-by-Hop		that transports that abstract information in an IPv6 Hop-by-Hop
	header. [RFC8138] provides an alternate (more compressed)		Options header. [RFC8138] provides an alternate (more compressed)
	formatting for the same abstract information.		formatting for the same abstract information.
	RPL-Aware Node (RAN): A device that implements RPL. Please note		RPL-Aware Node (RAN): A device that implements RPL. Please note
	that the device can be found inside the LLN or outside LLN.		that the device can be found inside the LLN or outside LLN.
	RPL-Aware Leaf (RAL): A RPL-aware node that is also a RPL leaf.		RPL-Aware Leaf (RAL): A RPL-aware node that is also a RPL leaf.
	RPL-Unaware Node: A device that does not implement RPL, thus the		RPL-Unaware Node: A device that does not implement RPL, thus the
	device is RPL unaware. Please note that the device can be found		device is RPL unaware. Please note that the device can be found
	inside the LLN.		inside the LLN.
	skipping to change at line 332 ¶		skipping to change at line 333 ¶
	has been learned through an alternate protocol, for instance, a route		has been learned through an alternate protocol, for instance, a route
	to a prefix that is outside the RPL domain but reachable via a 6LR.		to a prefix that is outside the RPL domain but reachable via a 6LR.
	Being outside of the RPL domain, a node that is reached via an		Being outside of the RPL domain, a node that is reached via an
	external target cannot be guaranteed to ignore the RPL artifacts and		external target cannot be guaranteed to ignore the RPL artifacts and
	cannot be expected to process the compression defined in [RFC8138]		cannot be expected to process the compression defined in [RFC8138]
	correctly. This means that the RPL artifacts should be contained in		correctly. This means that the RPL artifacts should be contained in
	an IP-in-IP encapsulation that is removed by the 6LR, and that any		an IP-in-IP encapsulation that is removed by the 6LR, and that any
	remaining compression should be expanded by the 6LR before it		remaining compression should be expanded by the 6LR before it
	forwards a packet outside the RPL domain.		forwards a packet outside the RPL domain.
	This specification updates [RFC6550] to RECOMMEND that external		This specification updates [RFC6550] to say that advertising external
	targets are advertised using Non-Storing mode DAO messaging even in a		targets using Non-Storing mode DAO messaging even in a Storing mode
	Storing mode network. This way, external routes are not advertised		network is RECOMMENDED. This way, external routes are not advertised
	within the DODAG, and all packets to an external target reach the		within the DODAG, and all packets to an external target reach the
	root like normal Non-Storing mode traffic. The Non-Storing mode DAO		root like normal Non-Storing mode traffic. The Non-Storing mode DAO
	informs the root of the address of the 6LR that injects the external		informs the root of the address of the 6LR that injects the external
	route, and the root uses IP-in-IP encapsulation to that 6LR, which		route, and the root uses IP-in-IP encapsulation to that 6LR, which
	terminates the IP-in-IP tunnel and forwards the original packet		terminates the IP-in-IP tunnel and forwards the original packet
	outside the RPL domain free of RPL artifacts.		outside the RPL domain free of RPL artifacts.
	In the other direction, for traffic coming from an external target		In the other direction, for traffic coming from an external target
	into the LLN, the parent (6LR) that injects the traffic always		into the LLN, the parent (6LR) that injects the traffic always
	encapsulates to the root. This whole operation is transparent to		encapsulates to the root. This whole operation is transparent to
	intermediate routers that only see traffic between the 6LR and the		intermediate routers that only see traffic between the 6LR and the
	root, and only the root and the 6LRs that inject external routes in		root, and only the root and the 6LRs that inject external routes in
	the network need to be upgraded to add this function to the network.		the network need to be 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 Hop-by-Hop header as prescribed by [RFC8200]. The		and to ignore a Hop-by-Hop Options header as prescribed by [RFC8200].
	target may have been learned through an external routing protocol or		The target may have been learned through an external routing protocol
	may have been registered to the 6LR using [RFC8505].		or may 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 line 387 ¶		skipping to change at line 388 ¶
	[RFC6550], Section 6.3.1.		[RFC6550], Section 6.3.1.
	In addition, this document reserves MOP value 7 for future expansion.		In addition, this document reserves MOP value 7 for future expansion.
	See Sections 11.2 and 11.3.		See Sections 11.2 and 11.3.
	4.1.3. Indicating the New RPI in the DODAG Configuration Option Flag		4.1.3. Indicating the New RPI in the DODAG Configuration Option Flag
	In order to avoid a flag day caused by lack of interoperation between		In order to avoid a flag day caused by lack of interoperation between
	nodes of the new RPI Option Type (0x23) and old RPI Option Type		nodes of the new RPI Option Type (0x23) and old RPI Option Type
	(0x63), this section defines a flag in the DIO Configuration option,		(0x63), this section defines a flag in the DODAG Configuration
	to indicate when the new RPI Option Type can be safely used. This		option, to indicate when the new RPI Option Type can be safely used.
	means that the flag is going to indicate the value of Option Type		This means that the flag is going to indicate the value of Option
	that the network will be using for the RPL Option. Thus, when a node		Type that the network will be using for the RPL Option. Thus, when a
	joins to a network, it will know which value to use. With this, RPL-		node joins to a network, it will know which value to use. With this,
	capable nodes know if it is safe to use 0x23 when creating a new RPL		RPL-capable nodes know if it is safe to use 0x23 when creating a new
	Option. A node that forwards a packet with an RPI MUST NOT modify		RPL Option. A node that forwards a packet with an RPI MUST NOT
	the Option Type of the RPL Option.		modify the Option Type of the RPL Option.
	This is done using a DODAG Configuration option flag that will signal		This is done using a DODAG Configuration option flag that will signal
	"RPI 0x23 enable" and propagate through the network. Section 6.3.1		"RPI 0x23 enable" and propagate through the network. Section 6.3.1
	of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base		of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base
	Object. The flag is defined only for MOP value between 0 to 6.		Object. The flag is defined only for MOP value between 0 to 6.
	For a MOP value of 7, a node MUST use the RPI 0x23 option.		For a MOP value of 7, a node MUST use the RPI 0x23 option.
	As stated in [RFC6550], the DODAG Configuration option is present in		As stated in [RFC6550], the DODAG Configuration option is present in
	DIO messages. The DODAG Configuration option distributes		DIO messages. The DODAG Configuration option distributes
	skipping to change at line 467 ¶		skipping to change at line 468 ¶
	+===========+=====+=====+=======+=============+===========+		+===========+=====+=====+=======+=============+===========+
	| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |		| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |
	+-----------+-----+-----+-------+-------------+-----------+		+-----------+-----+-----+-------+-------------+-----------+
	Table 2: Option Type in RPL Option		Table 2: Option Type in RPL Option
	This document illustrates that it is not always possible to know for		This document illustrates that it is not always possible to know for
	sure at the source whether a packet will travel only within the RPL		sure at the source whether a packet will travel only within the RPL
	domain or whether it will leave it.		domain or whether it will leave it.
	At the time [RFC6553] was published, leaking a Hop-by-Hop header in		At the time [RFC6553] was published, leaking a Hop-by-Hop Options
	the outer IPv6 header chain could potentially impact core routers in		header in the outer IPv6 header chain could potentially impact core
	the Internet. So at that time, it was decided to encapsulate any		routers in the Internet. So at that time, it was decided to
	packet with a RPL Option using IPv6-in-IPv6 in all cases where it was		encapsulate any packet with a RPL Option using IPv6-in-IPv6 in all
	unclear whether the packet would remain within the RPL domain. In		cases where it was unclear whether the packet would remain within the
	the exception case where a packet would still leak, the Option Type		RPL domain. In the exception case where a packet would still leak,
	would ensure that the first router in the Internet that does not		the Option Type would ensure that the first router in the Internet
	recognize the option would drop the packet and protect the rest of		that does not recognize the option would drop the packet and protect
	the network.		the rest of the network.
	Even with [RFC8138], where the IPv6-in-IPv6 header is compressed,		Even with [RFC8138], where the IPv6-in-IPv6 header is compressed,
	this approach yields extra bytes in a packet; this means consuming		this approach yields extra bytes in a packet; this means consuming
	more energy and more bandwidth, incurring higher chances of loss, and		more energy and more bandwidth, incurring higher chances of loss, and
	possibly causing a fragmentation at the 6LoWPAN level. This impacts		possibly causing a fragmentation at the 6LoWPAN level. This impacts
	the daily operation of constrained devices for a case that generally		the daily operation of constrained devices for a case that generally
	does not happen and would not heavily impact the core anyway.		does not happen and would not heavily impact the core anyway.
	While the intention was and remains that the Hop-by-Hop header with a		While the intention was and remains that the Hop-by-Hop Options
	RPL Option should be confined within the RPL domain, this		header with a RPL Option should be confined within the RPL domain,
	specification modifies this behavior in order to reduce the		this specification modifies this behavior in order to reduce the
	dependency on IPv6-in-IPv6 and protect the constrained devices.		dependency on IPv6-in-IPv6 and protect the constrained devices.
	Section 4 of [RFC8200] clarifies the behavior of routers in the		Section 4 of [RFC8200] clarifies the behavior of routers in the
	Internet as follows: "it is now expected that nodes along a packet's		Internet as follows: "it is now expected that nodes along a packet's
	delivery path only examine and process the Hop-by-Hop Options header		delivery path only examine and process the Hop-by-Hop Options header
	if explicitly configured to do so."		if explicitly configured to do so."
	When unclear about the travel of a packet, it becomes preferable for		When unclear about the travel of a packet, it becomes preferable for
	a source not to encapsulate, accepting the fact that the packet may		a source not to encapsulate, accepting the fact that the packet may
	leave the RPL domain on its way to its destination. In that event,		leave the RPL domain on its way to its destination. In that event,
	the packet should reach its destination and should not be discarded		the packet should reach its destination and should not be discarded
	by the first node that does not recognize the RPL Option. However,		by the first node that does not recognize the RPL Option. However,
	with the current value of the Option Type, if a node in the Internet		with the current value of the Option Type, if a node in the Internet
	is configured to process the Hop-by-Hop header, and if such a node		is configured to process the Hop-by-Hop Options header, and if such a
	encounters an Option Type with the first two bits set to 01 and the		node encounters an Option Type with the first two bits set to 01 and
	node conforms to [RFC8200], it will drop the packet. Host systems		the node conforms to [RFC8200], it will drop the packet. Host
	should do the same, irrespective of the configuration.		systems should do the same, irrespective of the configuration.
	Thus, this document updates the Option Type of the RPL Option		Thus, this document updates the Option Type of the RPL Option
	[RFC6553], naming it RPI Option Type for simplicity (Table 3): the		[RFC6553], naming it RPI Option Type for simplicity (Table 3): the
	two high order bits MUST be set to '00', and the third bit is equal		two high order bits MUST be set to '00', and the third bit is equal
	to '1'. The first two bits indicate that the IPv6 node MUST skip		to '1'. The first two bits indicate that the IPv6 node MUST skip
	over this option and continue processing the header ([RFC8200],		over this option and continue processing the header ([RFC8200],
	Section 4.2) if it doesn't recognize the Option Type, and the third		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 may change		bit continues to be set to indicate that the Option Data may change
	en route. The rightmost five bits remain at 0x3(00011). This		en route. The rightmost five bits remain at 0x3(00011). This
	ensures that a packet that leaves the RPL domain of an LLN (or that		ensures that a packet that leaves the RPL domain of an LLN (or that
	skipping to change at line 550 ¶		skipping to change at line 551 ¶
	header.		header.
	When forwarding packets, implementations SHOULD use the same value of		When forwarding packets, implementations SHOULD use the same value of
	RPI Type as was received. This is required because the RPI Option		RPI Type as was received. This is required because the RPI Option
	Type does not change en route ([RFC8200], Section 4.2). It allows		Type does not change en route ([RFC8200], Section 4.2). It allows
	the network to be incrementally upgraded and allows the DODAG root to		the network to be incrementally upgraded and allows the DODAG root to
	know which parts of the network have been upgraded.		know which parts of the network have been upgraded.
	When originating new packets, implementations should have an option		When originating new packets, implementations should have an option
	to determine which value to originate with. This option is		to determine which value to originate with. This option is
	controlled by the DIO Configuration option (Section 4.1.3).		controlled by the DODAG Configuration option (Section 4.1.3).
	The change of RPI Option Type from 0x63 to 0x23 makes all nodes that		The change of RPI Option Type from 0x63 to 0x23 makes all nodes that
	are compliant with Section 4.2 of [RFC8200] tolerant of the RPL		are compliant with Section 4.2 of [RFC8200] tolerant of the RPL
	artifacts. There is no longer a need to remove the artifacts when		artifacts. There is no longer a need to remove the artifacts when
	sending traffic to the Internet. This change clarifies when to use		sending traffic to the Internet. This change clarifies when to use
	IPv6-in-IPv6 headers and how to address them: the Hop-by-Hop Options		IPv6-in-IPv6 headers and how to address them: the Hop-by-Hop Options
	header containing the RPI MUST always be added when 6LRs originate		header containing the RPI MUST always be added when 6LRs originate
	packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST		packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST
	always be added when a 6LR finds that it needs to insert a Hop-by-Hop		always be added when a 6LR finds that it needs to insert a Hop-by-Hop
	Options header containing the RPL Option. The IPv6-in-IPv6 header is		Options header containing the RPL Option. The IPv6-in-IPv6 header is
	skipping to change at line 602 ¶		skipping to change at line 603 ¶
	Section 7 of [RFC8138] documents how to compress the IPv6-in-IPv6		Section 7 of [RFC8138] documents how to compress the IPv6-in-IPv6
	header.		header.
	There are potential significant advantages to having a single code		There are potential significant advantages to having a single code
	path that always processes IPv6-in-IPv6 headers with no conditional		path that always processes IPv6-in-IPv6 headers with no conditional
	branches.		branches.
	In Storing mode, the scenarios where the flow goes from RAL to RUL		In Storing mode, the scenarios where the flow goes from RAL to RUL
	and RUL to RUL include compression of the IPv6-in-IPv6 and RPI		and RUL to RUL include compression of the IPv6-in-IPv6 and RPI
	headers. The use of the IPv6-in-IPv6 header is MANDATORY in this		headers. The IPv6-in-IPv6 header MUST be used in this case, and it
	case, and it SHOULD be compressed with [RFC8138], Section 7.		SHOULD be compressed as specified in [RFC8138], Section 7. Figure 2
	Figure 2 illustrates the case in Storing mode where the packet is		illustrates the case in Storing mode where the packet is received
	received from the Internet, then the root encapsulates the packet to		from the Internet, then the root encapsulates the packet to insert
	insert the RPI. In that example, the leaf is not known to support		the RPI. In that example, the leaf is not known to support RFC 8138,
	RFC 8138, and the packet is encapsulated to the 6LR that is the		and the packet is encapsulated to the 6LR that is the parent and last
	parent and last hop to the final destination.		hop to the final destination.
	+-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-...		+-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-...
	|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP		|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
	|Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld		|Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
	+-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-...		+-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-...
	<-4bytes-> <- RFC 6282 ->		<-4bytes-> <- RFC 6282 ->
	No RPL artifact		No RPL artifact
	Figure 2: RPI Inserted by the Root in Storing Mode		Figure 2: RPI Inserted by the Root in Storing Mode
	skipping to change at line 758 ¶		skipping to change at line 759 ¶
	RUL to RAL		RUL to RAL
	RUL to RUL		RUL to RUL
	This document is consistent with the rule that a header cannot be		This document is consistent with the rule that a header cannot be
	inserted or removed on the fly inside an IPv6 packet that is being		inserted or removed on the fly inside an IPv6 packet that is being
	routed. This is a fundamental precept of the IPv6 architecture as		routed. This is a fundamental precept of the IPv6 architecture as
	outlined in [RFC8200].		outlined in [RFC8200].
	As the rank information in the RPI artifact is changed at each hop,		As the Rank information in the RPI artifact is changed at each hop,
	it will typically be zero when it arrives at the DODAG root. The		it will typically be zero when it arrives at the DODAG root. The
	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 intermediate router can remove an RH3 or RPL		A corollary is that an intermediate router can remove an RH3 or RPL
	Option only if it is placed in an encapsulating IPv6 header that is		Option only if it is placed in an encapsulating IPv6 header that is
	addressed _to_ this intermediate router. When doing the above, 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.)
	addressed to the next-hop router using a 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		RPL Option are marked mutable but recoverable: so an IPsec
	Authentication Header (AH) can be applied across these headers, but		Authentication Header (AH) can be applied across these headers, but
	it cannot secure the values that mutate.		it cannot secure the values that mutate.
	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 interest in the code and tests. The ability to		adding significant interest in the code and tests. The ability to
	compress the RPI down to three bytes or less removes much of the		compress the RPI down to three bytes or less removes much of the
	pressure to optimize this any further [ACP].		pressure to optimize this any further.
	Throughout the following subsections, the examples are described in		Throughout the following subsections, the examples are described in
	more detail in the first subsections, and more concisely in the later		more detail in the first subsections, and more concisely in the later
	ones.		ones.
	The use cases are delineated based on the following IPV6 and RPL		The use cases are delineated based on the following IPV6 and RPL
	mandates:		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.
	skipping to change at line 945 ¶		skipping to change at line 945 ¶
	root to RAL		root to RAL
	RUL to root		RUL to root
	root to RUL		root to RUL
	7.1.1. SM: Example of Flow from RAL to Root		7.1.1. SM: Example of Flow from RAL to Root
	In Storing mode, RPI [RFC6553] is used to send the RPLInstanceID and		In Storing mode, RPI [RFC6553] is used to send the RPLInstanceID and
	rank information.		Rank information.
	In this case, the flow comprises:		In this case, the flow comprises:
	RAL (6LN) --> 6LR_i --> root (6LBR)		RAL (6LN) --> 6LR_i --> root (6LBR)
	For example, a communication flow could be: Node F (6LN) --> Node D		For example, a communication flow could be: Node F (6LN) --> Node D
	(6LR_i) --> Node B (6LR_i) --> Node A root (6LBR)		(6LR_i) --> Node B (6LR_i) --> Node A root (6LBR)
	The RAL (Node F) inserts the RPI, and sends the packet to the 6LR		The RAL (Node F) inserts the RPI, and sends the packet to the 6LR
	(Node D), which decrements the rank in the RPI and sends the packet		(Node D), which decrements the Rank in the RPI and sends the packet
	up. When the packet arrives at the 6LBR (Node A), the RPI is removed		up. When the packet arrives at the 6LBR (Node A), the RPI is removed
	and the packet is processed.		and the packet is processed.
	No IPv6-in-IPv6 header is required.		No IPv6-in-IPv6 header is required.
	The RPI can be removed by the 6LBR because the packet is addressed to		The RPI can be removed by the 6LBR because the packet is addressed to
	the 6LBR. The RAL must know that it is communicating with the 6LBR		the 6LBR. The RAL must know that it is communicating with the 6LBR
	to make use of this scenario. The RAL can know the address of the		to make use of this scenario. The RAL can know the address of the
	6LBR because it knows the address of the root via the DODAGID in the		6LBR because it knows the address of the root via the DODAGID in the
	DIO messages.		DIO messages.
	skipping to change at line 994 ¶		skipping to change at line 994 ¶
	7.1.2. SM: Example of Flow from Root to RAL		7.1.2. SM: Example of Flow from Root to RAL
	In this case, the flow comprises:		In this case, the flow comprises:
	root (6LBR) --> 6LR_i --> RAL (6LN)		root (6LBR) --> 6LR_i --> RAL (6LN)
	For example, a communication flow could be: Node A root (6LBR) -->		For example, a communication flow could be: Node A root (6LBR) -->
	Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN)		Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN)
	In this case, the 6LBR inserts RPI and sends the packet down. The		In this case, the 6LBR inserts RPI and sends the packet down. The
	6LR increments the rank in the RPI (it examines the RPLInstanceID to		6LR increments the Rank in the RPI (it examines the RPLInstanceID to
	identify the right forwarding table). The packet is processed in the		identify the right forwarding table). The packet is processed in the
	RAL, and the RPI is removed.		RAL, and the RPI is removed.
	No IPv6-in-IPv6 header is required.		No IPv6-in-IPv6 header is required.
	Table 6 summarizes which headers are needed for this use case.		Table 6 summarizes which headers are needed for this use case.
	+===================+==========+=======+=========+		+===================+==========+=======+=========+
	| Header | 6LBR src | 6LR_i | RAL dst |		| Header | 6LBR src | 6LR_i | RAL dst |
	+===================+==========+=======+=========+		+===================+==========+=======+=========+
	skipping to change at line 1038 ¶		skipping to change at line 1038 ¶
	total number of routers (6LR) that the packet goes through, from the		total number of routers (6LR) that the packet goes through, from the
	6LBR (Node A) to the RUL (Node G).		6LBR (Node A) to the RUL (Node G).
	The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header and		The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header and
	prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR		prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR
	parent of the RUL (6LR_n). The 6LR parent of the RUL removes the		parent of the RUL (6LR_n). The 6LR parent of the RUL removes the
	header and sends the packet to the RUL.		header and sends the packet to the RUL.
	Table 7 summarizes which headers are needed for this use case.		Table 7 summarizes which headers are needed for this use case.
	+===================+=============+=========+=============+=========+		+==================+===============+=========+=========+=========+
	| Header | 6LBR src | 6LR_i | 6LR_n | RUL dst |		| Header | 6LBR src | 6LR_i | 6LR_n | RUL dst |
	+===================+=============+=========+=============+=========+		+==================+===============+=========+=========+=========+
	| Added headers | IP6-IP6 RPI | -- | -- | -- |		| Added headers | IP6-IP6 (RPI) | -- | -- | -- |
	+===================+-------------+---------+-------------+---------+		+==================+---------------+---------+---------+---------+
	| Modified headers | -- | RPI | -- | -- |		| Modified headers | -- | RPI | -- | -- |
	+===================+-------------+---------+-------------+---------+		+==================+---------------+---------+---------+---------+
	| Removed headers | -- | -- | IP6-IP6 RPI | -- |		| Removed headers | -- | -- | IP6-IP6 | -- |
	+===================+-------------+---------+-------------+---------+		| | | | (RPI) | |
	| Untouched | -- | IP6-IP6 | -- | -- |		+==================+---------------+---------+---------+---------+
	| headers | | | | |		| Untouched | -- | IP6-IP6 | -- | -- |
	+===================+-------------+---------+-------------+---------+		| headers | | | | |
			+==================+---------------+---------+---------+---------+
	Table 7: SM: Summary of the Use of Headers from Root to RUL		Table 7: 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 RH3 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 RH3, and the		operation, then the 6LR forwards to the RUL based on the RH3, and the
	RUL ignores both the consumed RH3 and the RPI, as in Non-Storing		RUL ignores both the consumed RH3 and the RPI, as in Non-Storing
	mode.		mode.
	Table 8 summarizes which headers are needed for this scenario.		Table 8 summarizes which headers are needed for this scenario.
	skipping to change at line 1104 ¶		skipping to change at line 1105 ¶
	6LBR.		6LBR.
	When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the		When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the
	6LR_1 will encapsulate the packet in an IPv6-in-IPv6 header with an		6LR_1 will encapsulate the packet in an IPv6-in-IPv6 header with an
	RPI. The IPv6-in-IPv6 header is addressed to the root (Node A). The		RPI. The IPv6-in-IPv6 header is addressed to the root (Node A). The
	root removes the header and processes the packet.		root removes the header and processes the packet.
	Table 9 summarizes which headers are needed for this use case where		Table 9 summarizes which headers are needed for this use case where
	the IPv6-in-IPv6 header is addressed to the root (Node A).		the IPv6-in-IPv6 header is addressed to the root (Node A).
	+===================+=========+=============+=========+=============+		+==================+=========+===============+=========+==========+
	| Header | RUL src | 6LR_1 | 6LR_i | 6LBR dst |		| Header | RUL src | 6LR_1 | 6LR_i | 6LBR dst |
	+===================+=========+=============+=========+=============+		+==================+=========+===============+=========+==========+
	| Added headers | -- | IP6-IP6 RPI | -- | -- |		| Added headers | -- | IP6-IP6 (RPI) | -- | -- |
	+===================+---------+-------------+---------+-------------+		+==================+---------+---------------+---------+----------+
	| Modified headers | -- | -- | RPI | -- |		| Modified headers | -- | -- | RPI | -- |
	+===================+---------+-------------+---------+-------------+		+==================+---------+---------------+---------+----------+
	| Removed headers | -- | -- | -- | IP6-IP6 RPI |		| Removed headers | -- | -- | -- | IP6-IP6 |
	+===================+---------+-------------+---------+-------------+		| | | | | (RPI) |
	| Untouched | -- | -- | IP6-IP6 | -- |		+==================+---------+---------------+---------+----------+
	| headers | | | | |		| Untouched | -- | -- | IP6-IP6 | -- |
	+===================+---------+-------------+---------+-------------+		| headers | | | | |
			+==================+---------+---------------+---------+----------+
	Table 9: SM: Summary of the Use of Headers from RUL to Root		Table 9: 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
	This section describes the communication flow in Storing mode (SM)		This section describes the communication flow in Storing mode (SM)
	between the following:		between the following:
	RAL to Internet		RAL to Internet
	skipping to change at line 1153 ¶		skipping to change at line 1155 ¶
	routers (6LR) that the packet goes through, from the RAL to the 6LBR.		routers (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 that have not been configured to be RPL aware. No		ignored by nodes that have not been configured to be RPL 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 an		On the other hand, the RAL may insert the RPI encapsulated in an
	IPv6-in-IPv6 header to the root. Thus, the root removes the RPI and		IPv6-in-IPv6 header to the root. Thus, the root removes the RPI and
	sends the packet to the Internet.		sends the packet to the Internet.
	| Note: In this use case, it is used a node as a leaf, but this		| Note: In this use case, a leaf node is used, but this use case
	| use case can be also applicable to any RPL-aware node type		| can also be applicable to any RPL-aware node type (e.g., 6LR).
	| (e.g., 6LR).
	Table 10 summarizes which headers are needed for this use case when		Table 10 summarizes which headers are needed for this use case when
	there is no encapsulation. Note that the RPI is modified by 6LBR to		there is no encapsulation. Note that the RPI is modified by 6LBR to
	set the SenderRank to zero in the case that it is not already zero.		set the SenderRank to zero in the case that it is not already zero.
	Table 11 summarizes which headers are needed when encapsulation to		Table 11 summarizes which headers are needed when encapsulation to
	the root takes place.		the root takes place.
	+===================+=========+=======+======+===============+		+===================+=========+=======+======+===============+
	| Header | RAL src | 6LR_i | 6LBR | Internet dst |		| Header | RAL src | 6LR_i | 6LBR | Internet dst |
	+===================+=========+=======+======+===============+		+===================+=========+=======+======+===============+
	skipping to change at line 1178 ¶		skipping to change at line 1179 ¶
	| Modified headers | -- | RPI | RPI | -- |		| Modified headers | -- | RPI | RPI | -- |
	+===================+---------+-------+------+---------------+		+===================+---------+-------+------+---------------+
	| Removed headers | -- | -- | -- | -- |		| Removed headers | -- | -- | -- | -- |
	+===================+---------+-------+------+---------------+		+===================+---------+-------+------+---------------+
	| Untouched headers | -- | -- | -- | RPI (Ignored) |		| Untouched headers | -- | -- | -- | RPI (Ignored) |
	+===================+---------+-------+------+---------------+		+===================+---------+-------+------+---------------+
	Table 10: SM: Summary of the Use of Headers from RAL to		Table 10: SM: Summary of the Use of Headers from RAL to
	Internet with No Encapsulation		Internet with No Encapsulation
	+==================+=============+=========+=========+==============+		+===============+===============+=========+=========+==============+
	| Header | RAL src | 6LR_i | 6LBR | Internet dst |		| Header | RAL src | 6LR_i | 6LBR | Internet dst |
	+==================+=============+=========+=========+==============+		+===============+===============+=========+=========+==============+
	| Added headers | IP6-IP6 RPI | -- | -- | -- |		| Added headers | IP6-IP6 (RPI) | -- | -- | -- |
	+==================+-------------+---------+---------+--------------+		+===============+---------------+---------+---------+--------------+
	| Modified | -- | RPI | -- | -- |		| Modified | -- | RPI | -- | -- |
	| headers | | | | |		| headers | | | | |
	+==================+-------------+---------+---------+--------------+		+===============+---------------+---------+---------+--------------+
	| Removed | -- | -- | IP6-IP6 | -- |		| Removed | -- | -- | IP6-IP6 | -- |
	| headers | | | RPI | |		| headers | | | (RPI) | |
	+==================+-------------+---------+---------+--------------+		+===============+---------------+---------+---------+--------------+
	| Untouched | -- | IP6-IP6 | -- | -- |		| Untouched | -- | IP6-IP6 | -- | -- |
	| headers | | | | |		| headers | | | | |
	+==================+-------------+---------+---------+--------------+		+===============+---------------+---------+---------+--------------+
	Table 11: SM: Summary of the Use of Headers from RAL to Internet with		Table 11: SM: Summary of the Use of Headers from RAL to Internet
	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:
	Internet --> root (6LBR) --> 6LR_i --> RAL (6LN)		Internet --> root (6LBR) --> 6LR_i --> RAL (6LN)
	For example, a communication flow could be: Internet --> Node A root		For example, a communication flow could be: Internet --> Node A root
	(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL)		(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL)
	When the packet arrives from Internet to 6LBR, the RPI is added in a		When the packet arrives from Internet to 6LBR, the RPI is added in a
	outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address		outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address
	set to the RAL) and sent to the 6LR, which modifies the rank in the		set to the RAL) and sent to the 6LR, which modifies the Rank in the
	RPI. When the packet arrives at the RAL, the packet is decapsulated,		RPI. When the packet arrives at the RAL, the packet is decapsulated,
	which removes the RPI before the packet is processed.		which removes the RPI before the packet is processed.
	Table 12 summarizes which headers are needed for this use case.		Table 12 summarizes which headers are needed for this use case.
	+==================+==============+===============+=======+=========+		+==================+==============+===============+=======+=========+
	| Header | Internet src | 6LBR | 6LR_i | RAL dst |		| Header | Internet src | 6LBR | 6LR_i | RAL dst |
	+==================+==============+===============+=======+=========+		+==================+==============+===============+=======+=========+
	| Added headers | -- | IP6-IP6 (RPI) | -- | -- |		| Added headers | -- | IP6-IP6 (RPI) | -- | -- |
	+==================+--------------+---------------+-------+---------+		+==================+--------------+---------------+-------+---------+
	skipping to change at line 1241 ¶		skipping to change at line 1242 ¶
	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
	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) --> Internet		(6LR_1) --> Node B (6lR_i) --> Node A root (6LBR) --> Internet
	The node 6LR_1 (i=1) will add an IPv6-in-IPv6 (RPI) header addressed		The node 6LR_1 (i=1) will add an IPv6-in-IPv6 (RPI) header addressed
	to the root such that the root can remove the RPI before passing		to the root such that the root can remove the RPI before passing
	upwards. In the intermediate 6LR, the rank in the RPI is modified.		upwards. In the intermediate 6LR, the Rank in the RPI is modified.
	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 the packet can be better compressed through the LLN. The		so that the packet can be better compressed through the LLN. The
	6LBR will set the flow label of the packet to a non-zero value when		6LBR will set the flow label of the packet to a non-zero value when
	sending to the Internet. For details, check [RFC6437].		sending to the Internet. For details, check [RFC6437].
	Table 13 summarizes which headers are needed for this use case.		Table 13 summarizes which headers are needed for this use case.
	+===========+==========+=========+=============+=========+==========+		+===========+=======+=========+==============+=========+==========+
	| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet |		| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet |
	| | src | | [i=2,...,n] | | dst |		| | src | | i=(1,..,n-1) | | dst |
	| | (RUL) | | | | |		| | (RUL) | | | | |
	+===========+==========+=========+=============+=========+==========+		+===========+=======+=========+==============+=========+==========+
	| Added | -- | IP6-IP6 | -- | -- | -- |		| Added | -- | IP6-IP6 | -- | -- | -- |
	| headers | | (RPI) | | | |		| headers | | (RPI) | | | |
	+===========+----------+---------+-------------+---------+----------+		+===========+-------+---------+--------------+---------+----------+
	| Modified | -- | -- | RPI | -- | -- |		| Modified | -- | -- | RPI | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+===========+----------+---------+-------------+---------+----------+		+===========+-------+---------+--------------+---------+----------+
	| Removed | -- | -- | -- | IP6-IP6 | -- |		| Removed | -- | -- | -- | IP6-IP6 | -- |
	| headers | | | | (RPI) | |		| headers | | | | (RPI) | |
	+===========+----------+---------+-------------+---------+----------+		+===========+-------+---------+--------------+---------+----------+
	| Untouched | -- | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+===========+----------+---------+-------------+---------+----------+		+===========+-------+---------+--------------+---------+----------+
	Table 13: SM: Summary of the Use of Headers from RUL to Internet		Table 13: SM: Summary of the Use of Headers from RUL to Internet
	7.2.4. SM: Example of Flow from Internet to RUL		7.2.4. SM: Example of Flow from Internet to RUL
	In this case, the flow comprises:		In this case, the flow comprises:
	Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)		Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
	For example, a communication flow could be: Internet --> Node A root		For example, a communication flow could be: Internet --> Node A root
	(6LBR) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL)		(6LBR) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL)
	The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The		The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The
	IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL.		IPv6-in-IPv6 encapsulating header is addressed to the 6LR parent of
			the RUL.
	Further details about this are mentioned in [RFC9010], which		Further details about this are mentioned in [RFC9010], which
	specifies RPL routing for a 6LN acting as a plain host and being		specifies RPL routing for a 6LN acting as a plain host and being
	unaware of RPL.		unaware of RPL.
	The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to		The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to
	zero in order to aid in compression [RFC8138] [RFC6437].		zero in order to aid in compression [RFC8138] [RFC6437].
	Table 14 summarizes which headers are needed for this use case.		Table 14 summarizes which headers are needed for this use case.
	+===========+==============+=========+==============+=========+=====+		+===========+==============+=========+==============+=========+=====+
	| Header | Internet | 6LBR | 6LR_i | 6LR_n | RUL |		| Header | Internet | 6LBR | 6LR_i | 6LR_n | RUL |
	| | src | | [i=1,..,n-1] | | dst |		| | src | | i=(1,..,n-1) | | dst |
	+===========+==============+=========+==============+=========+=====+		+===========+==============+=========+==============+=========+=====+
	| Inserted | -- | IP6-IP6 | -- | -- | -- |		| Added | -- | IP6-IP6 | -- | -- | -- |
	| headers | | (RPI) | | | |		| headers | | (RPI) | | | |
	+===========+--------------+---------+--------------+---------+-----+		+===========+--------------+---------+--------------+---------+-----+
	| Modified | -- | -- | RPI | -- | -- |		| Modified | -- | -- | RPI | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+===========+--------------+---------+--------------+---------+-----+		+===========+--------------+---------+--------------+---------+-----+
	| Removed | -- | -- | -- | IP6-IP6 | -- |		| Removed | -- | -- | -- | IP6-IP6 | -- |
	| headers | | | | (RPI) | |		| headers | | | | (RPI) | |
	+===========+--------------+---------+--------------+---------+-----+		+===========+--------------+---------+--------------+---------+-----+
	| Untouched | -- | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	skipping to change at line 1495 ¶		skipping to change at line 1497 ¶
	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 applies		that the packet goes through, from the RUL to the root. 6LR_1 applies
	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 (Node J). In this case, 1 <= id <=		(Node A) to the destination RUL (Node J). In this case, 1 <= id <=
	m, where m is the total number of routers (6LR) that the packet goes		m, where m is the total number of routers (6LR) that the packet goes
	through, from the root to the destination RUL.		through, from the root to the destination RUL.
	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 adds
	inserts the RPI (RPI1), encapsulated in an IPv6-in-IPv6 header		the RPI (RPI1) in an IPv6-in-IPv6 encapsulation directed to the root.
	directed to the root. The root removes the outer header including		The root removes the outer header including the RPI (RPI1) and
	the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR		inserts a new RPI (RPI2) addressed to the 6LR parent of the RUL.
	parent of the RUL.
	Table 18 summarizes which headers are needed for this use case.		Table 18 summarizes which headers are needed for this use case.
	+===========+===+=========+========+=========+========+=========+===+		+===========+===+=========+========+=========+========+=========+===+
	| Header |RUL| 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LR_n |RUL|		| Header |RUL| 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LR_n |RUL|
	| |src| | | | | |dst|		| |src| | | | | |dst|
	+===========+===+=========+========+=========+========+=========+===+		+===========+===+=========+========+=========+========+=========+===+
	| Added | --| IP6-IP6 | -- | IP6-IP6 | -- | -- | --|		| Added | --| IP6-IP6 | -- | IP6-IP6 | -- | -- | --|
	| headers | | (RPI1) | | (RPI1) | | | |		| headers | | (RPI1) | | (RPI1) | | | |
	+===========+---+---------+--------+---------+--------+---------+---+		+===========+---+---------+--------+---------+--------+---------+---+
	skipping to change at line 1615 ¶		skipping to change at line 1616 ¶
	root to RAL		root to RAL
	RUL to root		RUL to root
	root to RUL		root to RUL
	8.1.1. Non-SM: Example of Flow from RAL to Root		8.1.1. Non-SM: Example of Flow from RAL 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 must be included since it contains the		traffic to the root. The RPI must be included since it contains the
	rank information, which is used to avoid and/or detect loops.		Rank information, which is used to avoid and/or detect loops.
	RAL (6LN) --> 6LR_i --> root(6LBR)		RAL (6LN) --> 6LR_i --> root(6LBR)
	For example, a communication flow could be: Node F --> Node D -->		For example, a communication flow could be: Node F --> Node D -->
	Node B --> Node A (root)		Node B --> Node A (root)
	6LR_i represents the intermediate routers from the source to the		6LR_i represents the intermediate routers from the source to the
	destination. In this case, 1 <= i <= n, where n is the total number		destination. In this case, 1 <= i <= n, where n is the total number
	of routers (6LR) that the packet goes through, from the source (RAL)		of routers (6LR) that the packet goes through, from the source (RAL)
	to the destination (6LBR).		to the destination (6LBR).
	skipping to change at line 1900 ¶		skipping to change at line 1901 ¶
	6LBR, e.g., 6LR_1 (i=1).		6LBR, e.g., 6LR_1 (i=1).
	In this case, the flow label is recommended to be zero in the RUL.		In this case, the flow label is recommended to be zero in the RUL.
	As the RUL parent adds RPL headers in the RUL packet, the first 6LR		As the RUL parent adds RPL headers in the RUL packet, the first 6LR
	(6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6-		(6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6-
	in-IPv6 header will be addressed to the root. This case is identical		in-IPv6 header will be addressed to the root. This case is identical
	to the Storing mode case (see Section 7.2.3).		to the Storing mode case (see Section 7.2.3).
	Table 27 summarizes which headers are needed for this use case.		Table 27 summarizes which headers are needed for this use case.
	+===========+=========+=========+============+=========+==========+		+===========+=========+=========+==============+=========+==========+
	| Header | RUL src | 6LR_1 | 6LR_i | 6LBR | Internet |		| Header | RUL | 6LR_1 | 6LR_i | 6LBR | Internet |
	| | | | [i=2,..,n] | | dst |		| | src | | i=(1,..,n-1) | | dst |
	+===========+=========+=========+============+=========+==========+		+===========+=========+=========+==============+=========+==========+
	| Added | -- | IP6-IP6 | -- | -- | -- |		| Added | -- | IP6-IP6 | -- | -- | -- |
	| headers | | (RPI) | | | |		| headers | | (RPI) | | | |
	+===========+---------+---------+------------+---------+----------+		+===========+---------+---------+--------------+---------+----------+
	| Modified | -- | -- | RPI | -- | -- |		| Modified | -- | -- | RPI | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+===========+---------+---------+------------+---------+----------+		+===========+---------+---------+--------------+---------+----------+
	| Removed | -- | -- | -- | IP6-IP6 | -- |		| Removed | -- | -- | -- | IP6-IP6 | -- |
	| headers | | | | (RPI) | |		| headers | | | | (RPI) | |
	+===========+---------+---------+------------+---------+----------+		+===========+---------+---------+--------------+---------+----------+
	| Untouched | -- | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+===========+---------+---------+------------+---------+----------+		+===========+---------+---------+--------------+---------+----------+
	Table 27: Non-SM: Summary of the Use of Headers from RUL to		Table 27: Non-SM: Summary of the Use of Headers from RUL to Internet
	Internet
	8.2.4. Non-SM: Example of Flow from Internet to RUL		8.2.4. Non-SM: Example of Flow from Internet to RUL
	In this case, the flow comprises:		In this case, the flow comprises:
	Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)		Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
	For example, a communication flow could be: Internet --> Node A		For example, a communication flow could be: Internet --> Node A
	(root) --> Node B --> Node E --> Node G		(root) --> Node B --> Node E --> Node G
	skipping to change at line 2047 ¶		skipping to change at line 2047 ¶
	| headers | | | | | |		| headers | | | | | |
	+===========+---------+--------+---------------+---------+---------+		+===========+---------+--------+---------------+---------+---------+
	Table 29: Non-SM: Summary of the Use of Headers from RAL to RAL with		Table 29: Non-SM: Summary of the Use of Headers from RAL to RAL with
	Encapsulation to the Root		Encapsulation to the Root
	+===========+======+========+=============+=============+===========+		+===========+======+========+=============+=============+===========+
	| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL dst |		| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL dst |
	| | src | | | | |		| | src | | | | |
	+===========+======+========+=============+=============+===========+		+===========+======+========+=============+=============+===========+
	| Inserted | RPI1 | -- | IP6-IP6 | -- | -- |		| Added | RPI1 | -- | IP6-IP6 | -- | -- |
	| headers | | | (RH3, RPI2) | | |		| headers | | | (RH3, RPI2) | | |
	+===========+------+--------+-------------+-------------+-----------+		+===========+------+--------+-------------+-------------+-----------+
	| 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) |
	+===========+------+--------+-------------+-------------+-----------+		+===========+------+--------+-------------+-------------+-----------+
	skipping to change at line 2124 ¶		skipping to change at line 2124 ¶
	| headers | | | | | | |		| headers | | | | | | |
	+===========+---------+--------+---------+---------+---------+-----+		+===========+---------+--------+---------+---------+---------+-----+
	Table 31: Non-SM: Summary of the Use of Headers from RAL to RUL with		Table 31: Non-SM: Summary of the Use of Headers from RAL to RUL with
	Encapsulation to the Root		Encapsulation to the Root
	+===========+====+========+=========+=========+=========+===========+		+===========+====+========+=========+=========+=========+===========+
	| Header |RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL dst |		| Header |RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL dst |
	| |src | | | | | |		| |src | | | | | |
	+===========+====+========+=========+=========+=========+===========+		+===========+====+========+=========+=========+=========+===========+
	| Inserted |RPI1| -- | IP6-IP6 | -- | -- | -- |		| Added |RPI1| -- | IP6-IP6 | -- | -- | -- |
	| headers | | | (RH3, | | | |		| headers | | | (RH3, | | | |
	| | | | RPI2) | | | |		| | | | RPI2) | | | |
	+===========+----+--------+---------+---------+---------+-----------+		+===========+----+--------+---------+---------+---------+-----------+
	| 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) | |
	skipping to change at line 2243 ¶		skipping to change at line 2243 ¶
	9. Operational Considerations of Supporting RULs		9. Operational Considerations of Supporting RULs
	Roughly half of the situations described in this document involve		Roughly half of the situations described in this document involve
	leaf ("host") nodes that do not speak RPL. These nodes fall into two		leaf ("host") nodes that do not speak RPL. These nodes fall into two
	further categories: ones that drop a packet that have RPI or RH3		further categories: ones that drop a packet that have RPI or RH3
	headers, and ones that continue to process a packet that has RPI and/		headers, and ones that continue to process a packet that has RPI and/
	or RH3 headers.		or RH3 headers.
	[RFC8200] provides for new rules that suggest that nodes that have		[RFC8200] provides for new rules that suggest that nodes that have
	not been configured (explicitly) to examine Hop-by-Hop headers should		not been configured (explicitly) to examine Hop-by-Hop Options
	ignore those headers and continue processing the packet. Despite		headers should ignore those headers and continue processing the
	this, and despite the switch from 0x63 to 0x23, there may be nodes		packet. Despite this, and despite the switch from 0x63 to 0x23,
	that predate RFC 8200 or are simply intolerant. Those nodes will		there may be nodes that predate RFC 8200 or are simply intolerant.
	drop packets that continue to have RPL artifacts in them. In		Those nodes will drop packets that continue to have RPL artifacts in
	general, such nodes cannot be easily supported in RPL LLNs.		them. In general, such nodes cannot be easily supported in RPL LLNs.
	There are some specific cases where it is possible to remove the RPL		There are some specific cases where it is possible to remove the RPL
	artifacts prior to forwarding the packet to the leaf host. The		artifacts prior to forwarding the packet to the leaf host. The
	critical thing is that the artifacts have been inserted by the RPL		critical thing is that the artifacts have been inserted by the RPL
	root inside an IPv6-in-IPv6 header, and that the header has been		root inside an IPv6-in-IPv6 header, and that the header has been
	addressed to the 6LR immediately prior to the leaf node. In that		addressed to the 6LR immediately prior to the leaf node. In that
	case, in the process of removing the IPv6-in-IPv6 header, the		case, in the process of removing the IPv6-in-IPv6 header, the
	artifacts can also be removed.		artifacts can also be removed.
	The above case occurs whenever traffic originates from the outside		The above case occurs whenever traffic originates from the outside
	skipping to change at line 2290 ¶		skipping to change at line 2290 ¶
	intolerant leaf nodes, which drop packets with RPL artifacts, cannot		intolerant leaf nodes, which drop packets with RPL artifacts, cannot
	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.
	During bootstrapping, the node receives the DIO with the information		During bootstrapping, the node receives the DIO with the information
	of RPI Option Type, indicating the new RPI in the DODAG Configuration		of RPI Option Type, indicating the new RPI in the DODAG Configuration
	option flag. The DODAG root is in charge to configure the current		option flag. The DODAG root is in charge of configuring the current
	network with the new value, through DIO messages, and determines when		network with the new value, through DIO messages, and determining
	all the nodes are set with the new value. The DODAG should change to		when all the nodes have been set with the new value. The DODAG
	a new DODAG version. In case of rebooting, the node does not		should change to a new DODAG version. In case of rebooting, the node
	remember the RPI Option Type. Thus, the DIO is sent with a flag		does not remember the RPI Option Type. Thus, the DIO is sent with a
	indicating the new RPI Option Type.		flag indicating the new RPI Option Type.
	The DODAG Configuration option is contained in a RPL DIO message,		The DODAG Configuration option is contained in a RPL DIO message,
	which contains a unique Destination Advertisement Trigger Sequence		which contains a unique Destination Advertisement Trigger Sequence
	Number (DTSN) counter. The leaf nodes respond to this message with		Number (DTSN) counter. The leaf nodes respond to this message with
	DAO messages containing the same DTSN. This is a normal part of RPL		DAO messages containing the same DTSN. This is a normal part of RPL
	routing; the RPL root therefore knows when the updated DODAG		routing; the RPL root therefore knows when the updated DODAG
	Configuration option has been seen by all nodes.		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 is triggered when the DIO is		both values. The migration procedure is triggered when the DIO is
	skipping to change at line 2389 ¶		skipping to change at line 2389 ¶
	While a typical LLN may be a very poor origin for attack traffic (as		While a typical LLN may be a very poor origin for attack traffic (as
	the networks tend to be very slow, and the nodes often have very low		the networks tend to be very slow, and the nodes often have very low
	duty cycles), given enough nodes, LLNs could still have a significant		duty cycles), given enough nodes, LLNs could still have a significant
	impact, particularly if the attack is targeting another LLN.		impact, particularly if the attack is targeting another LLN.
	Additionally, some uses of RPL involve large-backbone, ISP-scale		Additionally, some uses of RPL involve large-backbone, ISP-scale
	equipment [ACP], which may be equipped with multiple 100 Gb/s		equipment [ACP], which may be equipped with multiple 100 Gb/s
	interfaces.		interfaces.
	Blocking or careful filtering of IPv6-in-IPv6 traffic entering the		Blocking or careful filtering of IPv6-in-IPv6 traffic entering the
	LLN as described above will make sure that any attack that is mounted		LLN as described above will make sure that any attack that is mounted
	must originate from compromised nodes within the LLN. The use of BCP		must originate from compromised nodes within the LLN. The use of
	38 [BCP38] filtering at the RPL root on egress traffic will both		network ingress filtering [BCP38] on egress traffic at the RPL root
	alert the operator to the existence of the attack, as well as drop		will alert the operator to the existence of the attack as well as
	the attack traffic. As the RPL network is typically numbered from a		drop the attack traffic. As the RPL network is typically numbered
	single prefix, which is itself assigned by RPL, BCP38 filtering		from a single prefix, which is itself assigned by RPL, network
	involves a single prefix comparison and should be trivial to		ingress filtering [BCP38] involves a single prefix comparison and
	automatically configure.		should be trivial to automatically configure.
	There are some scenarios where IPv6-in-IPv6 traffic should be allowed		There are some scenarios where IPv6-in-IPv6 traffic should be allowed
	to pass through the RPL root, such as the IPv6-in-IPv6 mediated		to pass through the RPL root, such as the IPv6-in-IPv6 mediated
	communications between a new pledge and the Join Registrar/		communications between a new pledge and the Join Registrar/
	Coordinator (JRC) when using [BRSKI] and [ZEROTOUCH-JOIN]. This is		Coordinator (JRC) when using [BRSKI] and [ZEROTOUCH-JOIN]. This is
	the case for the RPL root to do careful filtering: it occurs only		the case for the RPL root to do careful filtering: it occurs only
	when the Join Coordinator is not co-located inside the RPL root.		when the Join Coordinator is not co-located inside the RPL root.
	With the above precautions, an attack using IPv6-in-IPv6 tunnels can		With the above precautions, an attack using IPv6-in-IPv6 tunnels can
	only be by a node within the LLN on another node within the LLN.		only be by a node within the LLN on another node within the LLN.
	Such an attack could, of course, be done directly. An attack of this		Such an attack could, of course, be done directly. An attack of this
	kind is meaningful only if the source addresses are either fake or if		kind is meaningful only if the source addresses are either fake or if
	the point is to amplify return traffic. Such an attack could also be		the point is to amplify return traffic. Such an attack could also be
	done without the use of IPv6-in-IPv6 headers using forged source		done without the use of IPv6-in-IPv6 headers, by using forged source
	addresses. If the attack requires bidirectional communication, then		addresses instead. If the attack requires bidirectional
	IPv6-in-IPv6 provides no advantages.		communication, then IPv6-in-IPv6 provides no advantages.
	Whenever IPv6-in-IPv6 headers are being proposed, there is a concern		Whenever IPv6-in-IPv6 headers are being proposed, there is a concern
	about creating security issues. In the Security Considerations		about creating security issues. In the Security Considerations
	section of [RFC2473] (Section 9), it was suggested that tunnel entry		section of [RFC2473] (Section 9), it was suggested that tunnel entry
	and exit points can be secured by securing the IPv6 path between		and exit points can be secured by securing the IPv6 path between
	them. This recommendation is not practical for RPL networks.		them. This recommendation is not practical for RPL networks.
	[RFC5406] goes into some detail on what additional details would be		[RFC5406] provides guidance on what on what additional details are
	needed in order to "Use IPsec". Use of Encapsulating Security		nedded in order to "Use IPsec". While the use of Encapsulating
	Payload (ESP) would prevent as defined in [RFC8138] (compression must		Security Payload (ESP) would prevent source address forgeries, in
	occur before encryption), and [RFC8138] compression is lossy in a way		order to use it with [RFC8138], compression would have to occur
	that prevents use of AH. These are minor issues. The major issue is		before encryption, as the [RFC8138] compression is lossy. Once
	how to establish trust enough such that Internet Key Exchange		encrypted, there would be no further redundancy to compress. These
	Protocol Version 2 (IKEv2) could be used. This would require a		are minor issues. The major issue is how to establish trust enough
	system of certificates to be present in every single node, including		such that Internet Key Exchange Protocol Version 2 (IKEv2) could be
	any Internet nodes that might need to communicate with the LLN.		used. This would require a system of certificates to be present in
	Thus, using IPsec requires a global PKI in the general case.		every single node, including any Internet nodes that might need to
			communicate with the LLN. Thus, using IPsec requires a global PKI in
			the general case.
	More significantly, the use of IPsec tunnels to protect the IPv6-in-		More significantly, the use of IPsec tunnels to protect the IPv6-in-
	IPv6 headers would, in the general case, scale with the square of the		IPv6 headers would, in the general case, scale with the square of the
	number of nodes. This is a lot of resources for a constrained nodes		number of nodes. This is a lot of resources for a constrained nodes
	on a constrained network. In the end, the IPsec tunnels would be		on a constrained network. In the end, the IPsec tunnels would be
	providing only BCP38-like origin authentication! That is, IPsec		providing only BCP38-like origin authentication! That is, IPsec
	provides a transitive guarantee to the tunnel exit point that the		provides a transitive guarantee to the tunnel exit point that the
	tunnel entry point did BCP38 on traffic going in. Just doing origin		tunnel entry point did network ingress filtering [BCP38] on traffic
	filtering per BCP 38 at the entry and exit of the LLN provides a		going in. Just doing origin filtering per BCP 38 at the entry and
	similar level of security without all the scaling and trust problems		exit of the LLN provides a similar level of security without all the
	related to IPv6 tunnels as discussed in [RFC2473]. IPsec is not		scaling and trust problems related to IPv6 tunnels as discussed in
	recommended.		[RFC2473]. IPsec is not recommended.
	An LLN with hostile nodes within it would not be protected against		An LLN with hostile nodes within it would not be protected against
	impersonation within the LLN by entry/exit filtering.		impersonation within the LLN by entry/exit filtering.
	The RH3 header usage described here can be abused in equivalent ways.		The RH3 header usage described here can be abused in equivalent ways.
	An external attacker may form a packet with an RH3 that is not fully		An external attacker may form a packet with an RH3 that is not fully
	consumed and encapsulate it to hide the RH3 from intermediate nodes		consumed and encapsulate it to hide the RH3 from intermediate nodes
	and disguise the origin of traffic. As such, the attacker's RH3		and disguise the origin of traffic. As such, the attacker's RH3
	header will not be seen by the network until it reaches the		header will not be seen by the network until it reaches the
	destination, which will decapsulate it. As indicated in Section 4.2		destination, which will decapsulate it. As indicated in Section 4.2
	skipping to change at line 2483 ¶		skipping to change at line 2485 ¶
	It could also be that not all nodes are reachable in an LLN using the		It could also be that not all nodes are reachable in an LLN using the
	default RPLInstanceID, but a change of RPLInstanceID would permit an		default RPLInstanceID, but a change of RPLInstanceID would permit an
	attacker to bypass such filtering. Like the RH3, an RPI is to be		attacker to bypass such filtering. Like the RH3, an RPI is to be
	inserted by the RPL root on traffic entering the LLN by first		inserted by the RPL root on traffic entering the LLN by first
	inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will		inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will
	not be seen by the network. Upon reaching the destination node, the		not be seen by the network. Upon reaching the destination node, the
	RPI has no further meaning and is just skipped; the presence of a		RPI has no further meaning and is just skipped; the presence of a
	second RPI will have no meaning to the end node as the packet has		second RPI will have no meaning to the end node as the packet has
	already been identified as being at its final destination.		already been identified as being at its final destination.
	For traffic leaving a RUL, if the RUL adds an opaque RPI, then the		For traffic leaving a RUL, if the RUL adds an uninitialized RPI
	6LR as a RPL Border Router SHOULD rewrite the RPI to indicate the		(e.g., with a value of zero), then the 6LR as a RPL Border Router
	selected Instance and set the flags. This is done in order to avoid		SHOULD rewrite the RPI to indicate the selected Instance and set the
	the following scenarios: 1) The leaf is an external router that		flags. This is done in order to avoid the following scenarios: 1)
	passes a packet that it did not generate and that carries an		The leaf is an external router that passes a packet that it did not
	unrelated RPI, and 2) The leaf is an attacker or presents		generate and that carries an unrelated RPI, and 2) The leaf is an
	misconfiguration and tries to inject traffic in a protected Instance.		attacker or presents misconfiguration and tries to inject traffic in
	Also, this applies to the case where the leaf is aware of the RPL		a protected Instance. Also, this applies to the case where the leaf
	Instance and passes a correct RPI; the 6LR needs a configuration that		is aware of the RPL Instance and passes a correct RPI; the 6LR needs
	allows that leaf to inject in that instance.		a configuration that allows that leaf to inject in that instance.
	The RH3 and RPIs could be abused by an attacker inside of the network		The RH3 and RPIs could be abused by an attacker inside of the network
	to route packets in nonobvious ways, perhaps eluding observation.		to route packets in nonobvious ways, perhaps eluding observation.
	This usage appears consistent with a normal operation of [RFC6997]		This usage appears consistent with a normal operation of [RFC6997]
	and cannot be restricted at all. This is a feature, not a bug.		and cannot be restricted at all. This is a feature, not a bug.
	[RFC7416] deals with many other threats to LLNs not directly related		[RFC7416] deals with many other threats to LLNs not directly related
	to the use of IPv6-in-IPv6 headers, and this document does not change		to the use of IPv6-in-IPv6 headers, and this document does not change
	that analysis.		that analysis.
	skipping to change at line 2527 ¶		skipping to change at line 2529 ¶
	LLN, IPv6-in-IPv6 can be used to hide inner routing headers, but by		LLN, IPv6-in-IPv6 can be used to hide inner routing headers, but by
	construction, the RH3 can typically only address nodes within the		construction, the RH3 can typically only address nodes within the
	LLN. That is, an RH3 with a CmprI less than 8 should be considered		LLN. That is, an RH3 with a CmprI less than 8 should be considered
	an attack (see Section 3 of [RFC6554]).		an attack (see Section 3 of [RFC6554]).
	Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic		Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic
	through the RPL root to perform this attack. To counter, the RPL		through the RPL root to perform this attack. To counter, the RPL
	root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the		root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the
	simpler solution), or it SHOULD walk the IP header extension chain		simpler solution), or it SHOULD walk the IP header extension chain
	until it can inspect the upper-layer payload as described in		until it can inspect the upper-layer payload as described in
	[RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing		[RFC7045]. In particular, the RPL root SHOULD do network ingress
	on the source addresses of all IP headers that it examines in both		filtering [BCP38] on the source addresses of all IP headers that it
	directions.		examines in both directions.
	Note: there are some situations where a prefix will spread across		Note: there are some situations where a prefix will spread across
	multiple LLNs via mechanisms such as the one described in [RFC8929].		multiple LLNs via mechanisms such as the one described in [RFC8929].
	In this case, the BCP38 filtering needs to take this into account,		In this case, the network ingress filtering [BCP38] needs to take
	either by exchanging detailed routing information on each LLN or by		this into account, either by exchanging detailed routing information
	moving the BCP38 filtering further towards the Internet, so that the		on each LLN or by moving the network ingress filtering [BCP38]
	details of the multiple LLNs do not matter.		further towards the Internet, so that the details of the multiple
			LLNs do not matter.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	<https://rfc-editor.org/info/bcp38>		<https://rfc-editor.org/info/bcp38>
	skipping to change at line 2724 ¶		skipping to change at line 2727 ¶
	dtsecurity-zerotouch-join-04, 8 July 2019,		dtsecurity-zerotouch-join-04, 8 July 2019,
	<https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-		<https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-
	zerotouch-join-04>.		zerotouch-join-04>.
	Acknowledgments		Acknowledgments
	This work is done thanks to the grant given by the StandICT.eu		This work is done thanks to the grant given by the StandICT.eu
	project.		project.
	A special BIG thanks to C. M. Heard for the help with Section 4.		A special BIG thanks to C. M. Heard for the help with Section 4.
	Much of the redaction in that section is based on his comments.		Much of the editing in that section is based on his comments.
	Additionally, the authors would like to acknowledge the review,		Additionally, the authors would like to acknowledge the review,
	feedback, and comments of the following (in alphabetical order):		feedback, and comments of the following (in alphabetical order):
	Dominique Barthel, Robert Cragie, Ralph Droms, Simon Duquennoy, Cenk		Dominique Barthel, Robert Cragie, Ralph Droms, Simon Duquennoy, Cenk
	Guendogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo		Guendogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo
	Mercado, Subramanian Moonesamy, Marcela Orbiscay, Cristian Perez,		Mercado, Subramanian Moonesamy, Marcela Orbiscay, Cristian Perez,
	Charlie Perkins, Alvaro Retana, Peter van der Stok, Xavier		Charlie Perkins, Alvaro Retana, Peter van der Stok, Xavier
	Vilajosana, Éric Vyncke, and Thomas Watteyne.		Vilajosana, Éric Vyncke, and Thomas Watteyne.
	Authors' Addresses		Authors' Addresses
End of changes. 45 change blocks.
	206 lines changed or deleted		209 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/