< draft-ietf-roll-useofrplinfo-16.txt		draft-ietf-roll-useofrplinfo-17.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 6553, 6550 (if approved) M. Richardson		Updates: 6553, 6550, 8138 (if approved) M. Richardson
	Intended status: Standards Track SSW		Intended status: Standards Track SSW
	Expires: January 4, 2018 P. Thubert		Expires: April 30, 2018 P. Thubert
	Cisco		Cisco
	July 3, 2017		October 27, 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-16		draft-ietf-roll-useofrplinfo-17
	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
	and the RFC 6550 to indicate about this change.		and the RFC 6550 to indicate about this change.
	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 http://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 January 4, 2018.		This Internet-Draft will expire on April 30, 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 and RFC 6550 . . . . . . . . . . . . . . . 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 6550 . . . . . . . . . . . . . . . . . . . 6		3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 6
	4. Sample/reference topology . . . . . . . . . . . . . . . . . . 7		3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
			Configuration Option Flag. . . . . . . . . . . . . . . . 6
			4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8
	5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13		6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13
	6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 14		6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 14
	6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 15		6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 15
	6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 15		6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 15
	6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 16		6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 16
	6.2. Storing Mode: Interaction between Leaf and Internet . . . 17		6.2. Storing Mode: Interaction between Leaf and Internet . . . 17
	6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 17		6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 17
	6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18		6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 29 ¶
	7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to		7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
	RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 38		RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 38
	7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to		7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to
	not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39		not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39
	8. Observations about the cases . . . . . . . . . . . . . . . . 40		8. Observations about the cases . . . . . . . . . . . . . . . . 40
	8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40		8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40
	8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41		8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41
	9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41		9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 42		11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	13.1. Normative References . . . . . . . . . . . . . . . . . . 45		13.1. Normative References . . . . . . . . . . . . . . . . . . 45
	13.2. Informative References . . . . . . . . . . . . . . . . . 46		13.2. Informative References . . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	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. RFC 6553
	[RFC6553] defines the "RPL option" (RPI), carried within the IPv6		[RFC6553] defines the "RPL option" (RPI), carried within the IPv6
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 12 ¶
	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).
	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 implementors agree when artifacts		artifacts as possible that not all implementors agree when artifacts
	are necessary, or when they can be safely omitted, or removed.		are necessary, or when they can be safely omitted, or removed.
	An interim meeting went through the 24 cases defined here to discover		An interim meeting went through the 24 cases defined here to discover
	if there were any shortcuts, and this document is the result of that		if there were any shortcuts, and this document is the result of that
	discussion. This document clarify what is correct and incorrect		discussion. This document clarifies what is the correct and the
	behaviour.		incorrect behaviour.
	The related document A Routing Header Dispatch for 6LoWPAN (6LoRH)		The related document A Routing Header Dispatch for 6LoWPAN (6LoRH)
	[I-D.ietf-roll-routing-dispatch] defines a method to compress RPL		[I-D.ietf-roll-routing-dispatch] defines a method to compress RPL
	Option information and Routing Header type 3 [RFC6554], an efficient		Option information and Routing Header type 3 [RFC6554], an efficient
	IP-in-IP technique, and use cases proposed for the		IP-in-IP technique, and use cases proposed for the
	[Second6TischPlugtest] involving 6loRH.		[Second6TischPlugtest] involving 6loRH.
	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",
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 35 ¶
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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: It is device which implements RPL, thus we can say that the		RPL-node: It is device which implements RPL, thus we can say that the
	device is RPL-capable or RPL-aware. Please note that the device can		device is RPL-capable or RPL-aware. Please note that the device can
	be found inside the LLN or outside LLN. In this document a RPL-node		be found inside the LLN or outside LLN. In this document a RPL-node
	which is a leaf of a DODAG is called RPL-aware-leaf.		which is a leaf of a DODAG is called RPL-aware-leaf.
	RPL-not-capable: It is device which do not implement RPL, thus we can		RPL-not-capable: It is device which does not implement RPL, thus we
	say that the device is not-RPL-aware. Please note that the device		can say that the device is not-RPL-aware. Please note that the
	can be found inside the LLN. In this document a not-RPL-aware node		device can be found inside the LLN. In this document a not-RPL-aware
	which is a leaf of a DODAG is called not-RPL-aware-leaf.		node which is a leaf of a DODAG is called not-RPL-aware-leaf.
	pledge: a new device which seeks admission to a network. (from		pledge: a new device which seeks admission to a network. (from
	[I-D.ietf-anima-bootstrapping-keyinfra])		[I-D.ietf-anima-bootstrapping-keyinfra])
	Join Registrar and Coordinator (JRC): a device which brings new nodes		Join Registrar and Coordinator (JRC): a device which brings new nodes
	(pledges) into a network. (from		(pledges) into a network. (from
	[I-D.ietf-anima-bootstrapping-keyinfra])		[I-D.ietf-anima-bootstrapping-keyinfra])
	Flag day: A "flag day" is a procedure in which the network, or a part		Flag day: A "flag day" is a procedure in which the network, or a part
	of it, is changed during a planned outage, or suddenly, causing an		of it, is changed during a planned outage, or suddenly, causing an
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	2.1. hop-by-hop IPv6-in-IPv6 headers		2.1. hop-by-hop IPv6-in-IPv6 headers
	The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header		The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
	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 and RFC 6550		3. Updates to RFC6553, RFC6550 and RFC 8138
	3.1. Updates to RFC 6553		3.1. Updates to RFC 6553
	[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.
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	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 [I-D.ietf-roll-routing-dispatch] will		mechanism to those described in [I-D.ietf-roll-routing-dispatch] will
	experience a flag day in the data compression anyway, and if possible		experience a flag day in the data compression anyway, and if possible
	this change can be deployed at the same time.		this change can be deployed at the same time.
	3.2. Updates to RFC 6550		3.2. Updates to RFC 8138
			RPI-6LoRH header provides a compressed form for the RPL RPI
			[RFC8138]. It should be considered when the Option Type in RPL
			Option is decompressed, should take the value of 0x23 instead of
			0x63.
			3.3. Updates to RFC 6550: 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
	new RPI (0x23) and old RPI (0x63) nodes, the new nodes need to be		new RPI (0x23) and old RPI (0x63) nodes, the new nodes need to be
	told that there are old RPI nodes present. This can be done via a		told that there are old RPI nodes present. This can be done via the
	new DIO Option which will propogate through the network. Failure to		DODAG Configuration Option flag which will propogate through the
	receive this flag will cause dual mode nodes to originate traffic		network. Failure to receive this information will cause dual mode
	with the old-RPI (0x63) value.		nodes to originate traffic with the old-RPI (0x63) value.
	DIO Option: 0x05 RPI 0x23 enable MCRXXX		As states in [RFC6550] the DODAG Configuration option is present in
			DIO messages. the DODAG Configuration option distribute
			configuration information which is generally static and unchanging
			within the DODAG. This information is configured at the DODAG root
			and distributed throughout the DODAG with the DODAG Configuration
			option. Nodes other than the DODAG root must not modify this
			information when propagating the DODAG Configuration option.
	Flags: 8-bit unused field reserved for flags. The field MUST be		The DODAG Configuration Option is as follow. We are interested in
	initialized to zero by the sender and MUST be ignored by the		the Flag field. The remaining fields states as defined in [RFC6550].
	receiver.
	We propose to use a bit flag as follows:		Flags: The 4-bits remaining unused in the Flags field are reserved
			for flags. The field MUST be initialized to zero by the sender and
			MUST be ignored by the receiver.
	+----+----+----+----+----+----+----+----+		0 1 2 3
	| | | | | | | | |		+-----------------+---------------------------------------------------+
	| | | | | | | | FR |		| Type = 0x04 | Opt Length = 14| Flags | A | PCS| DIOIntDoubl. |
	| | | | | | | | |		+---------------------------------------------------------------------+
	+----+----+----+----+----+----+----+----+		| DIOIntMin. | DIORedund. | MaxRankIncrease |
			+-----------------+---------------------------------------------------+
			| MinHopRankIncrease | OCP |
			+-----------------+---------------------------------------------------+
			|Reserved | Def. Lifetime | Lifetime Unit |
			+-----------------+-----------------+---------------------------------+
	Figure 3: A DIO Flag to indicate the RPI-flag-day.		Figure 3: DODAG Configuration Option.
	FR(RPI-flag-day): the flag with values of 1 indicates that RPL Option		We propose to use the flag in the DODAG Configuration option as
	field is set to "00", values of 0 indicates that RPL Option field is		follows:
	set to "01"
			+------------+-----------------+---------------+
			| Bit number | Description | Reference |
			+------------+-----------------+---------------+
			| 3 | RPI 0x23 enable | This document |
			+------------+-----------------+---------------+
			Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag-
			day.
			In case of rebooting, the DIO is sent with flag indicating the new
			RPI value.
	4. Sample/reference topology		4. Sample/reference topology
	A RPL network in general is composed of a 6LBR (6LoWPAN Border		A RPL network in general is composed of a 6LBR (6LoWPAN Border
	Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN		Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN
	(6LoWPAN Node) as leaf logically organized in a DODAG structure.		(6LoWPAN Node) as leaf logically organized in a DODAG structure.
	(Destination Oriented Directed Acyclic Graph).		(Destination Oriented Directed Acyclic Graph).
	RPL defines the RPL Control messages (control plane), a new ICMPv6		RPL defines the RPL Control messages (control plane), a new ICMPv6
	[RFC4443] message with Type 155. DIS (DODAG Information		[RFC4443] message with Type 155. DIS (DODAG Information
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 45 ¶
	| IPv6 |		| IPv6 |
	| |		| |
	+--------------+		+--------------+
	| 6LoWPAN |		| 6LoWPAN |
	| |		| |
	+--------------+		+--------------+
	| PHY-MAC |		| PHY-MAC |
	| |		| |
	+--------------+		+--------------+
	Figure 4: RPL Stack.		Figure 5: RPL Stack.
	+------------+		+------------+
	| INTERNET ----------+		| INTERNET ----------+
	| | |		| | |
	+------------+ |		+------------+ |
	|		|
	|		|
	|		|
	A |		A |
	+-------+		+-------+
	skipping to change at page 9, line 46 ¶		skipping to change at page 9, line 46 ¶
	| | +--+ | |		| | +--+ | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | I | J |		| | | I | J |
	F | | G | H | |		F | | G | H | |
	+-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+		+-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+
	| Raf | | ~Raf | | Raf | | Raf | | ~Raf |		| Raf | | ~Raf | | Raf | | Raf | | ~Raf |
	| 6LN | | 6LN | | 6LN | | 6LN | | 6LN |		| 6LN | | 6LN | | 6LN | | 6LN | | 6LN |
	+-------+ +-------+ +------+ +-------+ +-------+		+-------+ +-------+ +------+ +-------+ +-------+
	Figure 5: A reference RPL Topology.		Figure 6: A reference RPL Topology.
	Figure 2 shows the reference RPL Topology for this document. The		Figure 2 shows the reference RPL Topology for this document. The
	letters above the nodes are there so that they may be referenced in		letters above the nodes are there so that they may be referenced in
	subsequent sections. In the figure, a 6LR is a router. A 6LN can be		subsequent sections. In the figure, a 6LR is a router. A 6LN can be
	a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked		a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked
	as (F and I) are RPL hosts that does not have forwarding capability.		as (F and I) are RPL hosts that does not have forwarding capability.
	The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL		The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL
	aware leaf" (G and J) are devices which do not speak RPL at all (not-		aware leaf" (G and J) are devices which do not speak RPL at all (not-
	RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and		RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and
	efficient-ND only to participate in the network [RFC6775]. In the		efficient-ND only to participate in the network [RFC6775]. In the
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 33 ¶
	+---------------------+--------------+----------+--------------+		+---------------------+--------------+----------+--------------+
	| | Raf to Raf | No | -- |		| | Raf to Raf | No | -- |
	+ +--------------+----------+--------------+		+ +--------------+----------+--------------+
	| | Raf to ~Raf | No | -- |		| | Raf to ~Raf | No | -- |
	+ Leaf - Leaf +--------------+----------+--------------+		+ Leaf - Leaf +--------------+----------+--------------+
	| | ~Raf to Raf | Yes | dst |		| | ~Raf to Raf | Yes | dst |
	+ +--------------+----------+--------------+		+ +--------------+----------+--------------+
	| | ~Raf to ~Raf | Yes | hop |		| | ~Raf to ~Raf | Yes | hop |
	+---------------------+--------------+----------+--------------+		+---------------------+--------------+----------+--------------+
	Figure 6: IP-in-IP encapsulation in Storing mode.		Figure 7: IP-in-IP encapsulation in Storing mode.
	6.1. Storing Mode: Interaction between Leaf and Root		6.1. Storing Mode: Interaction between Leaf and Root
	In this section we are going to describe the communication flow in		In this section we are going to describe the communication flow in
	storing mode (SM) between,		storing mode (SM) between,
	RPL-aware-leaf to root		RPL-aware-leaf to root
	root to RPL-aware-leaf		root to RPL-aware-leaf
	skipping to change at page 27, line 34 ¶		skipping to change at page 27, line 34 ¶
	+-----------------+--------------+-----+-----+----------+----------+		+-----------------+--------------+-----+-----+----------+----------+
	| | Raf to Raf | Yes | Yes | Yes | root/dst |		| | Raf to Raf | Yes | Yes | Yes | root/dst |
	+ +--------------+-----+-----+----------+----------+		+ +--------------+-----+-----+----------+----------+
	| | Raf to ~Raf | Yes | Yes | Yes | root/6LR |		| | Raf to ~Raf | Yes | Yes | Yes | root/6LR |
	+ Leaf - Leaf +--------------+-----+-----+----------+----------+		+ Leaf - Leaf +--------------+-----+-----+----------+----------+
	| | ~Raf to Raf | Yes | Yes | Yes | root/6LN |		| | ~Raf to Raf | Yes | Yes | Yes | root/6LN |
	+ +--------------+-----+-----+----------+----------+		+ +--------------+-----+-----+----------+----------+
	| | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR |		| | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR |
	+-----------------+--------------+-----+-----+----------+----------+		+-----------------+--------------+-----+-----+----------+----------+
	Figure 7: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP		Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
	encapsulation.		encapsulation.
	7.1. Non-Storing Mode: Interaction between Leaf and Root		7.1. Non-Storing Mode: Interaction between Leaf and Root
	In this section we are going to describe the communication flow in		In this section we are going to describe the communication flow in
	Non Storing Mode (Non-SM) between,		Non Storing Mode (Non-SM) between,
	RPL-aware-leaf to root		RPL-aware-leaf to root
	root to RPL-aware-leaf		root to RPL-aware-leaf
	skipping to change at page 41, line 37 ¶		skipping to change at page 41, line 37 ¶
	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 |
	+--+-----+---+--------------+-----------+-------------+-------------+		+--+-----+---+--------------+-----------+-------------+-------------+
	Figure 8: Critical IP-in-IP (RPI).		Figure 9: Critical IP-in-IP (RPI).
	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.		Options and Hop-by-Hop Options registry from 0x63 to 0x23.
	Hex Value Binary Value		Hex Value Binary Value
	act chg rest Description Reference		act chg rest Description Reference
	--------- --- --- ------- ----------------- ----------		--------- --- --- ------- ----------------- ----------
	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 9: Option Type in RPL Option.		Figure 10: Option Type in RPL Option.
	Todo: Add the Updates to RFC 6550.		We propose to use DODAG Configuration Option Flags in the DODAG
			Configuration option as follows:
			+------------+-----------------+---------------+
			| Bit number | Description | Reference |
			+------------+-----------------+---------------+
			| 3 | RPI 0x23 enable | This document |
			+------------+-----------------+---------------+
			Figure 11: DODAG Configuration Option Flag to indicate the RPI-flag-
			day.
	11. Security Considerations		11. Security Considerations
	The security considerations covering of [RFC6553] and [RFC6554] apply		The security considerations covering of [RFC6553] and [RFC6554] apply
	when the packets get into RPL Domain.		when the packets get into RPL Domain.
	The IPIP mechanism described in this document is much more limited		The IPIP mechanism described in this document is much more limited
	than the general mechanism described in [RFC2473]. The willingness		than the general mechanism described in [RFC2473]. The willingness
	of each node in the LLN to decapsulate packets and forward them could		of each node in the LLN to decapsulate packets and forward them could
	be exploited by nodes to disguise the origin of an attack.		be exploited by nodes to disguise the origin of an attack.
	skipping to change at page 44, line 48 ¶		skipping to change at page 45, line 12 ¶
	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		The authors would like to acknowledge the review, feedback, and
	comments of (alphabetical order): Robert Cragie, Simon Duquennoy,		comments of (alphabetical order): Robert Cragie, Simon Duquennoy,
	Cenk Guendogan, C. M. Heard, Rahul Jadhav, Peter van der Stok,		Ralph Droms, Cenk Guendogan, C. M. Heard, Rahul Jadhav, Matthias
	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
	[I-D.ietf-6man-rfc2460bis]		[I-D.ietf-6man-rfc2460bis]
	Deering, S. and R. Hinden, "Internet Protocol, Version 6		Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work		(IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
	in progress), May 2017.		in progress), May 2017.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <http://www.rfc-editor.org/info/rfc2473>.		December 1998, <https://www.rfc-editor.org/info/rfc2473>.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] 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, DOI 10.17487/RFC2827,		Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
	May 2000, <http://www.rfc-editor.org/info/rfc2827>.		May 2000, <https://www.rfc-editor.org/info/rfc2827>.
	[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec		[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
	Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,		Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
	February 2009, <http://www.rfc-editor.org/info/rfc5406>.		February 2009, <https://www.rfc-editor.org/info/rfc5406>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<http://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-		[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
	Power and Lossy Networks (RPL) Option for Carrying RPL		Power and Lossy Networks (RPL) Option for Carrying RPL
	Information in Data-Plane Datagrams", RFC 6553,		Information in Data-Plane Datagrams", RFC 6553,
	DOI 10.17487/RFC6553, March 2012,		DOI 10.17487/RFC6553, March 2012,
	<http://www.rfc-editor.org/info/rfc6553>.		<https://www.rfc-editor.org/info/rfc6553>.
	[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6		[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554,		for Low-Power and Lossy Networks (RPL)", RFC 6554,
	DOI 10.17487/RFC6554, March 2012,		DOI 10.17487/RFC6554, March 2012,
	<http://www.rfc-editor.org/info/rfc6554>.		<https://www.rfc-editor.org/info/rfc6554>.
	[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing		[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
	of IPv6 Extension Headers", RFC 7045,		of IPv6 Extension Headers", RFC 7045,
	DOI 10.17487/RFC7045, December 2013,		DOI 10.17487/RFC7045, December 2013,
	<http://www.rfc-editor.org/info/rfc7045>.		<https://www.rfc-editor.org/info/rfc7045>.
	[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,		[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
	and M. Richardson, Ed., "A Security Threat Analysis for		and M. Richardson, Ed., "A Security Threat Analysis for
	the Routing Protocol for Low-Power and Lossy Networks		the Routing Protocol for Low-Power and Lossy Networks
	(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,		(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
	<http://www.rfc-editor.org/info/rfc7416>.		<https://www.rfc-editor.org/info/rfc7416>.
			[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
			"IPv6 over Low-Power Wireless Personal Area Network
			(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
			April 2017, <https://www.rfc-editor.org/info/rfc8138>.
	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-03 (work in progress), January 2017.		backbone-router-04 (work in progress), July 2017.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
	in progress), January 2017.		in progress), August 2017.
	[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]
	Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic		Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
	Control Plane", draft-ietf-anima-autonomic-control-		Control Plane (ACP)", draft-ietf-anima-autonomic-control-
	plane-06 (work in progress), March 2017.		plane-12 (work in progress), October 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-06 (work in progress), May 2017.		keyinfra-08 (work in progress), October 2017.
	[I-D.ietf-roll-dao-projection]		[I-D.ietf-roll-dao-projection]
	Thubert, P. and J. Pylakutty, "Root initiated routing		Thubert, P. and J. Pylakutty, "Root initiated routing
	state in RPL", draft-ietf-roll-dao-projection-01 (work in		state in RPL", draft-ietf-roll-dao-projection-02 (work in
	progress), March 2017.		progress), September 2017.
	[I-D.ietf-roll-routing-dispatch]		[I-D.ietf-roll-routing-dispatch]
	Thubert, P., Bormann, C., Toutain, L., and R. Cragie,		Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
	"6LoWPAN Routing Header", draft-ietf-roll-routing-		"6LoWPAN Routing Header", draft-ietf-roll-routing-
	dispatch-05 (work in progress), October 2016.		dispatch-05 (work in progress), October 2016.
	[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,
	<http://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", RFC 4443,		Protocol Version 6 (IPv6) Specification", STD 89,
	DOI 10.17487/RFC4443, March 2006,		RFC 4443, DOI 10.17487/RFC4443, March 2006,
	<http://www.rfc-editor.org/info/rfc4443>.		<https://www.rfc-editor.org/info/rfc4443>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<http://www.rfc-editor.org/info/rfc6775>.		<https://www.rfc-editor.org/info/rfc6775>.
	[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,
	<http://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, <http://www.rfc-editor.org/info/rfc7102>.		2014, <https://www.rfc-editor.org/info/rfc7102>.
	[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
End of changes. 49 change blocks.
	71 lines changed or deleted		119 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/