< draft-ietf-roll-turnon-rfc8138-15.txt		draft-ietf-roll-turnon-rfc8138-16.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: 8138 (if approved) Cisco Systems
	Intended status: Standards Track 18 September 2020		Intended status: Standards Track 24 September 2020
	Expires: 22 March 2021		Expires: 28 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-15		draft-ietf-roll-turnon-rfc8138-16
	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 unset.		when the bit is set and unset.
	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 22 March 2021.		This Internet-Draft will expire on 28 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 12 ¶		skipping to change at page 2, line 12 ¶
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4		3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 4
	4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 5		4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 5
	5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5		5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5
	5.1. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Inconsistent State While Migrating . . . . . . . . . . . 6		5.2. Inconsistent State While Migrating . . . . . . . . . . . 6
	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
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	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",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"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. Extending RFC 6550
	The DODAG Configuration Option is defined in Section 6.7.6 of		The DODAG Configuration Option is defined in Section 6.7.6 of
	[RFC6550]. Its purpose is extended to distribute configuration		[RFC6550]. Its purpose is extended to distribute configuration
	information affecting the construction and maintenance of the DODAG,		information affecting the construction and maintenance of the DODAG,
	as well as operational parameters for RPL on the DODAG, through the		as well as operational parameters for RPL on the DODAG, through the
	DODAG. As shown in Figure 1, the Option was originally designed with		DODAG. As shown in Figure 1, the Option was originally designed with
	4 bit positions reserved for future use as Flags.		4 bit positions reserved for future use as Flags.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	Figure 1: DODAG Configuration Option (Partial View)		Figure 1: DODAG Configuration Option (Partial View)
	This specification defines a new flag "Enable RFC8138 Compression"		This specification defines a new flag "Enable RFC8138 Compression"
	(T). The "T" flag is set to turn-on the use of [RFC8138] within the		(T). The "T" flag is set to turn-on the use of [RFC8138] within the
	DODAG. The "T" flag is encoded in position 2 of the reserved Flags		DODAG. The "T" flag is encoded in position 2 of the reserved Flags
	in the DODAG Configuration Option (counting from bit 0 as the most		in the DODAG Configuration Option (counting from bit 0 as the most
	significant bit) and set to 0 in legacy implementations as specified		significant bit) and set to 0 in legacy implementations as specified
	respectively in Sections 20.14 and 6.7.6 of [RFC6550].		respectively in Sections 20.14 and 6.7.6 of [RFC6550].
			Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
			definition of the Flags applies to Mode of Operation (MOP) values
			zero (0) to six (6) only, leaving the flags reserved for MOP value
			seven (7). For a MOP value of 7, the bit in position 2 is considered
			unallocated and [RFC8138] MUST be used on Links where 6LoWPAN Header
			Compression [RFC6282] applies and MUST NOT be used otherwise.
	The RPL DODAG Configuration Option is typically placed in a DODAG		The RPL DODAG Configuration Option is typically placed in a DODAG
	Information Object (DIO) message. The DIO message propagates down		Information Object (DIO) message. The DIO message propagates down
	the DODAG to form and then maintain its structure. The DODAG		the DODAG to form and then maintain its structure. The DODAG
	Configuration Option is copied unmodified from parents to children.		Configuration Option is copied unmodified from parents to children.
	Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
	the DIO Base Object. This specification applies to MOP values 0 to
	6. For a MOP value of 7, the bit in position 2 is considered
	unallocated and [RFC8138] MUST be used by default.
	[RFC6550] states that "Nodes other than the DODAG Root MUST NOT		[RFC6550] states that "Nodes other than the DODAG Root MUST NOT
	modify this information when propagating the DODAG Configuration		modify this information when propagating the DODAG Configuration
	option". Therefore, a legacy parent propagates the "T" flag as set		option". Therefore, a legacy parent propagates the "T" flag as set
	by the Root whether it supports this specification or not. So when		by the Root, and when the "T" flag is set, it is transparently
	the "T" flag is set, it is transparently flooded to all the nodes in		flooded to all the nodes in the DODAG.
	the DODAG.
	4. Updating RFC 8138		4. Updating RFC 8138
	A node SHOULD generate packets in the compressed form using [RFC8138]		A node SHOULD generate packets in the compressed form using [RFC8138]
	if and only if the "T" flag is set. This behavior can be overridden		if and only if the "T" flag is set. This behavior can be overridden
	by configuration or network management. Overriding may be needed		by configuration or network management. Overriding may be needed
	e.g., to turn on the compression in a network where all nodes support		e.g., to turn on the compression in a network where all nodes support
	[RFC8138] but the Root does not support this specification and cannot		[RFC8138] but the Root does not support this specification and cannot
	set the "T" flag, or to disable it locally in case of a problem.		set the "T" flag, or to disable it locally in case of a problem.
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 13 ¶
	<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, 12 June 2020, <https://tools.ietf.org/html/
	draft-ietf-roll-unaware-leaves-18>.		draft-ietf-roll-unaware-leaves-18>.
	10. Informative References		10. Informative References
			[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
			Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
			DOI 10.17487/RFC6282, September 2011,
			<https://www.rfc-editor.org/info/rfc6282>.
	[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>.
End of changes. 9 change blocks.
	16 lines changed or deleted		21 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/