< draft-ietf-roll-enrollment-priority-03.txt		draft-ietf-roll-enrollment-priority-04.txt >
	ROLL Working Group M. Richardson		ROLL Working Group M. Richardson
	Internet-Draft Sandelman Software Works		Internet-Draft Sandelman Software Works
	Intended status: Standards Track R. Jadhav		Intended status: Standards Track R.A. Jadhav
	Expires: March 29, 2021 Huawei Tech		Expires: 11 August 2021 Huawei Tech
	September 25, 2020		P. Thubert
			H. She
			Cisco Systems
			7 February 2021
	Controlling Secure Network Enrollment in RPL networks		Controlling Secure Network Enrollment in RPL networks
	draft-ietf-roll-enrollment-priority-03		draft-ietf-roll-enrollment-priority-04
	Abstract		Abstract
	[I-D.ietf-6tisch-enrollment-enhanced-beacon] defines a method by		[I-D.ietf-6tisch-enrollment-enhanced-beacon] defines a method by
	which a potential [I-D.ietf-6tisch-minimal-security] enrollment proxy		which a potential [I-D.ietf-6tisch-minimal-security] enrollment proxy
	can announce itself as a available for new Pledges to enroll on a		can announce itself as a available for new Pledges to enroll on a
	network. The announcement includes a priority for enrollment. This		network. The announcement includes a priority for enrollment. This
	document provides a mechanism by which a RPL DODAG root can disable		document provides a mechanism by which a RPL DODAG root can disable
	enrollment announcements, or adjust the base priority for enrollment		enrollment announcements, or adjust the base priority for enrollment
	operation.		operation.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 40 ¶
	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 March 29, 2021.		This Internet-Draft will expire on 11 August 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	carefully, as they describe your rights and restrictions with respect		Please review these documents carefully, as they describe your rights
	to this document. Code Components extracted from this document must		and restrictions with respect to this document. Code Components
	include Simplified BSD License text as described in Section 4.e of		extracted from this document must include Simplified BSD License text
	the Trust Legal Provisions and are provided without warranty as		as described in Section 4.e of the Trust Legal Provisions and are
	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
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Upwards compatibility . . . . . . . . . . . . . . . . . . 4		2.1. Upwards compatibility . . . . . . . . . . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 5		3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6		4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 7		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Change history . . . . . . . . . . . . . . . . . . . 8		Appendix A. Change history . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	[RFC7554] describes the use of the time-slotted channel hopping		[RFC7554] describes the use of the time-slotted channel hopping
	(TSCH) mode of [ieee802154]. [I-D.ietf-6tisch-minimal-security] and		(TSCH) mode of [ieee802154]. [I-D.ietf-6tisch-minimal-security] and
	[I-D.ietf-6tisch-dtsecurity-secure-join] describe mechanisms by which		[I-D.ietf-6tisch-dtsecurity-secure-join] describe mechanisms by which
	a new node (the "pledge)" can use a friendly router as a Join Proxy.		a new node (the "pledge)" can use a friendly router as a Join Proxy.
	[I-D.ietf-6tisch-enrollment-enhanced-beacon] describes an extension		[I-D.ietf-6tisch-enrollment-enhanced-beacon] describes an extension
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 30 ¶
	into the best effort part of a (TSCH) network, it would be better to		into the best effort part of a (TSCH) network, it would be better to
	have the enrollment process off when no new nodes are expected.		have the enrollment process off when no new nodes are expected.
	A network operator might also be able to recognize when certain parts		A network operator might also be able to recognize when certain parts
	of the network are overloaded and can not accomodate additional		of the network are overloaded and can not accomodate additional
	enrollment traffic, and it would like to adjust the enrollment		enrollment traffic, and it would like to adjust the enrollment
	priority (the proxy priority field of		priority (the proxy priority field of
	[I-D.ietf-6tisch-enrollment-enhanced-beacon]) among all nodes in the		[I-D.ietf-6tisch-enrollment-enhanced-beacon]) among all nodes in the
	subtree of a congested link.		subtree of a congested link.
	This document describes an RPL DIO option that can be used to		This document describes a RPL DIO option that can be used to announce
	announce a minimum enrollment priority. Each potential _Join Proxy_		a minimum enrollment priority. The minimum priority expresses the
	would this value as a base on which to add values relating to local		(lack of) willingness by the RPL DODAG globally to accept new joins.
	conditions. As explained in		It may derive from multiple constaining factors, e.g., the size of
	[I-D.ietf-6tisch-enrollment-enhanced-beacon], higher values decrease		the DODAG, the occupancy of the bandwidth at the Root, the memory
	the likelyhood of an unenrolled node sending enrollment traffic via		capacity at the DODAG Root, or an administrative decision.
	this path.
			Each potential _Join Proxy_ would this value as a base on which to
			add values relating to local conditions such as its Rank and number
			of pending joins, which would degrade even further the willingness to
			take more joins.
			When a RPL domain is composed of multiple DODAGs, nodes at the edge
			of 2 DODAGs may not only join either DODAG but also move from one to
			the other in order to keep their relative sizes balanced. For this,
			the approximate knowledge of size of the DODAG is an essential
			metric. Depending on the network policy, the size of the DODAG may
			or may not affect the minimum enrollment priority. It would be
			limiting its value to enforce that one is proportional to the other.
			This is why the current size of the DODAG is advertised separately in
			the new option.
			As explained in [I-D.ietf-6tisch-enrollment-enhanced-beacon], higher
			values decrease the likelyhood of an unenrolled node sending
			enrollment traffic via this path.
	A network operator can set this value to the maximum value allowed,		A network operator can set this value to the maximum value allowed,
	effectively disable all new enrollment traffic.		effectively disable all new enrollment traffic.
	1.1. Terminology		1.1. 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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Protocol Definition		2. Protocol Definition
	The following option is defined to transmission in the DIO issued by		The size of the DODAG is measured by the Root based one the DAO
	the DODAG root. It may also be added by a router on part of the sub-		activity. It represents a number of routes not a number of nodes,
	tree as a result of some (out of scope for this document) management		and can only be used to infer a load in an homogeneous network where
	function.		each node advertises the same number of addresses and generates
			roughly the same amount of traffic. The size may slightly change
			between a DIO and the next, so the value transmitted must be
			considered as an approxmation.
	6LRs that see this DIO Option SHOULD increment their minimum		With this specification, the following option is defined for
	enrollment priority if they observe congestion on the channel used		transmission in the DIO issued by the DODAG root and it MUST be
	for enrollment traffic. The exact mechanism is a local decision, and		propagated down the DODAG without modification.
	may be the subject for future work.
	A 6LR which would otherwise be willing to act as a _Join Proxy_, will		A 6LR which would otherwise be willing to act as a _Join Proxy_, will
	examine the minimum priority field, and to that number, add any		examine the minimum priority field, and to that number, add any
	additional local consideration (such as upstream congestion).		additional local consideration (such as upstream congestion).
	The Enrollment Priority can only be increased by each 6LR in value,		The Enrollment Priority can only be increased by each 6LR in value,
	to the maximum value of 0x7f.		to the maximum value of 0x7f.
	The resulting priority, if less than 0x7f should enable the _Join		The resulting priority, if less than 0x7f should enable the _Join
	Proxy_ function.		Proxy_ function.
	0 1 2		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		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 = TBD01|Opt Length = 1|R| min. priority |		| Type |Opt Length = 3 | exp | DODAG_Size |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|R| min priority|
			+-+-+-+-+-+-+-+-+
			Type To be assigned by IANA
			exp a 4 bit unsigned integer, indicating the power of 2 that defines
			the unit of the DODAG Size, such that (unit=2^exp).
			DODAG_Size a 12 bit unsigned integer, expressing the size of the
			DODAG in units that depend on the exp field. The size of the
			DODAG is computed as (DAG_Size*2^exp).
	min.priority a 7 bit field which provides a base value for the		min.priority a 7 bit field which provides a base value for the
	Enhanced Beacon Join priority. A value of 0x7f (127) disables the		Enhanced Beacon Join priority. A value of 0x7f (127) disables the
	_Join Proxy_ function entirely.		_Join Proxy_ function entirely.
	R a reserved bit that SHOULD be set to 0 by senders, and MUST be		R a reserved bit that SHOULD be set to 0 by senders, and MUST be
	ignored by receivers. This reserved bit SHOULD be copied to		ignored by receivers. This reserved bit SHOULD be copied to
	options created.		options created.
	This document uses the extensions mechanism designed into [RFC6550].		This document uses the extensions mechanism designed into [RFC6550].
	skipping to change at page 6, line 37 ¶		skipping to change at page 7, line 16 ¶
	This has been reviewed by Pascal Thubert and Thomas Wattenye.		This has been reviewed by Pascal Thubert and Thomas Wattenye.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-6tisch-enrollment-enhanced-beacon]		[I-D.ietf-6tisch-enrollment-enhanced-beacon]
	Dujovne, D. and M. Richardson, "IEEE 802.15.4 Information		Dujovne, D. and M. Richardson, "IEEE 802.15.4 Information
	Element encapsulation of 6TiSCH Join and Enrollment		Element encapsulation of 6TiSCH Join and Enrollment
	Information", draft-ietf-6tisch-enrollment-enhanced-		Information", Work in Progress, Internet-Draft, draft-
	beacon-14 (work in progress), February 2020.		ietf-6tisch-enrollment-enhanced-beacon-14, 21 February
			2020, <http://www.ietf.org/internet-drafts/draft-ietf-
			6tisch-enrollment-enhanced-beacon-14.txt>.
	[I-D.ietf-6tisch-minimal-security]		[I-D.ietf-6tisch-minimal-security]
	Vucinic, M., Simon, J., Pister, K., and M. Richardson,		Vucinic, M., Simon, J., Pister, K., and M. Richardson,
	"Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-		"Constrained Join Protocol (CoJP) for 6TiSCH", Work in
	6tisch-minimal-security-15 (work in progress), December		Progress, Internet-Draft, draft-ietf-6tisch-minimal-
	2019.		security-15, 10 December 2019, <http://www.ietf.org/
			internet-drafts/draft-ietf-6tisch-minimal-security-
			15.txt>.
	[ieee802154]		[ieee802154]
	IEEE standard for Information Technology, ., "IEEE Std.		IEEE standard for Information Technology, ., "IEEE Std.
	802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)		802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
	and Physical Layer (PHY) Specifications for Low-Rate		and Physical Layer (PHY) Specifications for Low-Rate
	Wireless Personal Area Networks", n.d.,		Wireless Personal Area Networks", n.d.,
	<http://standards.ieee.org/findstds/		<http://standards.ieee.org/findstds/
	standard/802.15.4-2015.html>.		standard/802.15.4-2015.html>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 7, line 35 ¶		skipping to change at page 8, line 23 ¶
	Internet of Things (IoT): Problem Statement", RFC 7554,		Internet of Things (IoT): Problem Statement", RFC 7554,
	DOI 10.17487/RFC7554, May 2015,		DOI 10.17487/RFC7554, May 2015,
	<https://www.rfc-editor.org/info/rfc7554>.		<https://www.rfc-editor.org/info/rfc7554>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-29 (work
	in progress), August 2020.
	[I-D.ietf-6tisch-dtsecurity-secure-join]		[I-D.ietf-6tisch-dtsecurity-secure-join]
	Richardson, M., "6tisch Secure Join protocol", draft-ietf-		Richardson, M., "6tisch Secure Join protocol", Work in
	6tisch-dtsecurity-secure-join-01 (work in progress),		Progress, Internet-Draft, draft-ietf-6tisch-dtsecurity-
	February 2017.		secure-join-01, 25 February 2017, <http://www.ietf.org/
			internet-drafts/draft-ietf-6tisch-dtsecurity-secure-join-
	[I-D.ietf-6tisch-terminology]		01.txt>.
	Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
	"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
	draft-ietf-6tisch-terminology-10 (work in progress), March
	2018.
	[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-07 (work		"RPL Capabilities", Work in Progress, Internet-Draft,
	in progress), September 2020.		draft-ietf-roll-capabilities-07, 17 September 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-roll-
	[RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information		capabilities-07.txt>.
	Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
	2017, <https://www.rfc-editor.org/info/rfc8137>.
	[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
	"A Voucher Artifact for Bootstrapping Protocols",
	RFC 8366, DOI 10.17487/RFC8366, May 2018,
	<https://www.rfc-editor.org/info/rfc8366>.
	Appendix A. Change history		Appendix A. Change history
	version 00.		version 00.
	Authors' Addresses		Authors' Addresses
	Michael Richardson		Michael Richardson
	Sandelman Software Works		Sandelman Software Works
	Email: mcr+ietf@sandelman.ca		Email: mcr+ietf@sandelman.ca
	Rahul Arvind Jadhav		Rahul Arvind Jadhav
	Huawei Tech		Huawei Tech
	Email: rahul.ietf@gmail.com		Email: rahul.ietf@gmail.com
			Pascal Thubert
			Cisco Systems
			Email: pthubert@cisco.com
			Huimin She
			Cisco Systems
			Email: hushe@cisco.com
End of changes. 18 change blocks.
	71 lines changed or deleted		92 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/