< draft-ietf-roll-mopex-00.txt		draft-ietf-roll-mopex-01.txt >
	ROLL R. Jadhav, Ed.		ROLL R. Jadhav, Ed.
	Internet-Draft Huawei Tech		Internet-Draft Huawei Tech
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: October 17, 2020 Cisco		Expires: December 7, 2020 Cisco
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	April 15, 2020		June 5, 2020
	Mode of Operation extension		Mode of Operation extension
	draft-ietf-roll-mopex-00		draft-ietf-roll-mopex-01
	Abstract		Abstract
	RPL allows different mode of operations which allows nodes to have a		RPL allows different mode of operations which allows nodes to have a
	consensus on the basic primitives that must be supported to join the		consensus on the basic primitives that must be supported to join the
	network. The MOP field in [RFC6550] is of 3 bits and is fast		network. The MOP field in [RFC6550] is of 3 bits and is fast
	depleting. This document extends the MOP for future use.		depleting. This document extends the MOP for future use.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 October 17, 2020.		This Internet-Draft will expire on December 7, 2020.
	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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are 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
	1.1. Requirements Language and Terminology . . . . . . . . . . 2		1.1. Requirements Language and Terminology . . . . . . . . . . 3
	2. Requirements for this document . . . . . . . . . . . . . . . 3		2. Requirements for this document . . . . . . . . . . . . . . . 3
	3. Extended MOP Control Message Option . . . . . . . . . . . . . 3		3. Extended MOP Control Message Option . . . . . . . . . . . . . 4
	3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4		3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4		3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4
	4. Implementation Considerations . . . . . . . . . . . . . . . . 4		4. Extending RPL Control Options . . . . . . . . . . . . . . . . 4
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		5. Implementation Considerations . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 4		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6.2. New options: MOPex and Capabilities . . . . . . . . . . . 5		7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6
	6.3. New Registry for Extended-MOP-value . . . . . . . . . . . 5		7.2. New options: MOPex and Capabilities . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		9.2. Informative References . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	RPL [RFC6550] specifies a proactive distance-vector based routing		RPL [RFC6550] specifies a proactive distance-vector based routing
	scheme. The protocol creates a DAG-like structure which operates		scheme. The protocol creates a DAG-like structure which operates
	with a given "Mode of Operation" (MOP) determining the minimal and		with a given "Mode of Operation" (MOP) determining the minimal and
	mandatory set of primitives to be supported by all the participating		mandatory set of primitives to be supported by all the participating
	nodes.		nodes.
	MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is		MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is
	specific to the RPL Instance. The receipient of the DIO message can		specific to the RPL Instance. The receipient of the DIO message can
	join the specified network as a router only when it can support the		join the specified network as a router only when it can support the
	primitives as required by the mode of operation value. For example,		primitives as required by the mode of operation value. For example,
	in case of MOP=3 (Storing MOP with multicast support) the nodes can		in case of MOP=3 (Storing MOP with multicast support) the nodes can
	join the network as routers only when they can handle the DAO		join the network as routers only when they can handle the DAO
	advertisements from the peers and manage routing tables. The 3-bit		advertisements from the peers and manage routing tables. The 3-bit
	value is already exhausted and requires replenishment. This document		value is already exhausted and requires replenishment. This document
	introduces a mechanism to extend mode of operation values.		introduces a mechanism to extend mode of operation values.
			This document further extends the RPL Control Option syntax to handle
			generic flags. The primary aim of these flags is to define the
			behaviour of a node not supporting the given control type. If a node
			does not support a given RPL Control Option, there are three
			possibilities:
			REQ1: Strip off the option
			REQ2: Copy the option as-is
			REQ3: Ignore the message containing this option
			REQ4: Let the node join in only as a 6LN to this parent
	1.1. Requirements Language and Terminology		1.1. Requirements Language and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	MOP: Mode of Operation. Identifies the mode of operation of the RPL		MOP: Mode of Operation. Identifies the mode of operation of the RPL
	Instance as administratively provisioned at and distributed by the		Instance as administratively provisioned at and distributed by the
	DODAG root.		DODAG root.
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 44 ¶
	continues to be true even in case of MOPex.		continues to be true even in case of MOPex.
	3.2. Use of values 0-6 in the MOPex option		3.2. Use of values 0-6 in the MOPex option
	The MOPex option could also be allowed to re-use the values 0-6,		The MOPex option could also be allowed to re-use the values 0-6,
	which have been used for MOP so far. The use of current MOPs in		which have been used for MOP so far. The use of current MOPs in
	MOPex indicates that the MOP is supported with extended set of		MOPex indicates that the MOP is supported with extended set of
	semantics for e.g., the capability options		semantics for e.g., the capability options
	[I-D.ietf-roll-capabilities].		[I-D.ietf-roll-capabilities].
	4. Implementation Considerations		4. Extending RPL Control Options
			Section 6.7.1 of RFC6550 explains the RPL Control Message Option
			Generic Format. This document extends this format to following:
			0 1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------
			| |X| OptionType| Option Length |Opt Flags|J|I|C| Option Data
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------
			Figure 2: Extended RPL Option Format
			New fields in extended RPL Control Message Option Format:
			'X' bit in Option Type: Value 1 indicates that this is an extended
			option. If the 'X' flag is set, a 1 byte Option Flags follows the
			Option Length field.
			Option Length: 8-bit unsigned integer, representing the length in
			octets of the option, not including the Option Type and Length
			fields. Option Flags and variable length Option Data fields are
			included in the length.
			'J' (Join) bit in Option Flags: A node MUST join only as a 6LN if
			the Option Type is not understood.
			'C' (Copy) bit in Option Flags: A node which does not understand
			the Option Type MUST copy the Option while generating the
			corresponding message. For e.g., if a 6LR receives a DIO message
			with an unknown Option with 'C' bit set and if the 6LR choses to
			accept this node as the preferred parent then the node MUST copy
			this option in the subsequent DIO message it generates.
			Alternatively, if the 'C' flag is unset the node MUST strip off
			the option and process the message.
			'I' (Ignore) bit in Option Flags: A node which does not understand
			the Option Type MUST ignore this whole message if the 'I' bit is
			set. If 'I' bit is set than the value of 'J' and 'C' bits are
			irrelevant and the message MUST be ignored.
			Note that this format does not deprecate the previous format, it
			simply extends it and the new format is applicable only when 2nd bit
			('X' flag) of the Option Type is set. Option Type 0x40 to 0x7F are
			thus applicable only as extended options.
			+---------+---------+-----------------------------------------------+
			| 'J' bit | 'C' bit | Handling |
			+---------+---------+-----------------------------------------------+
			| 0 | 0 | Strip off the option, and the node can join |
			| | | as 6LR |
			| 0 | 1 | Copy the option, and the node can join as 6LR |
			| 1 | NA | Join as 6LN |
			+---------+---------+-----------------------------------------------+
			Table 1: Option Flags handling
			If a node receives an unknown Option without 'X' flag set then the
			node MUST ignore the option and process the message. The option MUST
			be treated as if J=0, C=0, I=0.
			5. Implementation Considerations
	[RFC6550], it was possible to discard an unsupported DIO-MOP just by		[RFC6550], it was possible to discard an unsupported DIO-MOP just by
	inspecting the base message. With this document, the MOPex is a		inspecting the base message. With this document, the MOPex is a
	different control message option and thus the discarding of the DIO		different control message option and thus the discarding of the DIO
	message could happen after inspecting the message options.		message could happen after inspecting the message options.
	5. Acknowledgements		6. Acknowledgements
	6. IANA Considerations		Using 'I' bit was Pascal Thubert's idea.
	6.1. Mode of operation: MOPex		7. IANA Considerations
			7.1. Mode of operation: MOPex
	IANA is requested to assign a new Mode of Operation, named "MOPex"		IANA is requested to assign a new Mode of Operation, named "MOPex"
	for MOP extension under the RPL registry. The value of 7 is to be		for MOP extension under the RPL registry. The value of 7 is to be
	assigned from the "Mode of Operation" space [RFC6550]		assigned from the "Mode of Operation" space [RFC6550]
	+-------+-------------+---------------+		+-------+-------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------+---------------+		+-------+-------------+---------------+
	| 7 | MOPex | This document |		| 7 | MOPex | This document |
	+-------+-------------+---------------+		+-------+-------------+---------------+
	Mode of Operation		Mode of Operation
	6.2. New options: MOPex and Capabilities		7.2. New options: MOPex and Capabilities
	A new entry is required for supporting new option "MOPex" in the "RPL		A new entry is required for supporting new option "MOPex" in the "RPL
	Control Message Options" space [RFC6550].		Control Message Options" space [RFC6550].
	+-------+---------+---------------+		+-------+---------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+---------+---------------+		+-------+---------+---------------+
	| TBD1 | MOPex | This document |		| TBD1 | MOPex | This document |
	+-------+---------+---------------+		+-------+---------+---------------+
	New options		New options
	6.3. New Registry for Extended-MOP-value		7.3. New Registry for Extended-MOP-value
	IANA is requested to create a registry for the extended-MOP-value		IANA is requested to create a registry for the extended-MOP-value
	(MOPex). This registry should be located in TODO. New MOPex values		(MOPex). This registry should be located in TODO. New MOPex values
	may be allocated only by an IETF review. Currently no values are		may be allocated only by an IETF review. Currently no values are
	defined by this document. Each value is tracked with the following		defined by this document. Each value is tracked with the following
	qualities:		qualities:
	o MOPex value		o MOPex value
	o Description		o Description
	o Defining RFC		o Defining RFC
	7. Security Considerations		8. Security Considerations
	The options defined in this document are carried in the base message		The options defined in this document are carried in the base message
	objects as defined in [RFC6550]. The RPL control message options are		objects as defined in [RFC6550]. The RPL control message options are
	protected by the same security mechanisms that protect the base		protected by the same security mechanisms that protect the base
	messages.		messages.
	Capabilities flag can reveal that the node has been upgraded or is		Capabilities flag can reveal that the node has been upgraded or is
	running a old feature set. This document assumes that the base		running a old feature set. This document assumes that the base
	messages that carry these options are protected by RPL security		messages that carry these options are protected by RPL security
	mechanisms and thus are not visible to a malicious node.		mechanisms and thus are not visible to a malicious node.
	8. References		9. References
	8.1. Normative References		9.1. 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>.
	[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>.
	8.2. Informative References		9.2. Informative References
	[I-D.ietf-roll-capabilities]		[I-D.ietf-roll-capabilities]
	Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo,		Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo,
	"RPL Capabilities", draft-ietf-roll-capabilities-02 (work		"RPL Capabilities", draft-ietf-roll-capabilities-06 (work
	in progress), March 2020.		in progress), June 2020.
	Authors' Addresses		Authors' Addresses
	Rahul Arvind Jadhav (editor)		Rahul Arvind Jadhav (editor)
	Huawei Tech		Huawei Tech
	Kundalahalli Village, Whitefield,		Kundalahalli Village, Whitefield,
	Bangalore, Karnataka 560037		Bangalore, Karnataka 560037
	India		India
	Phone: +91-080-49160700		Phone: +91-080-49160700
End of changes. 20 change blocks.
	29 lines changed or deleted		108 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/