< draft-ietf-roll-useofrplinfo-27.txt		draft-ietf-roll-useofrplinfo-28.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 17, 2019 P. Thubert		Expires: November 18, 2019 P. Thubert
	Cisco		Cisco
	May 16, 2019		May 17, 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-27		draft-ietf-roll-useofrplinfo-28
	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 RFC 6553 (RPL Option Type), RFC 6554
	(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is		(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
	required in data plane. This analysis provides the basis on which to		required in data plane. This analysis provides the basis on which to
	design efficient compression of these headers. This document updates		design efficient compression of these headers. This document updates
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 17, 2019.		This Internet-Draft will expire on November 18, 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 15, line 15 ¶		skipping to change at page 15, line 15 ¶
	storing)		storing)
	not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing)		not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing)
	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]. Extensions headers may not be added or		outlined in [RFC8200]. Extensions headers may not be added or
	removed except by the sender or the receiver.		removed except by the sender or the receiver.
	However, unlike [RFC6553], the Hop-by-Hop Option Header used for the
	RPI artifact has the first two bits set to '00'. This means that the
	RPI artifact will be ignored when received by a host or router that
	does not understand that option ( Section 4.2 [RFC8200]).
	This means that when the no-drop RPI option code 0x23 is used, a
	packet that leaves the RPL domain of an LLN (or that leaves the LLN
	entirely) will not be discarded when it contains the [RFC6553] RPL
	Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option is
	left in place even if the end host does not understand it.
	NOTE: No clear attack has been described when the RPI information is
	released to the Internet. At a minimum, it is clear that the RPI
	option would waste some network bandwidth when it escapes. This is
	traded off against the savings in the LLN by not having to
	encapsulate the packet in order to remove the artifact. Please check
	the Security Considerations sections Section 11 for further details.
	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 RPI Option) MUST still encapsulate the packet in an (additional)		or RPI 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
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 10 ¶
	challenges, yet costed significant code and testing complexity. The		challenges, yet costed significant code and testing complexity. The
	ability to compress the RPI down to three bytes or less removes much		ability to compress the RPI down to three bytes or less removes much
	of the pressure to optimize this any further		of the pressure to optimize this any further
	[I-D.ietf-anima-autonomic-control-plane].		[I-D.ietf-anima-autonomic-control-plane].
	The earlier examples are more extensive to make sure that the process		The earlier examples are more extensive to make sure that the process
	is clear, while later examples are more concise.		is clear, while later examples are more concise.
	6. Storing mode		6. Storing mode
	In storing mode (fully stateful), the sender can determine if the		In storing mode (SM) (fully stateful), the sender can determine if
	destination is inside the LLN by looking if the destination address		the destination is inside the LLN by looking if the destination
	is matched by the DIO's Prefix Information Option (PIO) option.		address is matched by the DIO's Prefix Information Option (PIO)
			option.
	The following table (Figure 7) itemizes which headers are needed in		The following table (Figure 7) itemizes which headers are needed in
	each of the following scenarios. It indicates if the IPv6-in-IPv6		each of the following scenarios. It indicates if the IPv6-in-IPv6
	header that is added, must be addressed to the final destination (the		header that is added, must be addressed to the final destination (the
	Raf node that is the target(tgt)), to the "root" or if a hop-by-hop		Raf node that is the target(tgt)), to the "root" or if a hop-by-hop
	header must be added (indicated by "hop").		header must be added (indicated by "hop").
	In cases where no IPv6-in-IPv6 header is needed, the column states as		In cases where no IPv6-in-IPv6 header is needed, the column states as
	"No". If the IPv6-in-IPv6 header is needed is a "must".		"No". If the IPv6-in-IPv6 header is needed is a "must".
	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| -- |IPv6-in-IPv | -- |IPv6-in-IPv6| -- |		| Modified| -- |IP6-in-IP6| -- |IPv6-in-IPv6| -- |
	| 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		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)
	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 E --> Node G		Node B --> Node A (root) --> Node B --> Node E --> Node G
End of changes. 8 change blocks.
	47 lines changed or deleted		30 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/