draft-ietf-roll-turnon-rfc8138-13.txt		draft-ietf-roll-turnon-rfc8138-14.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 September 7, 2020		Intended status: Standards Track September 8, 2020
	Expires: March 11, 2021		Expires: March 12, 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-13		draft-ietf-roll-turnon-rfc8138-14
	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 March 11, 2021.		This Internet-Draft will expire on March 12, 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 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	A node that supports [RFC8138] but not this specification can only be		A node that supports [RFC8138] but not this specification can only be
	used in an homogeneous network. Enabling the [RFC8138] compression		used in an homogeneous network. Enabling the [RFC8138] compression
	without a turn-on signaling method requires a "flag day"; by which		without a turn-on signaling method requires a "flag day"; by which
	time all nodes must be upgraded, and at which point the network can		time all nodes must be upgraded, and at which point the network can
	be rebooted with the [RFC8138] compression turned on.		be rebooted with the [RFC8138] compression turned on.
	The intent for this specification is to perform a migration once and		The intent for this specification is to perform a migration once and
	for all without the need for a flag day. In particular it is not the		for all without the need for a flag day. In particular it is not the
	intention to undo the setting of the "T" flag. Though it is possible		intention to undo the setting of the "T" flag. Though it is possible
	to roll back (see Section 5.3), adding nodes that do not support		to roll back (see Section 5.3, the network operator SHOULD ensure
	[RFC8138] after a roll back may be problematic if the roll back did		that the roll back operation is completed before adding nodes that do
	not fully complete.		not support [RFC8138].
	5.1. Coexistence		5.1. Coexistence
	A node that supports this specification can operate in a network with		A node that supports this specification can operate in a network with
	the [RFC8138] compression turned on or off with the "T" flag set		the [RFC8138] compression turned on or off with the "T" flag set
	accordingly and in a network in transition from off to on or on to		accordingly and in a network in transition from off to on or on to
	off (see Section 5.2).		off (see Section 5.2).
	A node that does not support [RFC8138] can interoperate with nodes		A node that does not support [RFC8138] can interoperate with nodes
	that do in a network with [RFC8138] compression turned off. If the		that do in a network with [RFC8138] compression turned off. If the
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	structure, the attacker would be in position to drop the packets from		structure, the attacker would be in position to drop the packets from
	and to the attacked nodes. So the attacks above would be more		and to the attacked nodes. So the attacks above would be more
	complex and more visible than simply dropping selected packets. The		complex and more visible than simply dropping selected packets. The
	downstream node may have other parents and see both settings, which		downstream node may have other parents and see both settings, which
	could raise attention.		could raise attention.
	8. Acknowledgments		8. Acknowledgments
	The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry		The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry
	Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant,		Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant,
	Carles Gomez, and especially Alvaro Retana, Dominique Barthel and		Carles Gomez, Eric Vyncke, and especially 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. 5 change blocks.
	9 lines changed or deleted		10 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/