< draft-ietf-roll-turnon-rfc8138-01.txt		draft-ietf-roll-turnon-rfc8138-02.txt >
	ROLL P. Thubert, Ed.		ROLL P. Thubert, Ed.
	Internet-Draft L. Zhao		Internet-Draft L. Zhao
	Updates: 6550,8138 (if approved) Cisco Systems		Updates: 6550, 8138 (if approved) Cisco Systems
	Intended status: Standards Track December 12, 2019		Intended status: Standards Track 12 December 2019
	Expires: June 14, 2020		Expires: 14 June 2020
	Configuration option for RFC 8138		Configuration option for RFC 8138
	draft-ietf-roll-turnon-rfc8138-01		draft-ietf-roll-turnon-rfc8138-02
	Abstract		Abstract
	This document complements RFC 8138 and dedicates a bit in the RPL		This document complements RFC 8138 and dedicates a bit in the RPL
	configuration option defined in RFC 6550 to indicate whether RFC 8138		configuration option defined in RFC 6550 to indicate whether RFC 8138
	compression is used within the RPL instance.		compression is used within the RPL instance.
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 June 14, 2020.		This Internet-Draft will expire on 14 June 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 2		3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 2
	4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 3		4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 3
	5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 3		5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 3
	5.1. Inconsistent State While Migrating . . . . . . . . . . . 4		5.1. Inconsistent State While Migrating . . . . . . . . . . . 4
	5.2. Single Instance Scenario . . . . . . . . . . . . . . . . 5		5.2. Single Instance Scenario . . . . . . . . . . . . . . . . 5
	5.3. Double Instance Scenario . . . . . . . . . . . . . . . . 5		5.3. Double Instance Scenario . . . . . . . . . . . . . . . . 6
	5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6		5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. Normative References . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		10. Informative References . . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The transition to [RFC8138] in a network can only be done when all		The transition to [RFC8138] in a network can only be done when all
	nodes support the specification. In a mixed case with both		nodes support the specification. In a mixed case with both
	RFC8138-capable and non-capable nodes, the compression should be		RFC8138-capable and non-capable nodes, the compression should be
	turned off.		turned off.
	This document complements RFC 8138 and dedicates a bit in the RPL		This document complements RFC 8138 and dedicates a bit in the RPL
	configuration option to indicate whether RFC 8138 compression should		configuration option to indicate whether RFC 8138 compression should
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 50 ¶
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Updating RFC 6550		3. Updating RFC 6550
	RPL defines a configuration option that is registered to IANA in		RPL defines a configuration option that is registered to IANA in
	section 20.14. of [RFC6550]. This specification defines a new flag		section 20.14. of [RFC6550]. This specification defines a new flag
	"Enable RFC8138 Compression" (T) that is encoded in one of the		"Enable RFC8138 Compression" (T) that is encoded in one of the
	reserved control bits in the option. The new flag is set to turn on		reserved control bits in the option. The new flag is set to turn on
	the use of the compression of RPL artifacts with RFC 8138.		the use of the compression of RPL artifacts with RFC 8138. The bit
			position of the "T" flag is indicated in Section 6.
	Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP)		Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP)
	in the DIO Base Object. The new "T" flag is defined only for MOP		in the DIO Base Object. The new "T" flag is defined only for MOP
	value between 0 to 6. For a MOP value of 7 or above, the flag MAY		value between 0 to 6. For a MOP value of 7 or above, the flag MAY
	indicate something different and MUST NOT be interpreted as "Enable		indicate something different and MUST NOT be interpreted as "Enable
	RFC8138 Compression" unless the specification of the MOP indicates to		RFC8138 Compression" unless the specification of the MOP indicates to
	do so.		do so.
	4. Updating RFC 8138		4. Updating RFC 8138
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 31 ¶
	migrates to the new OCP. As a result, nodes that do not support RFC		migrates to the new OCP. As a result, nodes that do not support RFC
	8138 join as leaves and do not forward packets anymore. The leaves		8138 join as leaves and do not forward packets anymore. The leaves
	generate packets without compression. The parents - which supports		generate packets without compression. The parents - which supports
	RFC 8138 - may encapsulate the packets using RFC 8138 if needed. The		RFC 8138 - may encapsulate the packets using RFC 8138 if needed. The
	other way around, the root encapsulates packets to the leaves all the		other way around, the root encapsulates packets to the leaves all the
	way to the parent, which decapsulates and distribute the uncompresses		way to the parent, which decapsulates and distribute the uncompresses
	inner packet to the leaf.		inner packet to the leaf.
	This scenario presents a number of caveats:		This scenario presents a number of caveats:
	o The method consumes an extra OCP. It also requires a means to		* The method consumes an extra OCP. It also requires a means to
	signal the capabilities of the leaf, e.g., using "RPL Mode of		signal the capabilities of the leaf, e.g., using "RPL Mode of
	Operation extension" [I-D.rahul-roll-mop-ext].		Operation extension" [MOP-EXT].
	o If an implementation does not move to a leaf mode when the OCP is		* If an implementation does not move to a leaf mode when the OCP is
	changed to an unknown one, then the node may be stalled.		changed to an unknown one, then the node may be stalled.
	o If the only possible parents of a node are nodes that do not		* If the only possible parents of a node are nodes that do not
	support RFC 8138, then that node will loose all its parent at the		support RFC 8138, then that node will loose all its parent at the
	time of the migration and it will be stalled until a parent is		time of the migration and it will be stalled until a parent is
	deployed with the new capability.		deployed with the new capability.
	o Nodes that only support RFC8138 for forwarding may not parse the		* Nodes that only support RFC8138 for forwarding may not parse the
	RPI in native form. If such nodes are present, the parent needs		RPI in native form. If such nodes are present, the parent needs
	to encapsulate with RFC8138.		to encapsulate with RFC8138.
	5.3. Double Instance Scenario		5.3. Double Instance Scenario
	An alternate to the Single Instance Scenario is to deploy an		An alternate to the Single Instance Scenario is to deploy an
	additional Instance for the nodes that support [RFC8138]. The two		additional Instance for the nodes that support [RFC8138]. The two
	instances operate as ships-in-the-night as specified in [RFC6550].		instances operate as ships-in-the-night as specified in [RFC6550].
	The preexisting Instance that does not use [RFC8138], whereas the new		The preexisting Instance that does not use [RFC8138], whereas the new
	Instance does. This is signaled by the "T" flag which is only set in		Instance does. This is signaled by the "T" flag which is only set in
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 38 ¶
	the administrator SHOULD make sure that all nodes have converged to		the administrator SHOULD make sure that all nodes have converged to
	the "T" flag reset before allowing nodes that do not support the		the "T" flag reset before allowing nodes that do not support the
	compression in the network (see caveats in Section 5.2).		compression in the network (see caveats in Section 5.2).
	It is RECOMMENDED to only deploy nodes that support [RFC8138] in a		It is RECOMMENDED to only deploy nodes that support [RFC8138] in a
	network where the compression is turned on. A node that does not		network where the compression is turned on. A node that does not
	support [RFC8138] MUST only be used as a leaf.		support [RFC8138] MUST only be used as a leaf.
	6. IANA Considerations		6. IANA Considerations
	This specification updates the "Registry for the DODAG Configuration		This specification updates the Registry for the "DODAG Configuration
	Option Flags" that was created for [RFC6550] as follows:		Option Flags" that was created for [RFC6550] as follows:
	+---------------+---------------------------------+-----------------+		+------------+---------------------------------+-----------+
	| Bit Number | Meaning | Defining Spec |		| Bit Number | Capability Description | Reference |
	+---------------+---------------------------------+-----------------+		+============+=================================+===========+
	| 2 (suggested) | Turn on RFC8138 Compression | This |		| 2 | Turn on RFC8138 Compression (T) | THIS RFC |
	| | (T) | |		+------------+---------------------------------+-----------+
	+---------------+---------------------------------+-----------------+
	Table 1: New DODAG Configuration Option Flag		Table 1: New DODAG Configuration Option Flag
	7. Security Considerations		7. Security Considerations
	No specific threat was identified with this specification.		Turning the "T" flag on before some routers are upgraded may cause a
			loss 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
			if an attacker manages to inject a corrupted configuration.
			Turning the "T" flag on and off may create inconsistencies in the
			network but as long as all nodes are upgraded to RFC 8138 support
			they will be able to forward both forms. The draft insists that the
			source is responsible for selecting whether the packet is compressed
			or not, and all 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 network, at an additional cost of bandwidth for
			packets in the uncompressed form.
	8. Acknowledgments		8. Acknowledgments
	9. References
	9.1. 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>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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,
	<https://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		10. Informative References
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References
	[I-D.rahul-roll-mop-ext]
	Jadhav, R. and P. Thubert, "RPL Mode of Operation
	extension", draft-rahul-roll-mop-ext-01 (work in
	progress), June 2019.
	[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,		[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
	"IPv6 over Low-Power Wireless Personal Area Network		"IPv6 over Low-Power Wireless Personal Area Network
	(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,		(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
	April 2017, <https://www.rfc-editor.org/info/rfc8138>.		April 2017, <https://www.rfc-editor.org/info/rfc8138>.
			[MOP-EXT] Jadhav, R., Thubert, P., and M. Richardson, "Mode of
			Operation extension and Capabilities", Work in Progress,
			Internet-Draft, draft-ietf-roll-mopex-cap-01, 2 November
			2019, <https://tools.ietf.org/html/draft-ietf-roll-mopex-
			cap-01>.
	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
	MOUGINS - Sophia Antipolis 06254		France
	FRANCE
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Li Zhao		Li Zhao
	Cisco Systems, Inc		Cisco Systems, Inc
	Xinsi Building		Xinsi Building, No. 926 Yi Shan Rd
	No. 926 Yi Shan Rd		SHANGHAI
	SHANGHAI 200233		200233
	CHINA		China
	Email: liz3@cisco.com		Email: liz3@cisco.com
End of changes. 23 change blocks.
	54 lines changed or deleted		64 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/