< draft-ietf-roll-turnon-rfc8138-11.txt		draft-ietf-roll-turnon-rfc8138-12.txt >
	ROLL P. Thubert, Ed.		ROLL P. Thubert, Ed.
	Internet-Draft L. Zhao		Internet-Draft L. Zhao
	Updates: 8138 (if approved) Cisco Systems		Updates: 8138 (if approved) Cisco Systems
	Intended status: Standards Track 27 August 2020		Intended status: Standards Track 2 September 2020
	Expires: 28 February 2021		Expires: 6 March 2021
	A RPL DODAG Configuration Option for the 6LoWPAN Routing Header		A RPL DODAG Configuration Option for the 6LoWPAN Routing Header
	draft-ietf-roll-turnon-rfc8138-11		draft-ietf-roll-turnon-rfc8138-12
	Abstract		Abstract
	This document updates RFC 8138 by defining a bit in the RPL DODAG		This document updates RFC 8138 by defining a bit in the RPL DODAG
	Configuration Option to indicate whether compression is used within		Configuration Option to indicate whether compression is used within
	the RPL Instance, and specify the behavior of RFC 8138-capable nodes		the RPL Instance, and specify the behavior of RFC 8138-capable nodes
	when the bit is set and reset.		when the bit is set and reset.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 28 February 2021.		This Internet-Draft will expire on 6 March 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	5.3. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6		5.3. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Normative References . . . . . . . . . . . . . . . . . . . . 8		9. Normative References . . . . . . . . . . . . . . . . . . . . 8
	10. Informative References . . . . . . . . . . . . . . . . . . . 9		10. Informative References . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The packet compression technique defined in [RFC8138] can only be		The design of Low Power and Lossy Networks (LLNs) is generally
	activated in a RPL [RFC6550] network when all the nodes support it.		focused on saving energy, which is the most constrained resource of
	Otherwise, if acting as a leaf, a node that does not support the		all. The routing optimizations in the "Routing Protocol for Low
	compression would fail to communicate; if acting as a router it would		Power and Lossy Networks" [RFC6550] (RPL) such as routing along a
	drop the compressed packets and black-hole a portion of the network.		Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node
			and the associated packet compression technique [RFC8138] derive from
			that primary concern.
	The original idea was to use a flag day but that proved impractical		Enabling [RFC8138] requires a Flag Day where the network is upgraded
	in a number of situations such as a large metering network that is		and rebooted. Otherwise, if acting as a Leaf, a node that does not
	used in production and incurs financial losses when interrupted.		support the compression would fail to communicate; if acting as a
			router it would drop the compressed packets and black-hole a portion
			of the network. This specification enables a hot upgrade where a
			live network is migrated. During the migration, the compression
			remains inactive, until all nodes are upgraded.
	This specification is designed for the scenario where a live network
	is upgraded to support [RFC8138]. During the migration, the
	compression should remain inactive, until all nodes are upgraded.
	This document complements [RFC8138] and dedicates a flag in the RPL		This document complements [RFC8138] and dedicates a flag in the RPL
	DODAG Configuration Option to indicate whether the [RFC8138]		DODAG Configuration Option to indicate whether the [RFC8138]
	compression should be used within the RPL DODAG.		compression should be used within the RPL DODAG. The setting of this
			new flag is controlled by the Root and propagates as is in the whole
	The setting of this new flag is controlled by the Root and propagates		network as part of the normal RPL signaling.
	as is in the whole network as part of the normal RPL signaling.
	The flag is cleared to maintain the compression inactive during the		The flag is cleared to maintain the compression inactive during the
	migration phase. When the migration is complete (e.g., as known by		migration phase. When the migration is complete (e.g., as known by
	network management and/or inventory), the flag is set and the		network management and/or inventory), the flag is set and the
	compression is globally activated in the whole DODAG.		compression is globally activated in the whole DODAG.
	2. Terminology		2. Terminology
	2.1. References		2.1. References
	skipping to change at page 6, line 50 ¶		skipping to change at page 6, line 50 ¶
	are upgraded to support this specification.		are upgraded to support this specification.
	5.3. Rolling Back		5.3. Rolling Back
	When turning [RFC8138] compression off in the network, the Network		When turning [RFC8138] compression off in the network, the Network
	Administrator MUST wait until all nodes have converged to the "T"		Administrator MUST wait until all nodes have converged to the "T"
	flag reset before allowing nodes that do not support the compression		flag reset before allowing nodes that do not support the compression
	in the network. To that effect, whether the compression is active in		in the network. To that effect, whether the compression is active in
	a node SHOULD be exposed the node's management interface.		a node SHOULD be exposed the node's management interface.
	It is RECOMMENDED to only deploy nodes that support [RFC8138] in a		Nodes that do not support [RFC8138] SHOULD NOT be deployed in a
	network where the compression is turned on. A node that does not		network where the compression is turned on. If that is done, the
	support [RFC8138] MUST only be used as a RUL.		node can only operate as a RUL.
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to assign a new option flag from the Registry for		IANA is requested to assign a new option flag from the Registry for
	the "DODAG Configuration Option Flags" that was created for [RFC6550]		the "DODAG Configuration Option Flags" that was created for [RFC6550]
	as follows:		as follows:
	+---------------+---------------------------------+-----------+		+---------------+---------------------------------+-----------+
	| Bit Number | Capability Description | Reference |		| Bit Number | Capability Description | Reference |
	+---------------+---------------------------------+-----------+		+---------------+---------------------------------+-----------+
	| 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC |		| 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC |
	+---------------+---------------------------------+-----------+		+---------------+---------------------------------+-----------+
	Table 1: New DODAG Configuration Option Flag		Table 1: New DODAG Configuration Option Flag
	7. Security Considerations		7. Security Considerations
	First of all, it is worth noting that with [RFC6550], every node in		It is worth noting that with RPL [RFC6550], every node in the LLN
	the LLN that is RPL-aware can inject any RPL-based attack in the		that is RPL-aware can inject any RPL-based attack in the network.
	network. A trust model is REQUIRED in an effort to exclude rogue		This document applies typically to an existing deployment and does
	nodes from participating to the RPL and the 6LoWPAN signaling, as		not change its security requirements and operations. It is assumed
	well as from the data packet exchange. This trust model could at a		that the security mechanisms as defined for RPL are followed.
	minimum be based on a Layer-2 Secure joining and the Link-Layer
	security. This is a generic RPL and 6LoWPAN requirement, see Req5.1
	in Appendix of [RFC8505].
	Setting the "T" flag before all routers are upgraded may cause a loss		Setting the "T" flag before all routers are upgraded may cause a loss
	of packets. The new bit is protected as the rest of the		of packets. The new bit is protected as the rest of the
	configuration so this is just one of the many attacks that can happen		configuration so this is just one of the many attacks that can happen
	if an attacker manages to inject a corrupted configuration.		if an attacker manages to inject a corrupted configuration.
	Setting and resetting the "T" flag may create inconsistencies in the		Setting and resetting the "T" flag may create inconsistencies in the
	network but as long as all nodes are upgraded to [RFC8138] support		network but as long as all nodes are upgraded to [RFC8138] support
	they will be able to forward both forms. The source is responsible		they will be able to forward both forms. The source is responsible
	for selecting whether the packet is compressed or not, and all		for selecting whether the packet is compressed or not, and all
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	"T" flag, so that nodes located downstream would compress when that		"T" flag, so that nodes located downstream would compress when that
	it is not desired, potentially resulting in the loss of packets. In		it is not desired, potentially resulting in the loss of packets. In
	a tree structure, the attacker would be in position to drop the		a tree structure, the attacker would be in position to drop the
	packets from and to the attacked nodes. So the attacks above would		packets from and to the attacked nodes. So the attacks above would
	be more complex and more visible than simply dropping selected		be more complex and more visible than simply dropping selected
	packets. The downstream node may have other parents and see both		packets. The downstream node may have other parents and see both
	settings, which could raise attention.		settings, which could raise attention.
	8. Acknowledgments		8. Acknowledgments
	The authors wish to thank Meral Shirazipour, Nagendra Kumar Nainar,		The authors wish to thank Meral Shirazipour, Barry Leiba, Nagendra
	Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique Barthel and		Kumar Nainar, Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique
	Rahul Jadhav for their in-depth reviews and constructive suggestions.		Barthel and Rahul Jadhav for their in-depth reviews and constructive
			suggestions.
	Also many thanks to Michael Richardson for being always helpful and		Also many thanks to Michael Richardson for being always helpful and
	responsive when need comes.		responsive when need comes.
	9. Normative References		9. 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>.
End of changes. 10 change blocks.
	33 lines changed or deleted		33 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/