< draft-ietf-roll-useofrplinfo-21.txt		draft-ietf-roll-useofrplinfo-22.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: August 14, 2018 P. Thubert		Expires: September 2, 2018 P. Thubert
	Cisco		Cisco
	February 10, 2018		March 1, 2018
	When to use RFC 6553, 6554 and IPv6-in-IPv6		When to use RFC 6553, 6554 and IPv6-in-IPv6
	draft-ietf-roll-useofrplinfo-21		draft-ietf-roll-useofrplinfo-22
	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. This document		to design efficient compression of these headers. This document
	updates RFC 6553 adding a change to the RPL Option Type.		updates RFC 6553 adding a change to the RPL Option Type.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 August 14, 2018.		This Internet-Draft will expire on September 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Requirements Language . . . . . . . . . . . . 4		2. Terminology and Requirements Language . . . . . . . . . . . . 4
	2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5		2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5
	3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5		3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5
	3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5		3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5
	3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 6		3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 7
	3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG		3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
	Configuration Option Flag. . . . . . . . . . . . . . . . 7		Configuration Option Flag. . . . . . . . . . . . . . . . 7
	4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8		4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8
	5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. Storing Mode: Interaction between Leaf and Root . . . . . 14		6.1. Storing Mode: Interaction between Leaf and Root . . . . . 14
	6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 15		6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 15
	6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 16		6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 16
	6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 16		6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 16
	6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 17		6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 17
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	that originates from a node to an adjacent node, using the addresses		that originates from a node to an adjacent node, using the addresses
	(usually the GUA or ULA, but could use the link-local addresses) of		(usually the GUA or ULA, but could use the link-local addresses) of
	each node. If the packet must traverse multiple hops, then it must		each node. If the packet must traverse multiple hops, then it must
	be decapsulated at each hop, and then re-encapsulated again in a		be decapsulated at each hop, and then re-encapsulated again in a
	similar fashion.		similar fashion.
	3. Updates to RFC6553, RFC6550 and RFC 8138		3. Updates to RFC6553, RFC6550 and RFC 8138
	3.1. Updates to RFC 6553		3.1. Updates to RFC 6553
			This modification is required to be able to send, for example, IPv6
			packets from a RPL-aware-leaf to a not-RPL-aware node through
			Internet (see Section 6.2.1), without requiring IP-in-IP
			encapsulation.
	[RFC6553] states as showed below, that in the Option Type field of		[RFC6553] states as showed below, that in the Option Type field of
	the RPL Option header, the two high order bits MUST be set to '01'		the RPL Option header, the two high order bits MUST be set to '01'
	and the third bit is equal to '1'. The first two bits indicate that		and the third bit is equal to '1'. The first two bits indicate that
	the IPv6 node MUST discard the packet if it doesn't recognize the		the IPv6 node MUST discard the packet if it doesn't recognize the
	option type, and the third bit indicates that the Option Data may		option type, and the third bit indicates that the Option Data may
	change en route. The remaining bits serve as the option type.		change en route. The remaining bits serve as the option type.
	Hex Value Binary Value		Hex Value Binary Value
	act chg rest Description Reference		act chg rest Description Reference
	--------- --- --- ------- ----------------- ----------		--------- --- --- ------- ----------------- ----------
	skipping to change at page 5, line 46 ¶		skipping to change at page 6, line 5 ¶
	intermediate nodes) is now optional, but if they are configured to		intermediate nodes) is now optional, but if they are configured to
	process the header, and if such nodes encounter an option with the		process the header, and if such nodes encounter an option with the
	first two bits set to 01, they will drop the packet (if they conform		first two bits set to 01, they will drop the packet (if they conform
	to [RFC8200]). Host systems should do the same, irrespective of the		to [RFC8200]). Host systems should do the same, irrespective of the
	configuration.		configuration.
	Based on That, if an IPv6 (intermediate) node (RPL-not-capable)		Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
	receives a packet with an RPL Option, it should ignore the HBH RPL		receives a packet with an RPL Option, it should ignore the HBH RPL
	option (skip over this option and continue processing the header).		option (skip over this option and continue processing the header).
			This is relevant, as we mentioned previously, in the case that we
			have a flow from RPL-aware-leaf to Internet (see Section 6.2.1).
	Thus, this document updates the Option Type field to: the two high		Thus, this document updates the Option Type field to: the two high
	order bits MUST be set to '00' and the third bit is equal to '1'.		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 over this		The first two bits indicate that the IPv6 node MUST skip over this
	option and continue processing the header ([RFC8200] Section 4.2) if		option and continue processing the header ([RFC8200] Section 4.2) if
	it doesn't recognize the option type, and the third bit continues to		it doesn't recognize the option type, and the third bit continues to
	be set to indicate that the Option Data may change en route. The		be set to indicate that the Option Data may change en route. The
	remaining bits serve as the option type and remain as 0x3. This		remaining bits serve as the option type and remain as 0x3. 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
	leaves the LLN entirely) will not be discarded when it contains the		leaves the LLN entirely) will not be discarded when it contains the
	[RFC6553] RPL Hop-by-Hop option known as RPI.		[RFC6553] RPL Hop-by-Hop option known as RPI.
	skipping to change at page 43, line 19 ¶		skipping to change at page 43, line 19 ¶
	[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 IPIP headers, and this document does not change that		to the use of IPIP headers, and this document does not change that
	analysis.		analysis.
	12. Acknowledgments		12. Acknowledgments
	This work is partially funded by the FP7 Marie Curie Initial Training		This work is partially funded by the FP7 Marie Curie Initial Training
	Network (ITN) METRICS project (grant agreement No. 607728).		Network (ITN) METRICS project (grant agreement No. 607728).
	The authors would like to acknowledge the review, feedback, and		A special BIG thanks to C. M. Heard for the help with the
	comments of (alphabetical order): Robert Cragie, Simon Duquennoy,		Section 3. Much of the redaction in that section is based on his
	Ralph Droms, Cenk Guendogan, C. M. Heard, Rahul Jadhav, Matthias		comments.
			Additionally, the authors would like to acknowledge the review,
			feedback, and comments of (alphabetical order): Robert Cragie, Simon
			Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias
	Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne.		Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 44, line 42 ¶		skipping to change at page 44, line 49 ¶
	13.2. Informative References		13.2. Informative References
	[DDOS-KREBS]		[DDOS-KREBS]
	Goodin, D., "Record-breaking DDoS reportedly delivered by		Goodin, D., "Record-breaking DDoS reportedly delivered by
	>145k hacked cameras", September 2016,		>145k hacked cameras", September 2016,
	<http://arstechnica.com/security/2016/09/botnet-of-145k-		<http://arstechnica.com/security/2016/09/botnet-of-145k-
	cameras-reportedly-deliver-internets-biggest-ddos-ever/>.		cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
	[I-D.ietf-6lo-backbone-router]		[I-D.ietf-6lo-backbone-router]
	Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-		Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
	backbone-router-05 (work in progress), January 2018.		backbone-router-06 (work in progress), February 2018.
	[I-D.ietf-6man-rfc6434-bis]		[I-D.ietf-6man-rfc6434-bis]
	Chown, T., Loughney, J., and T. Winters, "IPv6 Node		Chown, T., Loughney, J., and T. Winters, "IPv6 Node
	Requirements", draft-ietf-6man-rfc6434-bis-03 (work in		Requirements", draft-ietf-6man-rfc6434-bis-05 (work in
	progress), February 2018.		progress), February 2018.
	[I-D.ietf-6tisch-dtsecurity-secure-join]		[I-D.ietf-6tisch-dtsecurity-secure-join]
	Richardson, M., "6tisch Secure Join protocol", draft-ietf-		Richardson, M., "6tisch Secure Join protocol", draft-ietf-
	6tisch-dtsecurity-secure-join-01 (work in progress),		6tisch-dtsecurity-secure-join-01 (work in progress),
	February 2017.		February 2017.
	[I-D.ietf-anima-autonomic-control-plane]		[I-D.ietf-anima-autonomic-control-plane]
	Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic		Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
	Control Plane (ACP)", draft-ietf-anima-autonomic-control-		Control Plane (ACP)", draft-ietf-anima-autonomic-control-
	plane-13 (work in progress), December 2017.		plane-13 (work in progress), December 2017.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Behringer, M., Bjarnason,		Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
	S., and K. Watsen, "Bootstrapping Remote Secure Key		S., and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-09 (work in progress), October 2017.		keyinfra-11 (work in progress), February 2018.
	[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for		[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
	Renumbering an IPv6 Network without a Flag Day", RFC 4192,		Renumbering an IPv6 Network without a Flag Day", RFC 4192,
	DOI 10.17487/RFC4192, September 2005,		DOI 10.17487/RFC4192, September 2005,
	<https://www.rfc-editor.org/info/rfc4192>.		<https://www.rfc-editor.org/info/rfc4192>.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", STD 89,		Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,		RFC 4443, DOI 10.17487/RFC4443, March 2006,
End of changes. 11 change blocks.
	11 lines changed or deleted		23 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/