< draft-ietf-roll-useofrplinfo-28.txt		draft-ietf-roll-useofrplinfo-29.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Aalto		Internet-Draft 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: November 18, 2019 P. Thubert		Expires: November 21, 2019 P. Thubert
	Cisco		Cisco
	May 17, 2019		May 20, 2019
	Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6		Using RPL 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-28		draft-ietf-roll-useofrplinfo-29
	Abstract		Abstract
	This document looks at different data flows through LLN (Low-Power		This document looks at different data flows through LLN (Low-Power
	and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power		and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
	and Lossy Networks) is used to establish routing. The document		and Lossy Networks) is used to establish routing. The document
	enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554		enumerates the cases where RFC6553 (RPL 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
	RFC 6553 adding a change to the RPL Option Type. Additionally, this		RFC6553 adding a change to the RPL Option Type. Additionally, this
	document updates RFC 6550 defining a flag in the DIO Configuration		document updates RFC6550 defining a flag in the DIO Configuration
	Option to indicate about this change and updates RFC8138 as well to		Option to indicate about this change and updates RFC8138 as well to
	consider the new Option Type when the RPL Option is decompressed.		consider the new Option Type when the RPL Option is decompressed.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 18, 2019.		This Internet-Draft will expire on November 21, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 47		11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
	13.1. Normative References . . . . . . . . . . . . . . . . . . 50		13.1. Normative References . . . . . . . . . . . . . . . . . . 50
	13.2. Informative References . . . . . . . . . . . . . . . . . 51		13.2. Informative References . . . . . . . . . . . . . . . . . 51
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
	1. Introduction		1. Introduction
	RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)		RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
	[RFC6550] is a routing protocol for constrained networks. RFC 6553		[RFC6550] is a routing protocol for constrained networks. RFC6553
	[RFC6553] defines the "RPL option" (RPL Packet Information or RPI),		[RFC6553] defines the "RPL option" (RPL Packet Information or RPI),
	carried within the IPv6 Hop-by-Hop header to quickly identify		carried within the IPv6 Hop-by-Hop header to quickly identify
	inconsistencies (loops) in the routing topology. RFC 6554 [RFC6554]		inconsistencies (loops) in the routing topology. RFC6554 [RFC6554]
	defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header		defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header
	to deliver datagrams within a RPL routing domain, particularly in		to deliver datagrams within a RPL routing domain, particularly in
	non-storing mode.		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		networks; they do not in general appear on the RPL control plane
	traffic at all which is mostly hop-by-hop traffic (one exception		traffic at all which is mostly hop-by-hop traffic (one exception
	being DAO messages in non-storing mode).		being DAO messages in non-storing mode).
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	considerations of supporting not-RPL-aware-leaves. Section 9 depicts		considerations of supporting not-RPL-aware-leaves. Section 9 depicts
	operational considerations for the proposed change on RPL Option		operational considerations for the proposed change on RPL Option
	type, section 10 the IANA considerations and then section 11		type, section 10 the IANA considerations and then section 11
	describes the security aspects.		describes the security aspects.
	2. Terminology and Requirements Language		2. Terminology and Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119], [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Terminology defined in [RFC7102] applies to this document: LBR, LLN,		Terminology defined in [RFC7102] applies to this document: LBR, LLN,
	RPL, RPL Domain and ROLL.		RPL, RPL Domain and ROLL.
	RPL-node: A device which implements RPL, thus the device is RPL-		RPL-node: A device which implements RPL, thus the device is RPL-
	aware. Please note that the device can be found inside the LLN or		aware. Please note that the device can be found inside the LLN or
	outside LLN. In this document a RPL-node which is a leaf of a		outside LLN. In this document a RPL-node which is a leaf of a
	(Destination Oriented Directed Acyclic Graph) DODAG is called RPL-		(Destination Oriented Directed Acyclic Graph) DODAG is called RPL-
	aware-leaf (Raf).		aware-leaf (Raf).
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	encapsulation.		encapsulation.
	[RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in		[RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in
	the Option Type field of the RPL Option header, the two high order		the Option Type field of the RPL Option header, the two high order
	bits must be set to '01' and the third bit is equal to '1'. The		bits must be set to '01' and the third bit is equal to '1'. The
	first two bits indicate that the IPv6 node must discard the packet if		first two bits indicate that the IPv6 node must discard the packet if
	it doesn't recognize the option type, and the third bit indicates		it doesn't recognize the option type, and the third bit indicates
	that the Option Data may change in route. The remaining bits serve		that the Option Data may change in route. The remaining bits serve
	as the option type.		as the option type.
	Hex Value Binary Value		+-------+-------------------+----------------+-----------+
	act chg rest Description Reference		| Hex | Binary Value | Description | Reference |
	--------- --- --- ------- ----------------- ----------		+ Value +-------------------+ + +
	0x63 01 1 00011 RPL Option [RFC6553]		| | act | chg | rest | | |
			+-------+-----+-----+-------+----------------+-----------+
			| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |
			+-------+-----+-----+-------+----------------+-----------+
	Figure 2: Option Type in RPL Option.		Figure 2: Option Type in RPL Option.
	This document illustrates that is is not always possible to know for		This document illustrates that is is not always possible to know for
	sure at the source that a packet will only travel within the RPL		sure at the source that a packet will only travel within the RPL
	domain or may leave it.		domain or may 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 header in
	the outer IPv6 header chain could potentially impact core routers in		the outer IPv6 header chain could potentially impact core routers in
	the internet. So at that time, it was decided to encapsulate any		the internet. So at that time, it was decided to encapsulate any
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 36 ¶
	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 an 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 RPL-aware-leaf to Internet (see		the case that there is a flow from RPL-aware-leaf to Internet (see
	Section 6.2.1).		Section 6.2.1).
	This is a significant update to [RFC6553].		This is a significant update to [RFC6553].
	Hex Value Binary Value		+-------+-------------------+-------------+------------+
	act chg rest Description Reference		| Hex | Binary Value | Description | Reference |
	--------- --- --- ------- ----------------- ----------		+ Value +-------------------+ + +
	0x23 00 1 00011 RPL Option [RFCXXXX]		| | act | chg | rest | | |
			+-------+-----+-----+-------+-------------+------------+
			| 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)|
			+-------+-----+-----+-------+-------------+------------+
	Figure 3: Revised Option Type in RPL Option.		Figure 3: Revised Option Type in RPL Option. (*)represents this
			document
	Without the signaling described below, this change would otherwise		Without the signaling described below, this change would otherwise
	create a flag day for existing networks which are currently using		create a flag day for existing networks which are currently using
	0x63 as the RPI value. A move to 0x23 will not be understood by		0x63 as the RPI value. A move to 0x23 will not be understood by
	those networks. It is suggested that implementations accept both		those networks. It is suggested that implementations accept both
	0x63 and 0x23 when processing.		0x63 and 0x23 when processing.
	When forwarding packets, implementations SHOULD use the same value as		When forwarding packets, implementations SHOULD use the same value as
	it was received (This is required because, RPI type code can not be		it was received (This is required because, RPI type code can not be
	changed by [RFC8200]). It allows to the network to be incrementally		changed by [RFC8200]). It allows to the network to be incrementally
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	3.2. Updates to RFC6550: Indicating the new RPI in the DODAG		3.2. Updates to RFC6550: Indicating the new RPI in the DODAG
	Configuration Option Flag.		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
	new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag		new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag
	in the DIO Configuration Option, to indicate when then new RPI value		in the DIO Configuration Option, to indicate when then new RPI value
	can be safely used. This means, the flag is going to indicate the		can be safely used. This means, the flag is going to indicate the
	type of RPI that the network is using. Thus, when a node join to a		type of RPI that the network is using. Thus, when a node join to a
	network will know which value to use. With this, RPL-capable nodes		network will know which value to use. With this, RPL-capable nodes
	know if it is safe to use 0x23 when creating a new RPI. A node that		know if it is safe to use 0x23 when creating a new RPI. A node that
	forwards a packet with an RPI MUST not modify the option type of the		forwards a packet with an RPI MUST NOT modify the option type of the
	RPI.		RPI.
	This is done via a DODAG Configuration Option flag which will		This is done via a DODAG Configuration Option flag which will
	propagate through the network. If the flag is received with a value		propagate through the network. If the flag is received with a value
	zero (which is the default), then new nodes will remain in RFC6553		zero (which is the default), then new nodes will remain in RFC6553
	Compatible Mode; originating traffic with the old-RPI (0x63) value.		Compatible Mode; originating traffic with the old-RPI (0x63) value.
	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
	configuration information. It is generally static, and does not		configuration information. It is generally static, and does not
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 5 ¶
	When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),		When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),
	the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6		the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6
	header. The IPv6-in-IPv6 header can be addressed to the next hop		header. The IPv6-in-IPv6 header can be addressed to the next hop
	(Node B), or to the root (Node A). The root removes the header and		(Node B), or to the root (Node A). The root removes the header and
	processes the packet.		processes the packet.
	The Figure 8 shows the table that summarizes what headers are needed		The Figure 8 shows the table that summarizes what headers are needed
	for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.		for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst |		| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst |
	| | src | | | |		| | src | | | |
	| | node | | | |		| | node | | | |
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	| Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- |		| Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	| Removed | -- | -- | -- | IP6-IP6(RPI)[1][2] |		| Removed | -- | -- | -- |IP6-IP6(RPI)[1][2]|
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	| Re-added | -- | -- | IP6-IP6(RPI)[1] | -- |		| Re-added | -- | -- | IP6-IP6(RPI)[1] | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	| Modified | -- | -- | IP6-IP6(RPI)[2] | -- |		| Modified | -- | -- | IP6-IP6(RPI)[2] | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+------+--------------+-----------------+--------------------+		+-----------+------+--------------+-----------------+------------------+
	Figure 8: Storing mode: Summary of the use of headers from not-RPL-		Figure 8: Storing mode: Summary of the use of headers from not-RPL-
	aware-leaf to root. [[1] Case where the IPv6-in-IPv6 header is		aware-leaf to root. [1] Case where the IPv6-in-IPv6 header is
	addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6		addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6
	header is addressed to the root (Node A).		header is addressed to the root (Node A).
	6.2. Storing Mode: Interaction between Leaf and Internet.		6.2. Storing Mode: 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,
	RPL-aware-leaf to Internet		RPL-aware-leaf to Internet
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	When the packet arrives from Internet to 6LBR the RPI header is added		When the packet arrives from Internet to 6LBR the RPI header is added
	in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination		in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination
	address set to the 6LR) and sent to 6LR, which modifies the rank in		address set to the 6LR) and sent to 6LR, which modifies the rank in
	the RPI. When the packet arrives at 6LN the RPI header is removed		the RPI. When the packet arrives at 6LN the RPI header is removed
	and the packet processed.		and the packet processed.
	The Figure 9 shows the table that summarizes what headers are needed		The Figure 9 shows the table that summarizes what headers are needed
	for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.		for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	| Header | Internet | 6LBR | 6LR_i | 6LN dst |		| Header | Internet | 6LBR | 6LR_i | 6LN dst |
	| | src | | | |		| | src | | | |
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	| Inserted | -- | IP6-IP6(RPI) | -- | -- |		| Inserted | -- | IP6-IP6(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	| Removed | -- | -- | -- | IP6-IP6(RPI) |		| Removed | -- | -- | -- | IP6-IP6(RPI) |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	| Modified | -- | -- | IP6-IP6(RPI) | -- |		| Modified | -- | -- | IP6-IP6(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+-----------+----------+--------------+--------------+------------------+		+-----------+----------+--------------+--------------+--------------+
	Figure 9: Storing mode: Summary of the use of headers from Internet		Figure 9: Storing mode: Summary of the use of headers from Internet
	to RPL-aware-leaf.		to RPL-aware-leaf.
	6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet		6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->		not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
	Internet		Internet
	skipping to change at page 28, line 25 ¶		skipping to change at page 28, line 25 ¶
	from the common parent (6LR_x) to destination 6LN.		from the common parent (6LR_x) to destination 6LN.
	The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node		The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node
	(Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6		(Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6
	header. The IPv6-in-IPv6 header is addressed to the destination 6LN		header. The IPv6-in-IPv6 header is addressed to the destination 6LN
	(Node F).		(Node F).
	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. In the figure, IP6-IP6 refers to IPv6-in-IPv6.		for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	| Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN |		| Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN |
	| |src | | Parent | | dst |		| |src | | Parent | | dst |
	| |node | | (6LRx) | | |		| |node | | (6LRx) | | |
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	| Inserted | -- | IP6-IP6(RPI) | -- | -- | -- |		| Inserted| -- |IP6-IP6(RPI)| -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	| Removed | -- | -- | -- | -- |IP6-IP6(RPI)|		| Removed | -- | -- | -- | -- |IP6-IP6(RPI)|
	| headers | | | | | |		| headers | | | | | |
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	| Re-added | -- | -- | -- | -- | -- |		| Re-added| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	| Modified | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- |		| Modified| -- | -- |IP6-IP6(RPI) |IP6-IP6(RPI) | -- |
	| headers | | | | | |		| headers | | | | | |
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	|Untouched | -- | -- | -- | -- | -- |		|Untouched| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+----------+-----+--------------+--------------+--------------+------------+		+---------+-----+------------+-------------+-------------+------------+
	Figure 12: Storing mode: Summary of the use of headers from not-RPL-		Figure 12: Storing mode: Summary of the use of headers from not-RPL-
	aware-leaf to RPL-aware-leaf.		aware-leaf to RPL-aware-leaf.
	6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware-		6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
	leaf		leaf
	In this case the flow comprises:		In this case the flow comprises:
	not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id		not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id
	skipping to change at page 35, line 5 ¶		skipping to change at page 35, line 5 ¶
	6LR_1 (i=1) is the router that receives the packets from the IPv6		6LR_1 (i=1) is the router that receives the packets from the IPv6
	node.		node.
	In this case the RPI is added by the first 6LR (6LR1) (Node E),		In this case the RPI is added by the first 6LR (6LR1) (Node E),
	encapsulated in an IPv6-in-IPv6 header, and is modified in the		encapsulated in an IPv6-in-IPv6 header, and is modified in the
	following 6LRs. The RPI and entire packet is consumed by the root.		following 6LRs. The RPI and entire packet is consumed by the root.
	The Figure 16 shows the table that summarizes what headers are needed		The Figure 16 shows the table that summarizes what headers are needed
	for this use case.		for this use case.
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst |		| Header |IPv6| 6LR_1 | 6LR_i | 6LBR dst |
	| | src | | | |		| |src | | | |
	| | node | | | |		| |node| | | |
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	| Inserted | -- | IPv6-in-IPv6(RPI) | -- | -- |		| Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- |
	| headers | | | | |		| headers | | | | |
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	| Removed | -- | -- | -- |IPv6-in-IPv6(RPI)|		| Removed | -- | -- | -- |IPv6-in-IPv6(RPI)|
	| headers | | | | |		| headers | | | | |
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	| Re-added | -- | -- | -- | -- |		| Re-added| -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	| Modified | -- | -- | IPv6-in-IPv6(RPI)| -- |		| Modified| -- | -- |IPv6-in-IPv6(RPI)| -- |
	| headers | | | | |		| headers | | | | |
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	|Untouched | -- | -- | -- | -- |		|Untouched| -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+----------+------+-------------------+------------------+-----------------+		+---------+----+-----------------+-----------------+-----------------+
	Figure 16: Non Storing mode: Summary of the use of headers from not-		Figure 16: Non Storing mode: Summary of the use of headers from not-
	RPL-aware-leaf to root		RPL-aware-leaf to root
	7.2. Non-Storing Mode: Interaction between Leaf and Internet		7.2. Non-Storing Mode: Interaction between Leaf and Internet
	This section will describe the communication flow in Non Storing Mode		This section will describe the communication flow in Non Storing Mode
	(Non-SM) between:		(Non-SM) between:
	RPL-aware-leaf to Internet		RPL-aware-leaf to Internet
	skipping to change at page 38, line 5 ¶		skipping to change at page 38, line 5 ¶
	In this case the flow label is recommended to be zero in the IPv6		In this case the flow label is recommended to be zero in the IPv6
	node. As RPL headers are added in the IPv6 node packet, the first		node. As RPL headers are added in the IPv6 node packet, the first
	6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header.		6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header.
	The IPv6-in-IPv6 header will be addressed to the root. This case is		The IPv6-in-IPv6 header will be addressed to the root. This case is
	identical to the storing-mode case (see Section 6.2.3).		identical to the storing-mode case (see Section 6.2.3).
	The Figure 17 shows the table that summarizes what headers are needed		The Figure 17 shows the table that summarizes what headers are needed
	for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.		for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet |		| Header |IPv6| 6LR_1 | 6LR_i | 6LBR |Internet|
	| | src | | [i=2,..,n] | | dst |		| |src | | [i=2,..,n] | | dst |
	| | node | | | | |		| |node| | | | |
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	| Inserted | -- | IP6-IP6(RPI) | -- | -- | -- |		| Inserted| -- |IP6-IP6(RPI) | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	| Removed | -- | -- | -- | IP6-IP6(RPI) | -- |		| Removed | -- | -- | -- | IP6-IP6(RPI) | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	| Re-added | -- | -- | -- | -- | -- |		| Re-added| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	| Modified | -- | -- | IP6-IP6(RPI) | -- | -- |		| Modified| -- | -- | IP6-IP6(RPI) | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	| Untouched | -- | -- | -- | -- | -- |		|Untouched| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+------+--------------+--------------+--------------+----------+		+---------+----+-------------+--------------+--------------+--------+
	Figure 17: Non Storing mode: Summary of the use of headers from not-		Figure 17: Non Storing mode: Summary of the use of headers from not-
	RPL-aware-leaf to Internet		RPL-aware-leaf to Internet
	7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf		7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)		Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
	skipping to change at page 39, line 5 ¶		skipping to change at page 39, line 5 ¶
	The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The		The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The
	6LBR will know the path, and will recognize that the final node is		6LBR will know the path, and will recognize that the final node is
	not an RPL capable node as it will have received the connectivity DAO		not an RPL capable node as it will have received the connectivity DAO
	from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6		from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6
	header destination be the last 6LR. The 6LBR will set to zero the		header destination be the last 6LR. The 6LBR will set to zero the
	flow label upon entry in order to aid compression.		flow label upon entry in order to aid compression.
	The Figure 18 shows the table that summarizes what headers are needed		The Figure 18 shows the table that summarizes what headers are needed
	for this use case.		for this use case.
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	| Header |Internet| 6LBR | 6LR_1 | 6lR_i | IPv6 |		| Header |Internet| 6LBR | 6LR_1 | 6lR_i |IPv6 |
	| | src | | | (i=2,...,n) | dst |		| | src | | | (i=2,...,n) |dst |
	| | | | | | node |		| | | | | |node |
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	| Inserted | -- | IPv6-in-IPv6 | -- | -- | -- |		| Inserted| -- | IPv6-in-IPv6| -- | -- | -- |
	| headers | | (RH3,RPI) | | | |		| headers | | (RH3,RPI) | | | |
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	| Removed | -- | -- | -- | IPv6-in-IPv6 | -- |		| Removed | -- | -- | -- | IPv6-in-IPv6 | -- |
	| headers | | | | (RH3,RPI)[1] | |		| headers | | | | (RH3,RPI)[1] | |
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	| Re-added | -- | -- | -- | -- | -- |		| Re-added| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	| Modified | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- |		| Modified| -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- |
	| headers | | | (RH3,RPI) | (RH3,RPI) | |		| headers | | | (RH3,RPI) | (RH3,RPI) | |
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	| Untouched | -- | -- | -- | -- | -- |		|Untouched| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+-----------+--------+--------------+--------------+--------------+------+		+---------+--------+-------------+--------------+--------------+-----+
	Figure 18: Non-Storing mode: Summary of the use of headers from		Figure 18: Non-Storing mode: Summary of the use of headers from
	Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node.		Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node.
	7.3. Non-Storing Mode: Interaction between Leafs		7.3. Non-Storing Mode: Interaction between Leafs
	In this section is described the communication flow in Non Storing		In this section is described the communication flow in Non Storing
	Mode (Non-SM) between,		Mode (Non-SM) between,
	RPL-aware-leaf to RPL-aware-leaf		RPL-aware-leaf to RPL-aware-leaf
	skipping to change at page 41, line 5 ¶		skipping to change at page 41, line 5 ¶
	Otherwise, there may be a RPI header buried inside the inner IP		Otherwise, there may be a RPI header buried inside the inner IP
	header, which should get ignored.		header, which should get ignored.
	Networks that use the RPL P2P extension [RFC6997] are essentially		Networks that use the RPL P2P extension [RFC6997] are essentially
	non-storing DODAGs and fall into this scenario or scenario		non-storing DODAGs and fall into this scenario or scenario
	Section 7.1.2, with the originating node acting as 6LBR.		Section 7.1.2, with the originating node acting as 6LBR.
	The Figure 19 shows the table that summarizes what headers are needed		The Figure 19 shows the table that summarizes what headers are needed
	for this use case.		for this use case.
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	| Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN |		| Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN |
	| | src | | | | dst |		| | src | | | | dst |
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	| Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- |		| Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- |
	| headers | (RPI1) | |(RH3-> 6LN, | | |		| headers | (RPI1) | |(RH3-> 6LN, | | |
	| | | | RPI2) | | |		| | | | RPI2) | | |
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	| Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6|		| Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6|
	| headers | | | (RPI1) | | (RH3, |		| headers | | | (RPI1) | | (RH3, |
	| | | | | | RPI2) |		| | | | | | RPI2) |
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	| Re-added| -- | -- | -- | -- | -- |		| Re-added| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	| Modified| -- |IP6-in-IP6| -- |IPv6-in-IPv6| -- |		| Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- |
	| headers | | (RPI1) | | (RPI2) | |		| headers | | (RPI1) | | (RPI2) | |
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	|Untouched| -- | -- | -- | -- | -- |		|Untouched| -- | -- | -- | -- | -- |
	| headers | | | | | |		| headers | | | | | |
	+---------+------------+----------+------------+------------+------------+		+---------+------------+----------+------------+----------+------------+
	Figure 19: Non Storing mode: Summary of the use of headers for RPL-		Figure 19: Non Storing mode: Summary of the use of headers for RPL-
	aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6.		aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6.
	7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-		7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-
	leaf		leaf
	In this case the flow comprises:		In this case the flow comprises:
	6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6)		6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6)
	skipping to change at page 46, line 33 ¶		skipping to change at page 46, line 33 ¶
	new RPI in the DODAG Configuration Option Flag is a way to avoid the		new RPI in the DODAG Configuration Option Flag is a way to avoid the
	flag day in a network. It is recommended that a network process both		flag day in a network. It is recommended that a network process both
	options to enable interoperability.		options to enable interoperability.
	10. IANA Considerations		10. 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 23.		Figure 23.
	[RFCXXXX] represents this document.		+-------+-------------------+------------------------+---------- -+
			| Hex | Binary Value | Description | Reference |
	Hex Value Binary Value		+ Value +-------------------+ + +
	act chg rest Description Reference		| | act | chg | rest | | |
	--------- --- --- ------- ----------------- ----------		+-------+-----+-----+-------+------------------------+------------+
	0x23 00 1 00011 RPL Option [RFCXXXX]		| 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)|
	0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX]		+-------+-----+-----+-------+------------------------+------------+
			| 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] |
			| | | | | |[RFCXXXX](*)|
			+-------+-----+-----+-------+------------------------+------------+
	Figure 23: Option Type in RPL Option.		Figure 23: Option Type in RPL Option.(*)represents this document
	DODAG Configuration option is updated as follows (Figure 24):		DODAG Configuration option is updated as follows (Figure 24):
	+------------+-----------------+---------------+		+------------+-----------------+---------------+
	| Bit number | Description | Reference |		| Bit number | Description | Reference |
	+------------+-----------------+---------------+		+------------+-----------------+---------------+
	| 3 | RPI 0x23 enable | This document |		| 3 | RPI 0x23 enable | This document |
	+------------+-----------------+---------------+		+------------+-----------------+---------------+
	Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag-		Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag-
End of changes. 23 change blocks.
	169 lines changed or deleted		179 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/