< draft-ietf-roll-capabilities-05.txt		draft-ietf-roll-capabilities-06.txt >
	ROLL R. Jadhav, Ed.		ROLL R. Jadhav, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: November 22, 2020 Cisco		Expires: December 5, 2020 Cisco
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	R. Sahoo		R. Sahoo
	Juniper		Juniper
	May 21, 2020		June 3, 2020
	RPL Capabilities		RPL Capabilities
	draft-ietf-roll-capabilities-05		draft-ietf-roll-capabilities-06
	Abstract		Abstract
	This draft enables the discovery, advertisement and query of		This draft enables the discovery, advertisement and query of
	capabilities for RPL nodes.		capabilities for RPL nodes.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 22, 2020.		This Internet-Draft will expire on December 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language and Terminology . . . . . . . . . . 3		1.1. Requirements Language and Terminology . . . . . . . . . . 3
	1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3		1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 4
	2. Requirements for this document . . . . . . . . . . . . . . . 4		2. Requirements for this document . . . . . . . . . . . . . . . 4
	2.1. How are Capabilities different from existing RPL		2.1. How are Capabilities different from existing RPL
	primitives? . . . . . . . . . . . . . . . . . . . . . . . 4		primitives? . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Capability Control Message Option . . . . . . . . . . . . 5		3.1. Capability Control Message Option . . . . . . . . . . . . 5
	3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5		3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 6
	4. Guidelines for defining new capabilities . . . . . . . . . . 6		4. Querying Capabilities . . . . . . . . . . . . . . . . . . . . 6
	4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6		4.1. Capability Query (CAPQ) . . . . . . . . . . . . . . . . . 6
	4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6		4.1.1. Capability Type List Control Option . . . . . . . . . 7
	5. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 6		4.1.2. Secure CAPQ . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7		4.1.3. Base rules for CAPQ handling . . . . . . . . . . . . 7
	5.1.1. Format of Capability Indicators . . . . . . . . . . . 7		4.2. Capability Set Response (CAPS) . . . . . . . . . . . . . 7
	5.2. Routing Resource Capability . . . . . . . . . . . . . . . 7		4.2.1. Secure CAPS . . . . . . . . . . . . . . . . . . . . . 8
	5.2.1. Format of Routing Resource Capability . . . . . . . . 8		5. Guidelines for defining new capabilities . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		5.1. Handling Capability flags . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5.1.1. Rules to handle capabilities flag . . . . . . . . . . 9
	7.1. New option: Capabilities . . . . . . . . . . . . . . . . 8		6. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 9
	7.2. New Registry for Capabilities Flags . . . . . . . . . . . 9		6.1. Capability Indicators . . . . . . . . . . . . . . . . . . 9
	7.3. New Registry for Capabilities Indicators . . . . . . . . 9		6.1.1. Format of Capability Indicators . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6.2. Routing Resource Capability . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.2.1. Format of Routing Resource Capability . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	Appendix A. Capability Handshake Example . . . . . . . . . . . . 11		8.1. New option: Capabilities . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		8.2. Capability Sub-Type . . . . . . . . . . . . . . . . . . . 11
			8.3. New Registry for CAPQ Flags . . . . . . . . . . . . . . . 12
			8.4. New Registry for Capabilities Flags . . . . . . . . . . . 12
			8.5. New Registry for Capabilities Indicators . . . . . . . . 12
			9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
			10.1. Normative References . . . . . . . . . . . . . . . . . . 13
			10.2. Informative References . . . . . . . . . . . . . . . . . 13
			Appendix A. Capability Handshake Example . . . . . . . . . . . . 14
			A.1. Query supported Cap Types . . . . . . . . . . . . . . . . 14
			A.2. Query specific Cap Set . . . . . . . . . . . . . . . . . 14
			A.3. CAPS with partial Cap Set . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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.
	This document adds a notion of capabilities using which nodes in the		This document adds a notion of capabilities using which nodes in the
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 32 ¶
	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 MOP of the RPL Instance as		MOP: Mode of Operation. Identifies the MOP of the RPL Instance as
	administratively provisioned at and distributed by the DODAG root.		administratively provisioned at and distributed by the DODAG root.
	MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].		MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].
	Capabilities: Additional features or capabilities that are supported		Capabilities: Additional features or capabilities that are supported
	by the node.		by the node.
			Cap: Abbreviated term used for Capability.
			Caps: Abbreviated term used for Capabilities.
	DAO: DODAG Advertisement Object. An RPL message used to advertise		DAO: DODAG Advertisement Object. An RPL message used to advertise
	the target information in order to establish routing adjacencies.		the target information in order to establish routing adjacencies.
	DIO: DODAG Information Object. An RPL message initiated by the root		DIO: DODAG Information Object. An RPL message initiated by the root
	and is used to advertise the network configuration information.		and is used to advertise the network configuration information.
	Current parent: Parent 6LR node before switching to the new path.		Current parent: Parent 6LR node before switching to the new path.
	NPDAO: No-Path DAO. A DAO message which has target with lifetime 0.		NPDAO: No-Path DAO. A DAO message which has target with lifetime 0.
	skipping to change at page 3, line 47 ¶		skipping to change at page 4, line 17 ¶
	section.		section.
	1.2. What are Capabilities?		1.2. What are Capabilities?
	Currently RPL specification does not have a mechanism whereby a node		Currently RPL specification does not have a mechanism whereby a node
	can signal the set of features that are available on its end. Such a		can signal the set of features that are available on its end. Such a
	mechanism could help the root to advertise its capabilities and in		mechanism could help the root to advertise its capabilities and in
	response also determine some advanced information about the		response also determine some advanced information about the
	capabilities of the joining nodes. This document defines		capabilities of the joining nodes. This document defines
	Capabilities which could be supported by the nodes and handshaked as		Capabilities which could be supported by the nodes and handshaked as
	part of RPL signaling. Capabilities are embedded as RPL control		part of RPL signaling. Capabilities are embedded as an RPL Control
	message option as defined Section 6.7 of [RFC6550] in the base		Message Option as defined in Section 6.7 of [RFC6550].
	messages of DIO, DAO and DAO-ACK signaling.
	2. Requirements for this document		2. Requirements for this document
	Following are the requirements considered for this documents:		Following are the requirements considered for this documents:
	REQ1: Backwards compatibility. The new options and new fields in		REQ1: Backwards compatibility. The new options and new fields in
	the DIO message should be backward compatible i.e. if there		the DIO message should be backward compatible i.e. if there
	are nodes which support old MOPs they could still operate in		are nodes which support old MOPs they could still operate in
	their own instances.		their own instances.
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 25 ¶
	advertised by non-root nodes are strictly a subset of the		advertised by non-root nodes are strictly a subset of the
	capabilities advertised by the root.		capabilities advertised by the root.
	In storing MOP, the DAO message from the 6LR could contain multiple		In storing MOP, the DAO message from the 6LR could contain multiple
	target options because of the DAO-Aggregation. The targets of the		target options because of the DAO-Aggregation. The targets of the
	capabilities option are indicated by one or more Target options that		capabilities option are indicated by one or more Target options that
	precede the Capabilities Option. This handling is similar to the		precede the Capabilities Option. This handling is similar to the
	Transit Information Option as supported in Section 6.7.8. of		Transit Information Option as supported in Section 6.7.8. of
	[RFC6550].		[RFC6550].
	4. Guidelines for defining new capabilities		4. Querying Capabilities
			Nodes may be interested in knowing the capabilities of another node
			before taking an action. For e.g., Consider
			[I-D.ietf-roll-dao-projection], the Root may want to know the
			capabilities of the nodes along a network segment before it initiates
			a projected DAO to install the routes along that segment.
			Caps can be carried in existing RPL Control messages as Control
			Options, however Caps can also be queried explicitly. This section
			provides a way for a node to query capability set of another node.
			The capability query and subsequent response messages are directly
			addressed between the two peers.
			4.1. Capability Query (CAPQ)
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| RPLInstanceID | Flags | reserved | CAPQSequence |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Option(s)...
			+-+-+-+-+-+-+-+-+
			Figure 3: CAPQ base object
			CAPQSequence: One byte, Sequence number sent by the CAPQ sender
			which is reflected back by the responder in the CAPS message.
			Flags: One byte, set to zero by sender, ignored by receiver.
			reserved: One byte, set to zero by sender, ignored by receiver.
			CAPQ base object may be followed by one or more options. The
			Capability Type List Control Option Figure 4 is used to carry a set
			of capability types to query about.
			If the sender does not send Figure 4 option, this would indicate that
			the node intends to query the capability type list Figure 4 supported
			by the target node.
			4.1.1. Capability Type List Control Option
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type = TODO | Option Length | CapType1 | CapType2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| CapType3 | .....
			+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: Capability Type List Control Option
			4.1.2. Secure CAPQ
			A Secure CAPQ message follows the format in [RFC6550] Figure 7, where
			the base message format is the CAPQ message shown in Figure 3.
			4.1.3. Base rules for CAPQ handling
			A CAPQ message may get dropped or lost in the transit. The sender of
			CAPQ MAY retry the CAPQ message after some delay. The delay SHOULD
			NOT be less than 1 second.
			4.2. Capability Set Response (CAPS)
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| RPLInstanceID | Flags | Reserved | CAPQSequence |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Option(s)...
			+-+-+-+-+-+-+-+-+
			Figure 5: CAPS base object
			Flags: One byte, set to zero by sender, ignored by receiver.
			reserved: One byte, set to zero by sender, ignored by receiver.
			CAPQSequence: One byte, Sequence number copied from CAPQSequence
			received in the CAPQ message.
			CAPS message SHOULD contain the capability set Figure 1 queried by
			the CAPQ sender. If the target node does not support subset of the
			queried capabilities then the Figure 4 option with the unsupported
			cap-types SHOULD be sent back indicating the queried capabilities
			not-supported by the target node. For an example, check Appendix A.3
			If the CAPQ message does not contain any Figure 4 option then the
			receiver MUST respond with the cap types it supports using Figure 4.
			If the capability set cannot be transmitted in a single message (for
			e.g., because of MTU limitations) then multiple CAPS messages could
			be used. All the CAPS message MUST use the same CAPQSequence number
			copied from the corresponding CAPQ message.
			4.2.1. Secure CAPS
			A Secure CAPS message follows the format in [RFC6550] Figure 7, where
			the base message format is the CAPS message shown in Figure 5.
			5. Guidelines for defining new capabilities
	This section provides guidelines/recommendations towards defining new		This section provides guidelines/recommendations towards defining new
	capabilities. Note that the capabilities might be carried as part of		capabilities. Note that the capabilities might be carried as part of
	the multicast messaging such as DIO and hence the set should be used		the multicast messaging such as DIO and hence the set should be used
	in restrictive manner as far as possible.		in restrictive manner as far as possible.
	4.1. Handling Capability flags		5.1. Handling Capability flags
	A node MUST drop or discard the message with an unknown capability		A node MUST drop or discard the message with an unknown capability
	with 'D' flag set. The message MUST be discarded silently.		with 'D' flag set. The message MUST be discarded silently.
	The 'J' (join) flag can be set in context to a capability either by a		The 'J' (join) flag can be set in context to a capability either by a
	6LR or the root. The 'J' flag indicates that if the capability is		6LR or the root. The 'J' flag indicates that if the capability is
	not supported by a node then it can join the instance only as a 6LN		not supported by a node then it can join the instance only as a 6LN
	(or do not join as 6LR).		(or do not join as 6LR).
	The 'C' (copy) flag is set by the node indicating that the		The 'C' (copy) flag is set by the node indicating that the
	capabilities MUST be copied downstream by the node even if the node		capabilities MUST be copied downstream by the node even if the node
	does not understand the capability.		does not understand the capability.
	4.1.1. Rules to handle capabilities flag		5.1.1. Rules to handle capabilities flag
	On receiving a capability it does not support, the node MUST check		On receiving a capability it does not support, the node MUST check
	the 'J' flag of the capability before joining the Instance. If the		the 'J' flag of the capability before joining the Instance. If the
	'J' flag is set then it can only join as a 6LN.		'J' flag is set then it can only join as a 6LN.
	If the node is operating as 6LR and subsequently it receives a		If the node is operating as 6LR and subsequently it receives a
	capability from its preferred parent which it does not understand		capability from its preferred parent which it does not understand
	with 'J' flag set, then the node has to switch itself to 6LN mode.		with 'J' flag set, then the node has to switch itself to 6LN mode.
	During switching the node needs to inform its downstream peers of its		During switching the node needs to inform its downstream peers of its
	changed status by sending a DIO with infinite rank as mentioned in		changed status by sending a DIO with infinite rank as mentioned in
	RFC6550. Alternatively, a node may decide to switch to another		RFC6550. Alternatively, a node may decide to switch to another
	parent with compatible and known capabilities.		parent with compatible and known capabilities.
	Capabilities are used to indicate a feature that is supported by the		Capabilities are used to indicate a feature that is supported by the
	node. Capabilities are not meant for configuration management for		node. Capabilities are not meant for configuration management for
	e.g., setting a threshold.		e.g., setting a threshold.
	5. Node Capabilities		6. Node Capabilities
	5.1. Capability Indicators
			6.1. Capability Indicators
	Capability Indicators indicates the capabilities supported by the		Capability Indicators indicates the capabilities supported by the
	node in the form of simple flags. Capabilities who do not have		node in the form of simple flags. Capabilities who do not have
	additional information to be specified could make use of these flags		additional information to be specified could make use of these flags
	to indicate their support.		to indicate their support.
	5.1.1. Format of Capability Indicators		6.1.1. Format of Capability Indicators
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CapType=0x01 | Len |J|I|C| Flags |T|..Indicators..		| CapType=0x01 | Len |J|I|C| Flags |T|..Indicators..
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Capability Indicators TLV		Figure 6: Capability Indicators TLV
	Flags: LRs MUST set it to 0. I bit will always be set to 0.		Flags: LRs MUST set it to 0. I bit will always be set to 0.
	T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].		T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].
	5.2. Routing Resource Capability		6.2. Routing Resource Capability
	Storing mode of operation requires each intermediate router in the		Storing mode of operation requires each intermediate router in the
	LLN to maintain routing states' information in the routing table.		LLN to maintain routing states' information in the routing table.
	LLN routers typically operate with constraints on processing power,		LLN routers typically operate with constraints on processing power,
	memory, and energy (battery power). Memory limits the number of		memory, and energy (battery power). Memory limits the number of
	routing states an LR and BR can maintain. When the routing table of		routing states an LR and BR can maintain. When the routing table of
	an LR or BR is full, it will either reject the new DAO messages		an LR or BR is full, it will either reject the new DAO messages
	received or will use some replacement policy to remove a routing		received or will use some replacement policy to remove a routing
	entry and add the new one. Rejection of DAO messages will lead to an		entry and add the new one. Rejection of DAO messages will lead to an
	increase in DAO message transmission that impacts the energy and		increase in DAO message transmission that impacts the energy and
	skipping to change at page 8, line 5 ¶		skipping to change at page 10, line 21 ¶
	advertise their current routing table usage details in the network.		advertise their current routing table usage details in the network.
	LR or LNs in LLN can use this information in the selection of the DAO		LR or LNs in LLN can use this information in the selection of the DAO
	parent set. PCE can use this information to select intermediate		parent set. PCE can use this information to select intermediate
	routers for the projected routes. Routing Resource is an optional		routers for the projected routes. Routing Resource is an optional
	capability.		capability.
	Routing resource capabablity sent in DIO message has link local scope		Routing resource capabablity sent in DIO message has link local scope
	and it MUST not be forwarded. The 'C' bit of this capability MUST be		and it MUST not be forwarded. The 'C' bit of this capability MUST be
	set to 0.		set to 0.
	5.2.1. Format of Routing Resource Capability		6.2.1. Format of Routing Resource Capability
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CapType=0x02 | Len=3 |J|I|C| Flags | Reserved |		| CapType=0x02 | Len=3 |J|I|C| Flags | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total Capacity |		| Total Capacity |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Routing Resource Capability TLV		Figure 7: Routing Resource Capability TLV
	Type: 0x02.		Type: 0x02.
	Flags: I bit MUST be set to 0. C bit MUST be set to 0.		Flags: I bit MUST be set to 0. C bit MUST be set to 0.
	Len: 8-bit unsigned integer, representing the length in octets of the		Len: 8-bit unsigned integer, representing the length in octets of the
	option, not including the Option Type and Length/flags fields.		option, not including the Option Type and Length/flags fields.
	Resvd: 8-bit unused field. It MUST be initialized to zero by the		Resvd: 8-bit unused field. It MUST be initialized to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	Total Capacity: 16 bit unsigned integer representing the routing		Total Capacity: 16 bit unsigned integer representing the routing
	table size.		table size.
	6. Acknowledgements		7. Acknowledgements
	Thanks to Georgios Papadopoulos, Li Zhao for early review and		Thanks to Georgios Papadopoulos, Li Zhao for early review and
	feedback.		feedback.
	7. IANA Considerations		8. IANA Considerations
	7.1. New option: Capabilities		IANA is requested to allocate new codes for the CAPQ and CAPS
			messages from the RPL Control Codes registry.
	New entry is required for supporting new Capabilities option in the		+------+----------------------------+---------------+
	"RPL Control Message Options" space [RFC6550].		| Code | Description | Reference |
			+------+----------------------------+---------------+
			| TBD1 | Capability Query | This document |
			| TBD2 | Capability Response | This document |
			| TBD3 | Secure Capability Query | This document |
			| TBD4 | Secure Capability Response | This document |
			+------+----------------------------+---------------+
			New RPL Control Messages
			The MSB of the codes allocated to "Secure" messages above should be
			set.
			8.1. New option: Capabilities
			New entry is required for supporting new Capabilities option and new
			Capability Type List Option in the "RPL Control Message Options"
			space [RFC6550].
			+-------+-----------------------------+---------------+
			| Value | Meaning | Reference |
			+-------+-----------------------------+---------------+
			| TODO | Capability Option | This document |
			| TODO | Capability Type List Option | This document |
			+-------+-----------------------------+---------------+
			New options
			8.2. Capability Sub-Type
			IANA is requested to create a registry for the Capabilities Type as
			described in Figure 2 of this document. This registry should be
			located in TODO. New Capabilities types may be allocated only by an
			IETF review.
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	| 0x01 | Capability Indicators | This document |		| 0x01 | Capability Indicators | This document |
	| 0x02 | Routing Resource Capability | This document |		| 0x02 | Routing Resource Capability | This document |
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	New options		Type
	7.2. New Registry for Capabilities Flags		8.3. New Registry for CAPQ Flags
			IANA is requested to create a registry for the Capabilities flags as
			described in Section 4.1 of this document. This registry should be
			located in TODO. New Capabilities flags may be allocated only by an
			IETF review. Currently no flags are defined by this document. Each
			value is tracked with the following qualities:
			o Flag
			o Description
			o Defining RFC
			8.4. New Registry for Capabilities Flags
	IANA is requested to create a registry for the Capabilities flags as		IANA is requested to create a registry for the Capabilities flags as
	described in Section 2.1 of this document. This registry should be		described in Section 2.1 of this document. This registry should be
	located in TODO. New Capabilities flags may be allocated only by an		located in TODO. New Capabilities flags may be allocated only by an
	IETF review. Currently no flags are defined by this document. Each		IETF review. Currently no flags are defined by this document. Each
	value is tracked with the following qualities:		value is tracked with the following qualities:
	o Flag		o Flag
	o Description		o Description
	o Defining RFC		o Defining RFC
	7.3. New Registry for Capabilities Indicators		8.5. New Registry for Capabilities Indicators
	IANA is requested to create a registry for the Capabilities		IANA is requested to create a registry for the Capabilities
	Indicators as described in Section 5.1 of this document. This		Indicators as described in Section 6.1 of this document. This
	registry should be located in TODO. New Capabilities indicators may		registry should be located in TODO. New Capabilities indicators may
	be allocated only by an IETF review. Each value is tracked with the		be allocated only by an IETF review. Each value is tracked with the
	following qualities:		following qualities:
	o Flag		o Flag
	o Description		o Description
	o Defining RFC		o Defining RFC
	8. Security Considerations		9. 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.
	[TODO] implications of malicious attack involving setting the		[TODO] implications of malicious attack involving setting the
	capability flags.		capability flags.
	9. References		10. References
	9.1. Normative References
			10.1. Normative References
	[I-D.ietf-roll-mopex]		[I-D.ietf-roll-mopex]
	Jadhav, R., Thubert, P., and M. Richardson, "Mode of		Jadhav, R., Thubert, P., and M. Richardson, "Mode of
	Operation extension", draft-ietf-roll-mopex-00 (work in		Operation extension", draft-ietf-roll-mopex-00 (work in
	progress), April 2020.		progress), April 2020.
	[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 10, line 28 ¶		skipping to change at page 13, line 47 ¶
	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>.
	[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>.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-lwig-nbr-mgmt-policy]		[I-D.ietf-lwig-nbr-mgmt-policy]
	Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,		Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,
	"Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-		"Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-
	nbr-mgmt-policy-03 (work in progress), February 2019.		nbr-mgmt-policy-03 (work in progress), February 2019.
	[I-D.ietf-roll-dao-projection]		[I-D.ietf-roll-dao-projection]
	Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated		Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated
	routing state in RPL", draft-ietf-roll-dao-projection-10		routing state in RPL", draft-ietf-roll-dao-projection-10
	(work in progress), May 2020.		(work in progress), May 2020.
	skipping to change at page 11, line 7 ¶		skipping to change at page 14, line 28 ¶
	progress), July 2019.		progress), July 2019.
	[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,		[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
	and D. Barthel, "Routing Metrics Used for Path Calculation		and D. Barthel, "Routing Metrics Used for Path Calculation
	in Low-Power and Lossy Networks", RFC 6551,		in Low-Power and Lossy Networks", RFC 6551,
	DOI 10.17487/RFC6551, March 2012,		DOI 10.17487/RFC6551, March 2012,
	<https://www.rfc-editor.org/info/rfc6551>.		<https://www.rfc-editor.org/info/rfc6551>.
	Appendix A. Capability Handshake Example		Appendix A. Capability Handshake Example
	Root 6LR 6LN		A.1. Query supported Cap Types
	| | |
	| DIO(CS1) | |
	|------------>| DIO(CS1) |
	| |----------->|
	| | |
	| | DAO(CS2) |
	| |<-----------|
	| DAO(CS2) | |
	|<------------| |
	| | |
	CS: Capabilities Set
	CS1: Capabilities set advertised by root
	CS2: Capabilities set advertised by node. CS2 is a subset of CS1.
	Figure 5: Capabilities Option		Root 6LR/6LN
			| |
			| CAPQ(seq=1, opts=nil) |
			|---------------------------------->|
			| |
			| |
			| CAPS(seq=1, opts={CapTypeList}) |
			|<----------------------------------|
			| |
			Figure 8: Query supported Cap Types
			CAPQ message with no CapTypeList Option results in the peer
			responding with a CAPS message with CapTypeList Option indicating all
			the capability set it supports.
			A.2. Query specific Cap Set
			Root 6LR/6LN
			| |
			| CAPQ(seq=2, |
			| opts={CapTypeList=[Cap1, Cap2]})|
			|---------------------------------->|
			| |
			| |
			| CAPS(seq=2, |
			| opts={Cap1=Cap1Value, |
			| Cap2=Cap2Value}) |
			|<----------------------------------|
			| |
			Figure 9: Query specific Cap Set
			This flow indicates the case where the Root probes for specific
			Capabilities of the peer node and the peer node responds with the
			value of indicated Capability set.
			A.3. CAPS with partial Cap Set
			Root 6LR/6LN
			| |
			| CAPQ(seq=3, |
			| opts={CapTypeList=[Cap1, Cap2, |
			| Cap3, Cap4]})|
			|---------------------------------->|
			| |
			| |
			| CAPS(seq=3, |
			| opts={Cap2=Cap2Value, |
			| Cap3=Cap3Value, |
			| CapTypeList=[Cap1,Cap4]})|
			|<----------------------------------|
			| |
			Partial Capability Set handshake
			Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4}
			from the peer node. However the peer node does not support or does
			not understand capability {cap1, cap4}. In this case the peer node
			will respond back with value of Cap2 and Cap3 (which it understands)
			and set the CapTypeList option with {Cap1, Cap4} type.
	Authors' Addresses		Authors' Addresses
	Rahul Arvind Jadhav (editor)		Rahul Arvind Jadhav (editor)
	Huawei		Huawei
	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. 33 change blocks.
	69 lines changed or deleted		281 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/