< draft-ietf-roll-useofrplinfo-18.txt		draft-ietf-roll-useofrplinfo-19.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Ericsson		Internet-Draft Ericsson
	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: May 2, 2018 P. Thubert		Expires: May 3, 2018 P. Thubert
	Cisco		Cisco
	October 29, 2017		October 30, 2017
	When to use RFC 6553, 6554 and IPv6-in-IPv6		When to use RFC 6553, 6554 and IPv6-in-IPv6
	draft-ietf-roll-useofrplinfo-18		draft-ietf-roll-useofrplinfo-19
	Abstract		Abstract
	This document looks at different data flows through LLN (Low-Power		This document looks at different data flows through LLN (Low-Power
	and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power		and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
	and Lossy Networks) is used to establish routing. The document		and Lossy Networks) is used to establish routing. The document
	enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6		enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
	encapsulation is required. This analysis provides the basis on which		encapsulation is required. This analysis provides the basis on which
	to design efficient compression of these headers. Additionally, this		to design efficient compression of these headers. Additionally, this
	document updates the RFC 6553 adding a change to the RPL Option Type		document updates the RFC 6553 adding a change to the RPL Option Type
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 May 2, 2018.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	This change creates a flag day for existing networks which are		This change creates a flag day for existing networks which are
	currently using 0x63 as the RPI value. A move to 0x23 will not be		currently using 0x63 as the RPI value. A move to 0x23 will not be
	understood by those networks. It is suggested that implementations		understood by those networks. It is suggested that implementations
	accept both 0x63 and 0x23 when processing. When forwarding packets,		accept both 0x63 and 0x23 when processing. When forwarding packets,
	implementations SHOULD use the same value as it was received. When		implementations SHOULD use the same value as it was received. When
	originating new packets, implementations SHOULD have an option to		originating new packets, implementations SHOULD have an option to
	determine which value to originate with, this option is controlled by		determine which value to originate with, this option is controlled by
	the DIO option described below.		the DIO option described below.
	A network which is switching from straight 6lowpan compression		A network which is switching from straight 6lowpan compression
	mechanism to those described in [RFC8183] will experience a flag day		mechanism to those described in [RFC8138] will experience a flag day
	in the data compression anyway, and if possible this change can be		in the data compression anyway, and if possible this change can be
	deployed at the same time.		deployed at the same time.
	3.2. Updates to RFC 8138		3.2. Updates to RFC 8138
	RPI-6LoRH header provides a compressed form for the RPL RPI		RPI-6LoRH header provides a compressed form for the RPL RPI
	[RFC8138]. It should be considered when the Option Type in RPL		[RFC8138]. It should be considered when the Option Type in RPL
	Option is decompressed, should take the value of 0x23 instead of		Option is decompressed, should take the value of 0x23 instead of
	0x63.		0x63.
	skipping to change at page 37, line 49 ¶		skipping to change at page 37, line 49 ¶
	| headers | | | | | |		| headers | | | | | |
	+------------+-------+-----------+------------+-------------+-------+		+------------+-------+-----------+------------+-------------+-------+
	Non Storing: Summary of the use of headers from not-RPL-aware-leaf to		Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
	not-RPL-aware-leaf		not-RPL-aware-leaf
	8. Observations about the cases		8. Observations about the cases
	8.1. Storing mode		8.1. Storing mode
	[RFC8183] shows that the hop-by-hop IP-in-IP header can be compressed		[RFC8138] shows that the hop-by-hop IP-in-IP header can be compressed
	using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header as described in		using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header as described in
	Section 7 of the document.		Section 7 of the document.
	There are potential significant advantages to having a single code		There are potential significant advantages to having a single code
	path that always processes IP-in-IP headers with no options.		path that always processes IP-in-IP headers with no options.
	Thanks to the change of the RPI option type from 0x63 to 0x23, there		Thanks to the change of the RPI option type from 0x63 to 0x23, there
	is no longer any uncertainty about when to use an IP-in-IP header in		is no longer any uncertainty about when to use an IP-in-IP header in
	the storing mode. A Hop-by-Hop Options Header containing the RPI		the storing mode. A Hop-by-Hop Options Header containing the RPI
	option SHOULD always be added when 6LRs originate packets (without		option SHOULD always be added when 6LRs originate packets (without
	skipping to change at page 38, line 36 ¶		skipping to change at page 38, line 36 ¶
	node. This means that the non-storing mode case can avoid ever using		node. This means that the non-storing mode case can avoid ever using
	hop-by-hop IP-in-IP headers for traffic originating from the root to		hop-by-hop IP-in-IP headers for traffic originating from the root to
	leafs.		leafs.
	The non-storing mode case does not require the type change from 0x63		The non-storing mode case does not require the type change from 0x63
	to 0x23, as the root can always create the right packet. The type		to 0x23, as the root can always create the right packet. The type
	change does not adversely affect the non-storing case.		change does not adversely affect the non-storing case.
	9. 6LoRH Compression cases		9. 6LoRH Compression cases
	The [RFC8183] proposes a compression method for RPI, RH3 and IPv6-in-		The [RFC8138] proposes a compression method for RPI, RH3 and IPv6-in-
	IPv6.		IPv6.
	In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-		In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-
	RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise		RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
	an IP-in-IP and RPI compression headers. The type of this case is		an IP-in-IP and RPI compression headers. The type of this case is
	critical since IP-in-IP is encapsulating a RPI header.		critical since IP-in-IP is encapsulating a RPI header.
	+--+-----+---+--------------+-----------+-------------+-------------+		+--+-----+---+--------------+-----------+-------------+-------------+
	|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |		|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
	+--+-----+---+--------------+-----------+-------------+-------------+		+--+-----+---+--------------+-----------+-------------+-------------+
	skipping to change at page 41, line 22 ¶		skipping to change at page 41, line 22 ¶
	would be cheaper should RPL be run in an environment where hostile		would be cheaper should RPL be run in an environment where hostile
	nodes are likely to be a part of the LLN.		nodes are likely to be a part of the LLN.
	The RH3 header usage described here can be abused in equivalent ways		The RH3 header usage described here can be abused in equivalent ways
	with an IPIP header to add the needed RH3 header. As such, the		with an IPIP header to add the needed RH3 header. As such, the
	attacker's RH3 header will not be seen by the network until it		attacker's RH3 header will not be seen by the network until it
	reaches the end host, which will decapsulate it. An end-host SHOULD		reaches the end host, which will decapsulate it. An end-host SHOULD
	be suspicious about a RH3 header which has additional hops which have		be suspicious about a RH3 header which has additional hops which have
	not yet been processed, and SHOULD ignore such a second RH3 header.		not yet been processed, and SHOULD ignore such a second RH3 header.
	In addition, the LLN will likely use [RFC8183] to compress the IPIP		In addition, the LLN will likely use [RFC8138] to compress the IPIP
	and RH3 headers. As such, the compressor at the RPL-root will see		and RH3 headers. As such, the compressor at the RPL-root will see
	the second RH3 header and MAY choose to discard the packet if the RH3		the second RH3 header and MAY choose to discard the packet if the RH3
	header has not been completely consumed. A consumed (inert) RH3		header has not been completely consumed. A consumed (inert) RH3
	header could be present in a packet that flows from one LLN, crosses		header could be present in a packet that flows from one LLN, crosses
	the Internet, and enters another LLN. As per the discussion in this		the Internet, and enters another LLN. As per the discussion in this
	document, such headers do not need to be removed. However, there is		document, such headers do not need to be removed. However, there is
	no case described in this document where an RH3 is inserted in a non-		no case described in this document where an RH3 is inserted in a non-
	storing network on traffic that is leaving the LLN, but this document		storing network on traffic that is leaving the LLN, but this document
	SHOULD NOT preclude such a future innovation. It should just be		SHOULD NOT preclude such a future innovation. It should just be
	noted that an incoming RH3 must be fully consumed, or very carefully		noted that an incoming RH3 must be fully consumed, or very carefully
	skipping to change at page 45, line 15 ¶		skipping to change at page 45, line 15 ¶
	[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and		[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
	J. Martocci, "Reactive Discovery of Point-to-Point Routes		J. Martocci, "Reactive Discovery of Point-to-Point Routes
	in Low-Power and Lossy Networks", RFC 6997,		in Low-Power and Lossy Networks", RFC 6997,
	DOI 10.17487/RFC6997, August 2013,		DOI 10.17487/RFC6997, August 2013,
	<https://www.rfc-editor.org/info/rfc6997>.		<https://www.rfc-editor.org/info/rfc6997>.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January		Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
	2014, <https://www.rfc-editor.org/info/rfc7102>.		2014, <https://www.rfc-editor.org/info/rfc7102>.
	[RFC8183] Austein, R., "An Out-of-Band Setup Protocol for Resource
	Public Key Infrastructure (RPKI) Production Services",
	RFC 8183, DOI 10.17487/RFC8183, July 2017,
	<https://www.rfc-editor.org/info/rfc8183>.
	[Second6TischPlugtest]		[Second6TischPlugtest]
	"2nd 6Tisch Plugtest", <http://www.ietf.org/mail-		"2nd 6Tisch Plugtest", <http://www.ietf.org/mail-
	archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>.		archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>.
	Authors' Addresses		Authors' Addresses
	Maria Ines Robles		Maria Ines Robles
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
End of changes. 9 change blocks.
	13 lines changed or deleted		8 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/