draft-ietf-roll-turnon-rfc8138-12.txt		draft-ietf-roll-turnon-rfc8138-13.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 2 September 2020		Intended status: Standards Track September 7, 2020
	Expires: 6 March 2021		Expires: March 11, 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-12		draft-ietf-roll-turnon-rfc8138-13
	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 6 March 2021.		This Internet-Draft will expire on March 11, 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 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	2.2. Glossary		2.2. Glossary
	This document often uses the following acronyms:		This document often uses the following acronyms:
	6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network		6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
	6LoRH: 6LoWPAN Routing Header		6LoRH: 6LoWPAN Routing Header
	DIO: DODAG Information Object (a RPL message)		DIO: DODAG Information Object (a RPL message)
	DODAG: Destination-Oriented Directed Acyclic Graph		DODAG: Destination-Oriented Directed Acyclic Graph
	LLN: Low-Power and Lossy Network		LLN: Low-Power and Lossy Network
	RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks		RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
	OF: RPL Objective Function		SubDAG: Subset of a DAG that is a child of a node
	OCP: RPL Objective Code Point
	MOP: RPL Mode of Operation		MOP: RPL Mode of Operation
	RPI: RPL Packet Information		RPI: RPL Packet Information
	RAL: RPL-Aware Leaf		RAL: RPL-Aware Leaf
	RAN: RPL-Aware Node		RAN: RPL-Aware Node
	RUL: RPL-Unaware Leaf		RUL: RPL-Unaware Leaf
	SRH: Source Routing Header		SRH: Source Routing Header
	2.3. Requirements Language		2.3. 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 7, line 21 ¶		skipping to change at page 7, line 21 ¶
	+---------------+---------------------------------+-----------+		+---------------+---------------------------------+-----------+
	| 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
	It is worth noting that with RPL [RFC6550], every node in the LLN		It is worth noting that in RPL [RFC6550], every node in the LLN that
	that is RPL-aware can inject any RPL-based attack in the network.		is RPL-aware and has access to the RPL domain can inject any RPL-
	This document applies typically to an existing deployment and does		based attack in the network, more in [RFC7416]. This document
	not change its security requirements and operations. It is assumed		applies typically to an existing deployment and does not change its
	that the security mechanisms as defined for RPL are followed.		security requirements and operations. It is assumed that the
			security mechanisms as defined for RPL are followed.
	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
	routers must use the format that the source selected. So the result		routers must use the format that the source selected. So the result
	of an inconsistency is merely that both forms will be present in the		of an inconsistency is merely that both forms will be present in the
	network, at an additional cost of bandwidth for packets in the		network, at an additional cost of bandwidth for packets in the
	uncompressed form.		uncompressed form.
	An attacker in the middle of the network may reset the "T" flag to		An attacker in the middle of the network may reset the "T" flag to
	cause extra energy spending in its subDAG. Conversely it may set the		cause extra energy spending in the subset of the DODAG formed by its
	"T" flag, so that nodes located downstream would compress when that		descendants (its subDAG). Conversely it may set the "T" flag, so
	it is not desired, potentially resulting in the loss of packets. In		that nodes located downstream would compress when that it is not
	a tree structure, the attacker would be in position to drop the		desired, potentially resulting in the loss of packets. In a tree
	packets from and to the attacked nodes. So the attacks above would		structure, the attacker would be in position to drop the packets from
	be more complex and more visible than simply dropping selected		and to the attacked nodes. So the attacks above would be more
	packets. The downstream node may have other parents and see both		complex and more visible than simply dropping selected packets. The
	settings, which could raise attention.		downstream node may have other parents and see both settings, which
			could raise attention.
	8. Acknowledgments		8. Acknowledgments
	The authors wish to thank Meral Shirazipour, Barry Leiba, Nagendra		The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry
	Kumar Nainar, Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique		Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant,
	Barthel and Rahul Jadhav for their in-depth reviews and constructive		Carles Gomez, and especially Alvaro Retana, Dominique Barthel and
	suggestions.		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>.
	skipping to change at page 8, line 51 ¶		skipping to change at page 8, line 51 ¶
	[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.		[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
	Perkins, "Registration Extensions for IPv6 over Low-Power		Perkins, "Registration Extensions for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Neighbor		Wireless Personal Area Network (6LoWPAN) Neighbor
	Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,		Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
	<https://www.rfc-editor.org/info/rfc8505>.		<https://www.rfc-editor.org/info/rfc8505>.
	[UNAWARE-LEAVES]		[UNAWARE-LEAVES]
	Thubert, P. and M. Richardson, "Routing for RPL Leaves",		Thubert, P. and M. Richardson, "Routing for RPL Leaves",
	Work in Progress, Internet-Draft, draft-ietf-roll-unaware-		Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
	leaves-18, 12 June 2020, <https://tools.ietf.org/html/		leaves-18, June 12, 2020, <https://tools.ietf.org/html/
	draft-ietf-roll-unaware-leaves-18>.		draft-ietf-roll-unaware-leaves-18>.
	10. Informative References		10. Informative References
	[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,
	<https://www.rfc-editor.org/info/rfc6553>.		<https://www.rfc-editor.org/info/rfc6553>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	<https://www.rfc-editor.org/info/rfc7228>.		<https://www.rfc-editor.org/info/rfc7228>.
			[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
			and M. Richardson, Ed., "A Security Threat Analysis for
			the Routing Protocol for Low-Power and Lossy Networks
			(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
			<https://www.rfc-editor.org/info/rfc7416>.
	[USEofRPLinfo]		[USEofRPLinfo]
	Robles, I., Richardson, M., and P. Thubert, "Using RPI		Robles, I., Richardson, M., and P. Thubert, "Using RPI
	Option Type, Routing Header for Source Routes and IPv6-in-		Option Type, Routing Header for Source Routes and IPv6-in-
	IPv6 encapsulation in the RPL Data Plane", Work in		IPv6 encapsulation in the RPL Data Plane", Work in
	Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40,		Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40,
	25 June 2020, <https://tools.ietf.org/html/draft-ietf-		June 25, 2020, <https://tools.ietf.org/html/draft-ietf-
	roll-useofrplinfo-40>.		roll-useofrplinfo-40>.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	06254 MOUGINS - Sophia Antipolis		06254 MOUGINS - Sophia Antipolis
	France		France
End of changes. 10 change blocks.
	25 lines changed or deleted		32 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/