rfc9032.original.xml		rfc9032.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->		nsus="true" docName="draft-ietf-6tisch-enrollment-enhanced-beacon-14" indexInclu
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">		de="true" ipr="trust200902" number="9032" prepTime="2021-05-29T09:25:40" scripts
	<?rfc toc="yes"?>		="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2
	<?rfc sortrefs="yes"?>		" tocInclude="true" xml:lang="en">
	<?rfc symrefs="yes"?>		<link href="https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enha
	<?rfc consensus="yes"?>		nced-beacon-14" rel="prev"/>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		<link href="https://dx.doi.org/10.17487/rfc9032" rel="alternate"/>
	-ietf-6tisch-enrollment-enhanced-beacon-14" category="std" obsoletes="" updates=		<link href="urn:issn:2070-1721" rel="alternate"/>
	"" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs
	="true" version="3">
	<!-- xml2rfc v2v3 conversion 2.39.0 -->
	<front>		<front>
	<title abbrev="IE for ICMPv6">IEEE 802.15.4 Information Element encapsulatio		<title abbrev="Enroll Beacon">Encapsulation of 6TiSCH Join and Enrollment In
	n of 6TiSCH Join and Enrollment Information</title>		formation Elements</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-enrollment-enhanc		<seriesInfo name="RFC" value="9032" stream="IETF"/>
	ed-beacon-14"/>		<author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="editor
	<author initials="D." surname="Dujovne" fullname="Diego Dujovne (editor)">		">
	<organization>Universidad Diego Portales</organization>		<organization showOnFrontPage="true">Universidad Diego Portales</organizat
			ion>
	<address>		<address>
	<postal>		<postal>
	<street>Escuela de Informatica y Telecomunicaciones, Av. Ejercito 441<		<street>Escuela de Informática y Telecomunicaciones</street>
	/street>		<street>Av. Ejército 441</street>
	<city>Santiago, Region Metropolitana</city>		<city>Santiago</city>
			<region>Región Metropolitana</region>
	<country>Chile</country>		<country>Chile</country>
	</postal>		</postal>
	<phone>+56 (2) 676-8121</phone>		<phone>+56 (2) 676-8121</phone>
	<email>diego.dujovne@mail.udp.cl</email>		<email>diego.dujovne@mail.udp.cl</email>
	</address>		</address>
	</author>		</author>
	<author initials="M." surname="Richardson" fullname="Michael Richardson">		<author initials="M." surname="Richardson" fullname="Michael Richardson">
	<organization>Sandelman Software Works</organization>		<organization showOnFrontPage="true">Sandelman Software Works</organizatio n>
	<address>		<address>
	<email>mcr+ietf@sandelman.ca</email>		<email>mcr+ietf@sandelman.ca</email>
	</address>		</address>
	</author>		</author>
	<date year="2020" month="February" day="21"/>		<date month="05" year="2021"/>
	<area>Internet</area>		<area>Internet</area>
	<workgroup>6tisch Working Group</workgroup>		<workgroup>6TiSCH</workgroup>
	<keyword>Internet-Draft</keyword>		<keyword>BRSKI</keyword>
	<abstract>		<keyword>enroll</keyword>
	<t>In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are lim		<keyword>zero-touch</keyword>
	ited to		<keyword>DODAG balancing</keyword>
	specific times and specific channels. Routers in a Time-Slotted Channel		<keyword>LLN balancing</keyword>
	Hopping (TSCH) network		<abstract pn="section-abstract">
			<t indent="0" pn="section-abstract-1">In the Time-Slotted Channel Hopping
			(TSCH) mode of IEEE Std 802.15.4,
			opportunities for broadcasts are limited to
			specific times and specific channels. Routers in a
			TSCH network
	transmit Enhanced Beacon (EB) frames to announce the presence of the		transmit Enhanced Beacon (EB) frames to announce the presence of the
	network. This document provides a mechanism by which additional information cri tical		network. This document provides a mechanism by which additional information cri tical
	for new nodes (pledges) and long sleeping nodes may be carried within the		for new nodes (pledges) and long-sleeping nodes may be carried within the
	Enhanced Beacon in order to conserve use of broadcast opportunities.</t>		EB in order to conserve use of broadcast opportunities.</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t indent="0" pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t indent="0" pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further
			information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t indent="0" pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc9032" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2021 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Simplified BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
			at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-introduction">Introduction</xref><
			/t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.1.2">
			<li pn="section-toc.1-1.1.2.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
			xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
			1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te
			rminology">Terminology</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
			xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
			2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-la
			yer-2-synchronization">Layer 2 Synchronization</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.3">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><
			xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.
			3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-la
			yer-3-synchronization-ipv">Layer 3 Synchronization: IPv6 Router Solicitations an
			d Advertisements</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.4">
			<t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent=
			"1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-layer-2-selection">Lay
			er 2 Selection</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
			at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-protocol-definition">Protocol Defi
			nition</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
			at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-security-considerations">Security
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-privacy-considerations">Privacy Co
			nsiderations</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
			ations</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.6.2">
			<li pn="section-toc.1-1.6.2.1">
			<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
			"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.2">
			<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
			"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" forma
			t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
			format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments
			</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" forma
			t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
			format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addr
			esses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
	<section anchor="problems" numbered="true" toc="default">		<section anchor="problems" numbered="true" toc="include" removeInRFC="false"
	<name>Introduction</name>		pn="section-1">
	<t><xref target="RFC7554" format="default"/> describes the use of the Time		<name slugifiedName="name-introduction">Introduction</name>
	-Slotted Channel Hopping (TSCH) mode of <xref target="ieee802154" format="defaul		<t indent="0" pn="section-1-1"><xref target="RFC7554" format="default" sec
	t"/>.</t>		tionFormat="of" derivedContent="RFC7554"/> describes the use of the Time-Slotted
	<t>In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are lim		Channel Hopping (TSCH) mode of <xref target="IEEE.802.15.4" format="default" se
	ited to		ctionFormat="of" derivedContent="IEEE.802.15.4"/>.</t>
			<t indent="0" pn="section-1-2">In TSCH mode of IEEE Std 802.15.4, opportun
			ities for broadcasts are limited to
	specific times and specific channels.		specific times and specific channels.
	Routers in a Time-Slotted Channel Hopping (TSCH) network		Routers in a TSCH network
	transmit Enhanced Beacon (EB) frames during broadcast slots in order to		transmit Enhanced Beacon (EB) frames during broadcast slots in order to
	announce the time and channel schedule.</t>		announce the time and channel schedule.</t>
	<t>This document defines a new IETF Information Element (IE) subtype to pl		<t indent="0" pn="section-1-3">This document defines a new IETF Informatio
	ace		n Element (IE) subtype to place
	into the Enhanced Beacon (EB) to provide join and enrollment information to pros		into the EB to provide join and enrollment information to prospective
	pective
	pledges in a more efficient way.</t>		pledges in a more efficient way.</t>
	<t>The following sub-sections explain the problem being solved, which		<t indent="0" pn="section-1-4">The following subsections explain the probl
	justify carrying the join and enrollement information in the EB.</t>		em being solved, which
	<section anchor="Terminology" numbered="true" toc="default">		justifies carrying the join and enrollment information in the EB.</t>
	<name>Use of BCP 14 Terminology</name>		<section anchor="Terminology" numbered="true" toc="include" removeInRFC="f
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		alse" pn="section-1.1">
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		<name slugifiedName="name-terminology">Terminology</name>
	"MAY", and "OPTIONAL" in this document are to be interpreted as		<t indent="0" pn="section-1.1-1">
	described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target=		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"RFC8174" format="default"/> when, and only when, they		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
	appear in all capitals, as shown here.</t>		D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	<t>Other terminology can be found in <xref target="I-D.ietf-6tisch-archi		OT RECOMMENDED</bcp14>",
	tecture" format="default"/> in section		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	2.1.</t>		be interpreted as
			described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
			f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
			mat="of" derivedContent="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
			<t indent="0" pn="section-1.1-2">Other terminology can be found in <xref
			target="RFC9030" sectionFormat="of" section="2.1" format="default" derivedLink=
			"https://rfc-editor.org/rfc/rfc9030#section-2.1" derivedContent="RFC9030"/>.</t>
	</section>		</section>
	<section anchor="layer-2-synchronization" numbered="true" toc="default">		<section anchor="layer-2-synchronization" numbered="true" toc="include" re
	<name>Layer-2 Synchronization</name>		moveInRFC="false" pn="section-1.2">
	<t>As explained in section 6 of <xref target="RFC8180" format="default"/		<name slugifiedName="name-layer-2-synchronization">Layer 2 Synchronizati
	>, the Enhanced Beacon (EB)		on</name>
	has a number of purposes: synchronization of the Absolute Slot Number (ASN) and		<t indent="0" pn="section-1.2-1">As explained in <xref target="RFC8180"
	Join Metric, carrying the timeslot template identifier, carrying the channel ho		sectionFormat="of" section="4.5.2" format="default" derivedLink="https://rfc-edi
	pping sequence identifier, and indicating the TSCH SlotFrame.</t>		tor.org/rfc/rfc8180#section-4.5.2" derivedContent="RFC8180"/>, the EB
	<t>An EB announces the existence of a TSCH network, and of the nodes		has a number of purposes: it carries synchronization information such as the
			Absolute Slot Number (ASN) and Join Metric and identifiers for
			the timeslot template and the channel hopping sequence, and it
			indicates the TSCH slotframe.</t>
			<t indent="0" pn="section-1.2-2">An EB announces the existence of a TSCH
			network and the nodes
	already joined to that network. Receiving an EB allows a Joining Node		already joined to that network. Receiving an EB allows a Joining Node
	(pledge) to learn about the network and synchronize to it.</t>		(pledge) to learn about the network and to synchronize with it.</t>
	<t>The EB may also be used as a means for a node already part of the net		<t indent="0" pn="section-1.2-3">The EB may also be used as a means for
	work to		a node already part of the network to
	re-synchronize <xref target="RFC7554" format="default"/>.</t>		resynchronize <xref target="RFC7554" format="default" sectionFormat="of" derived
	<t>There are a limited number of timeslots designated as broadcast slots		Content="RFC7554"/>.</t>
	by each		<t indent="0" pn="section-1.2-4">There are a limited number of timeslots
			designated as broadcast slots by each
	router in the network.		router in the network.
	Considering 10ms slots and a slot-frame length of 100, these slots are rare		Considering 10 ms slots and a slotframe length of 100, these slots are rare
	and could result in only 1 slot per second for broadcasts, which needs to be		and could result in only 1 slot per second for broadcasts, which needs to be
	used for the beacon.		used for the beacon.
	Additional broadcasts for Router Advertisements (RA), or Neighbor Discovery		Additional broadcasts for Router Advertisements (RA) or Neighbor Discovery
	(ND) could even more scarce.</t>		(ND) could be even more scarce.</t>
	</section>		</section>
	<section anchor="layer-3-synchronization-ipv6-router-solicitations-and-adv		<section anchor="layer-3-synchronization-ipv6-router-solicitations-and-adv
	ertisements" numbered="true" toc="default">		ertisements" numbered="true" toc="include" removeInRFC="false" pn="section-1.3">
	<name>Layer-3 synchronization: IPv6 Router Solicitations and Advertiseme		<name slugifiedName="name-layer-3-synchronization-ipv">Layer 3 Synchroni
	nts</name>		zation: IPv6 Router Solicitations and Advertisements</name>
	<t>At layer 3, <xref target="RFC4861" format="default"/> defines a mecha		<t indent="0" pn="section-1.3-1">At Layer 3, <xref target="RFC4861" form
	nism by which nodes learn about		at="default" sectionFormat="of" derivedContent="RFC4861"/> defines a mechanism b
	routers by receiving multicast Router Advertisements (RA).		y which nodes learn about
			routers by receiving multicast RAs.
	If no RA is received within a set time, then a Router Solicitation (RS) may be		If no RA is received within a set time, then a Router Solicitation (RS) may be
	transmitted as a multicast, to which an RA will be received, usually unicast.</t >		transmitted as a multicast, to which an RA will be received, usually unicast.</t >
	<t>Although <xref target="RFC6775" format="default"/> reduces the amount of multicast necessary to do address		<t indent="0" pn="section-1.3-2">Although <xref target="RFC6775" format= "default" sectionFormat="of" derivedContent="RFC6775"/> reduces the amount of mu lticast necessary for address
	resolution via Neighbor Solicitation (NS) messages, it still requires multicast		resolution via Neighbor Solicitation (NS) messages, it still requires multicast
	of either RAs or RSes.		of either RAs or RSes.
	This is an expensive operation for two reasons: there		This is an expensive operation for two reasons: there
	are few multicast timeslots for unsolicited RAs; and if a pledge node does not		are few multicast timeslots for unsolicited RAs; and if a pledge node does not
	receive an RA, and decides to transmit an RS,		receive an RA, and decides to transmit an RS,
	a broadcast aloha slot (see <xref target="RFC7554" format="default"/> section A. 5) is consumed with		a broadcast Aloha slot (see <xref target="RFC7554" sectionFormat="of" section="A .5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7554#appendix-A. 5" derivedContent="RFC7554"/>) is consumed with
	unencrypted traffic.		unencrypted traffic.
	<xref target="RFC6775" format="default"/> already allows for a unicast reply to		<xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC67
	such an RS.</t>		75"/> already allows for a unicast reply to such an RS.</t>
	<t>This is a particularly acute issue for the join process for the follo		<t indent="0" pn="section-1.3-3">This is a particularly acute issue for
	wing		the join process for the following
	reasons:</t>		reasons:</t>
	<ol spacing="normal" type="1">		<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1.
	<li>Use of a multicast slot by even a non-malicious unauthenticated no		3-4">
	de for		<li pn="section-1.3-4.1" derivedCounter="1.">Use of a multicast slot b
	a Router Solicitation (RS) may overwhelm that time slot.</li>		y even a non-malicious unauthenticated node for
	<li>It may require many seconds of on-time before a new pledge receive		a Router Solicitation (RS) may overwhelm that timeslot.</li>
	s a Router		<li pn="section-1.3-4.2" derivedCounter="2.">It may require many secon
	Advertisement (RA) that it can use.</li>		ds of on-time before a new pledge receives a
	<li>A new pledge may have to receive many Enhanced Beacons (EB) before		Router Advertisement (RA) that it can use.</li>
	it can pick an		<li pn="section-1.3-4.3" derivedCounter="3.">A new pledge may have to
	appropriate network and/or closest Join Assistant to attach to.		receive many EBs before it can pick an
			appropriate network and/or closest Join Proxy to attach to.
	If it must remain in the receive state for an RA as well as find the		If it must remain in the receive state for an RA as well as find the
	Enhanced Beacon (EB), then the process may take dozens of seconds, even minutes for each		EB, then the process may take dozens of seconds, even minutes for each
	enrollment attempt that it needs to make.</li>		enrollment attempt that it needs to make.</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="layer-2-selection" numbered="true" toc="default">		<section anchor="layer-2-selection" numbered="true" toc="include" removeIn
	<name>Layer-2 Selection</name>		RFC="false" pn="section-1.4">
	<t>In a complex Low-power and Lossy Networks (LLN), multiple LLNs may be		<name slugifiedName="name-layer-2-selection">Layer 2 Selection</name>
	connected together by backbone routers ( technology such as <xref target="I-D.i		<t indent="0" pn="section-1.4-1">In a complex Low-power and Lossy Networ
	etf-6lo-backbone-router" format="default"/>), resulting in an area that is servi		k (LLN), multiple LLNs may
	ced by multiple distinct Layer-2 instances.		be connected together by Backbone Routers (technology such as
	These are called Personal Area Networks (PAN).		<xref target="RFC8929" format="default" sectionFormat="of" derivedContent="RFC89
	Each instance will have a separate Layer-2 security profile, and will be disting		29"/>), resulting in an area that is
	uished by a different PANID.		serviced by multiple, distinct Layer 2 instances.
	The PANID is part of the <xref target="ieee802154" format="default"/> layer-2 he		These are called Personal Area Networks (PANs).
	ader: it is a 16-bit value which is chosen to be unique, and it contributes cont		Each instance will have a separate Layer 2 security profile and will be distingu
	ext to the layer-2 security mechanisms.		ished by a different PANID.
	The PANID provides a context similar to the ESSID does in 802.11 networking, and
	can be conceived of in a similar fashion as the 802.3 ethernet VLAN tag in that		The PANID is part of the Layer 2 header as defined in <xref target="IEEE.802.15.
	it provides context for all layer-2 addresses.</t>		4" format="default" sectionFormat="of" derivedContent="IEEE.802.15.4"/>:
	<t>A device which is already enrolled in a network may find after a long		it is a 16-bit value that is chosen to be unique, and
	sleep that it needs to resynchronize to the Layer 2 network.		it contributes context to the Layer 2 security mechanisms.
	The enrollment keys that it has will be specific to a PANID, but it may have mor		The PANID provides a context similar to the Extended Service Set ID (ESSID)
	e than one set of keys.		in 802.11 networking and can be considered similar to
	Such a device may wish to connect to a PAN that is experiencing less congestion,		the 802.3 Ethernet VLAN tag in that it provides context for all Layer 2 addresse
	or which has a shalower		s.</t>
	(<xref target="RFC6550" format="default"/>) Routing Protocol for LLNs (RPL) tree		<t indent="0" pn="section-1.4-2">A device that is already enrolled in a
	.		network may find after
	It may even observe PANs for which it does not have keys, but which is believes		a long sleep that it needs to resynchronize with the Layer 2 network.
	it may have credentials that would allow it to join.</t>		The device's enrollment keys will be specific to a PANID, but the device may hav
	<t>In order to identify which PANs are part of the same backbone network		e more than one set of keys.
	, the network ID is introduced in this extension.		Such a device may wish to connect to a PAN that is experiencing less congestion
			or that has a shallower
			Routing Protocol for LLNs (RPL) tree <xref target="RFC6550" format="default" sec
			tionFormat="of" derivedContent="RFC6550"/>.
			It may even observe PANs for which it does not have keys, but for which
			it believes it may have credentials that would allow it to join.</t>
			<t indent="0" pn="section-1.4-3">In order to identify which PANs are par
			t of the same backbone network, the network ID is introduced in this extension.
	PANs that are part of the same backbone will be configured to use the same netwo rk ID.		PANs that are part of the same backbone will be configured to use the same netwo rk ID.
	For <xref target="RFC6550" format="default"/> RPL networks, configuration of the		For RPL networks <xref target="RFC6550" format="default" sectionFormat="of" deri
	network ID can be done with an configuration option, which is the subject of fu		vedContent="RFC6550"/>, configuration of the network ID can be done with a confi
	ture work.</t>		guration option, which is the subject of future work.</t>
	<t>In order to provide some input to the choice of which PAN to use, the		<t indent="0" pn="section-1.4-4">In order to provide some input to the c
	PAN priority field has been added.		hoice of which PAN to use, the PAN priority field has been added.
	This lists the relative priority for the PAN among different PANs.		This lists the relative priority for the PAN among different PANs.
	Every Enhanced Beacon from a given PAN will likely have the same PAN priority.		Every EB from a given PAN will likely have the same PAN priority.
	Determination of the the PAN priority is the subject of future work; but it is e		Determination of the PAN priority is the subject of future work;
	xpected that it will be calculated by an algorithm in the 6LBR, possibly involvi		but it is expected that it will be calculated by an algorithm in the
	ng communication between 6LBRs over the backbone network.</t>		6LoWPAN Border Router (6LBR), possibly involving communication between 6LBRs ove
	<t>The <xref target="RFC6550" format="default"/> parent selection proces		r the backbone network.</t>
	s can only operate within a single PAN, because it depends upon receiving RPL DI		<t indent="0" pn="section-1.4-5">The parent selection process <xref targ
	O messages from all available parents.		et="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/>
	As part of the PAN selection process, the device may wish to know how deep in th		can only operate within a single PAN because it depends upon receiving RPL DIO m
	e LLN mesh it will be if it joins a particular PAN, and the rank priority field		essages from all available parents.
	provides an estimation of what the rank of each announcer is.		As part of the PAN selection process, the device may wish to know how deep
	Once the device synchronizes to a particular PAN's TSCH schedule then it may rec		in the LLN mesh it will be if it joins a particular PAN, and the rank
	eive DIOs that are richer in their diversity than this value.		priority field provides an estimation of each announcer's rank.
	How this value will be used in practice is the subject of future research, and t		Once the device synchronizes with a particular PAN's TSCH schedule,
	he interpretation of this		it may receive DIOs that are richer in their diversity than this value.
			The use of this value in practice is the subject of future research, and the int
			erpretation of this
	value of the structure is considered experimental.</t>		value of the structure is considered experimental.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="protocol-definition" numbered="true" toc="default">		<section anchor="protocol-definition" numbered="true" toc="include" removeIn
	<name>Protocol Definition</name>		RFC="false" pn="section-2">
	<t><xref target="RFC8137" format="default"/> creates a registry for new IE		<name slugifiedName="name-protocol-definition">Protocol Definition</name>
	TF IE subtypes.		<t indent="0" pn="section-2-1"><xref target="RFC8137" format="default" sec
			tionFormat="of" derivedContent="RFC8137"/> creates a registry for new IETF IE su
			btypes.
	This document allocates a new subtype.</t>		This document allocates a new subtype.</t>
	<t>The new IE subtype structure is as follows. As explained in		<t indent="0" pn="section-2-2">The new IE subtype structure is as follows.
	<xref target="RFC8137" format="default"/> the length of the Sub-Type Content can		As explained in
	be calculated from the		<xref target="RFC8137" format="default" sectionFormat="of" derivedContent="RFC81
			37"/>, the length of the subtype content can be calculated from the
	container, so no length information is necessary.</t>		container, so no length information is necessary.</t>
	<figure anchor="iesubtype">		<figure anchor="iesubtype" align="left" suppress-title="false" pn="figure-
	<name>IE subtype structure</name>		1">
	<artwork name="" type="" align="left" alt=""><![CDATA[		<name slugifiedName="name-ie-subtype-structure">IE Subtype Structure</na
			me>
			<artwork name="" type="" align="left" alt="" pn="section-2-3.1">
	1 2 3		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TBD-XXX |R|P| res | proxy prio | rank priority |		| 2 |R|P| res | proxy prio | rank priority |
	+-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+		+-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
	| pan priority | |		| PAN priority | |
	+---------------+ +		+---------------+ +
	| Join Proxy Interface-ID |		| Join Proxy Interface ID |
	+ (present if P=1) +		+ (present if P=1) +
	| |		| |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | |		| | |
	+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+ +
	| network ID |		| network ID |
	+ variable length, up to 16 bytes +		+ variable length, up to 16 bytes +
	~ ~		~ ~
	+ +		+ +
	| |		| |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		</figure>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal" indent="3" pn="section-2-4">
	<dt>res:</dt>		<dt pn="section-2-4.1">res:</dt>
	<dd>		<dd pn="section-2-4.2">
	reserved bits MUST be ignored upon receipt, and SHOULD be set to 0 when sendin		Reserved bits <bcp14>MUST</bcp14> be ignored upon receipt and <bcp14>SHOULD</b
	g.</dd>		cp14> be set to 0 when sending.</dd>
	<dt>R:</dt>		<dt pn="section-2-4.3">R:</dt>
	<dd>		<dd pn="section-2-4.4">
	The Router Advertisement R-flag is set if the sending node will act as a Route		The RA R-flag is set if the sending node will act as a router for host-only no
	r for host-only nodes relying on stateless address auto-configuration (SLAAC) to		des relying on stateless address auto-configuration (SLAAC) to get their global
	get their global IPv6 address.		IPv6 address.
	Those hosts MUST send a unicast Router Solicitation message in order to receive		Those hosts <bcp14>MUST</bcp14> send a unicast RS message in order to receive an
	a RA with the Prefix Information Option.</dd>		RA with the Prefix Information Option.</dd>
	<dt/>		<dt pn="section-2-4.5"/>
	<dd>In most cases, every node sending a beacon will set this flag, and i		<dd pn="section-2-4.6">In most cases, every node sending a beacon will s
	n a		et this flag, and in a
	typical mesh, this will be every single node. When this bit is not set, it		typical mesh, this will be every single node. When this bit is not set, it
	might indicate that this node may be under provisioned, or may have no additiona l		might indicate that this node may be under provisioned or that it may have no ad ditional
	slots for additional nodes. This could make this node more interesting to an		slots for additional nodes. This could make this node more interesting to an
	attacker.</dd>		attacker.</dd>
	<dt>P:</dt>		<dt pn="section-2-4.7">P:</dt>
	<dd>		<dd pn="section-2-4.8">
	If the Proxy Address P-flag is set, then the Join Proxy Interface ID bit field		If the Proxy Address P-flag is set, then the Join Proxy Interface ID bit field
	is present. Otherwise, it is not provided.</dd>		is present. Otherwise, it is not provided.</dd>
	<dt/>		<dt pn="section-2-4.9"/>
	<dd>This bit only indicates if another part of the structure is present,		<dd pn="section-2-4.10">This bit only indicates if another part of the s
	and		tructure is present, and
	has little security or privacy impact.</dd>		it has little security or privacy impact.</dd>
	<dt>proxy priority (proxy prio):</dt>		<dt pn="section-2-4.11">proxy prio (proxy priority):</dt>
	<dd>		<dd pn="section-2-4.12">
	This field indicates the willingness of the sender to act as join proxy.		This field indicates the willingness of the sender to act as a Join Proxy.
	Lower value indicates greater willingness to act as a Join Proxy as described in		Lower value indicates greater willingness to act as a Join Proxy as described in
	<xref target="I-D.ietf-6tisch-minimal-security" format="default"/>.		<xref target="RFC9031" format="default" sectionFormat="of" derivedContent="RFC90 31"/>.
	Values range from 0x00 (most willing) to 0x7e (least willing).		Values range from 0x00 (most willing) to 0x7e (least willing).
	A priority of 0x7f indicates that the announcer should never be considered as a viable enrollment proxy.		A priority of 0x7f indicates that the announcer should never be considered as a viable Join Proxy.
	Only unenrolled pledges look at this value.</dd>		Only unenrolled pledges look at this value.</dd>
	<dt/>		<dt pn="section-2-4.13"/>
	<dd>Lower values in this field indicate that the transmitter may have mo		<dd pn="section-2-4.14">Lower values in this field indicate that the tra
	re		nsmitter may have more
	capacity to handle unencrypted traffic.		capacity to handle unencrypted traffic.
	A higher value may indicate that the transmitter is low on neighbor cache entrie		A higher value may indicate that the transmitter is low on neighbor cache entrie
	s, or other resources.		s or other resources.
	Ongoing work such as <xref target="I-D.ietf-roll-enrollment-priority" format="de		Ongoing work such as <xref target="I-D.ietf-roll-enrollment-priority" format="de
	fault"/> documents one way to set this field.</dd>		fault" sectionFormat="of" derivedContent="NETWORK-ENROLLMENT"/> documents one wa
	<dt>rank priority:</dt>		y to set this field.</dd>
	<dd>		<dt pn="section-2-4.15">rank priority:</dt>
	The rank "priority" is set by the IPv6 LLN Router (6LR) which sent the beacon		<dd pn="section-2-4.16">
	and is an		The rank priority is set by the IPv6 LLN Router (6LR) that sent the beacon and
	indication of how willing this 6LR is to serve as an RPL <xref target="RFC6550"		is an
	format="default"/> parent within a		indication of how willing this 6LR is to serve as a RPL parent <xref target="RFC
			6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> within a
	particular network ID.		particular network ID.
	Lower values indicate more willingness, and higher values indicate less willingn ess.		Lower values indicate more willingness, and higher values indicate less willingn ess.
	This value is calculated by each 6LR according to algorithms specific to the		This value is calculated by each 6LR according to algorithms specific to the
	routing metrics used by the RPL (<xref target="RFC6550" format="default"/>).		routing metrics used by the RPL <xref target="RFC6550" format="default" sectionF ormat="of" derivedContent="RFC6550"/>.
	The exact process is a subject of significant research work.		The exact process is a subject of significant research work.
	It will typically be calculated from the RPL rank, and it may include some modif ications		It will typically be calculated from the RPL rank, and it may include some modif ications
	based upon current number of children, or number of neighbor cache entries		based upon current number of children or the number of neighbor cache entries
	available.		available.
	Pledges MUST ignore this value.		Pledges <bcp14>MUST</bcp14> ignore this value.
	It helps enrolled devices only to compare connection points.</dd>		It helps enrolled devices only to compare connection points.</dd>
	<dt/>		<dt pn="section-2-4.17"/>
	<dd>An attacker can use this value to determine which nodes are potentia		<dd pn="section-2-4.18">An attacker can use this value to determine whic
	lly		h nodes are potentially
	more interesting.		more interesting.
	Nodes which are less willingness to be parents likely have more traffic, and an		Nodes that are less willing to be parents likely have more traffic, and an
	attacker could use this information to determine which nodes would be more		attacker could use this information to determine which nodes would be more
	interesting to attack or disrupt.</dd>		interesting to attack or disrupt.</dd>
	<dt>pan priority:</dt>		<dt pn="section-2-4.19">PAN priority:</dt>
	<dd>		<dd pn="section-2-4.20">
	The pan priority is a value set by the Destination-Oriented Directed		The PAN priority is a value set by the Destination-Oriented Directed
	Acyclic Graph (DODAG) root (see <xref target="RFC6550" format="default"/>, typic		Acyclic Graph (DODAG) root (see <xref target="RFC6550" format="default" sectionF
	ally, the 6LBR) to indicate the relative		ormat="of" derivedContent="RFC6550"/>, typically the 6LBR) to indicate the relat
			ive
	priority of this LLN compared to those with different PANIDs that the		priority of this LLN compared to those with different PANIDs that the
	operator might control.		operator might control.
	This value may be used as part of the enrollment priority, but typically is used		This value may be used as part of the enrollment priority, but typically it is u
	by devices		sed by devices
	which have already enrolled, and need to determine which PAN to pick when		that have already enrolled and need to determine which PAN to pick when
	resuming from a long sleep.		resuming from a long sleep.
	Unenrolled pledges MAY consider this value when selecting a PAN to join.		Unenrolled pledges <bcp14>MAY</bcp14> consider this value when selecting a PAN t
	Enrolled devices MAY consider this value when looking for an eligible parent		o join.
			Enrolled devices <bcp14>MAY</bcp14> consider this value when looking for an elig
			ible parent
	device.		device.
	Lower values indicate a higher willingness to accept new nodes.</dd>		Lower values indicate more willingness to accept new nodes.</dd>
	<dt/>		<dt pn="section-2-4.21"/>
	<dd>An attacker can use this value, along with the observed PANID in the		<dd pn="section-2-4.22">An attacker can use this value, along with the o
	Beacon		bserved PANID in the EB
	to determine which PANIDs have more network resources, and may have more		to determine which PANIDs have more network resources, and may have more
	interesting traffic.</dd>		interesting traffic.</dd>
	<dt>Join Proxy Interface ID:</dt>		<dt pn="section-2-4.23">Join Proxy Interface ID:</dt>
	<dd>		<dd pn="section-2-4.24">
	If the P bit is set, then 64 bits (8 bytes) of address are present.		If the P bit is set, then 64 bits (8 bytes) of address are present.
	This field provides the Interface ID (IID) of the Link-Local address of the Join Proxy.		This field provides the Interface ID (IID) of the link-local address of the Join Proxy.
	The associated prefix is well-known as fe80::/64. If this field is not		The associated prefix is well-known as fe80::/64. If this field is not
	present, then IID is derived from the layer-2 address of the sender as per		present, then IID is derived from the Layer 2 address of the sender per
	SLAAC (<xref target="RFC4662" format="default"/>).</dd>		SLAAC <xref target="RFC4862" format="default" sectionFormat="of" derivedContent=
	<dt/>		"RFC4862"/>.</dd>
	<dd>This field communicates the Interface ID bits that should be used fo		<dt pn="section-2-4.25"/>
	r this node's		<dd pn="section-2-4.26">This field communicates the IID bits that should
	layer-3 address, if it should not be derived from the layer-2 address.		be used for this node's
			Layer 3 address, if it should not be derived from the Layer 2 address.
	Communication with the Join Proxy occurs in the clear.		Communication with the Join Proxy occurs in the clear.
	This field avoids the need for an additional service-discovery process for the c		This field avoids the need for an additional service-discovery process for the c
	ase where the L3		ase where the Layer 3
	address is not derived from the L2 address.		address is not derived from the Layer 2 address.
	An attacker will see both L2 and L3 addresses, so this field provides no new inf		An attacker will see both Layer 2 and Layer 3 addresses, so this field provides
	ormation.</dd>		no new information.</dd>
	<dt>network ID:</dt>		<dt pn="section-2-4.27">network ID:</dt>
	<dd>		<dd pn="section-2-4.28">
	This is a variable length field, up to 16-bytes in size that uniquely identifi es		This is a variable length field, up to 16-bytes in size that uniquely identifi es
	this network, potentially among many networks that are operating in the same		this network, potentially among many networks that are operating in the same
	frequencies in overlapping physical space. The length of this field can be		frequencies in overlapping physical space. The length of this field can be
	calculated as being whatever is left in the Information Element.</dd>		calculated as being whatever is left in the IE.</dd>
	<dt/>		<dt pn="section-2-4.29"/>
	<dd>In a 6tisch network, where RPL <xref target="RFC6550" format="defaul		<dd pn="section-2-4.30">In a 6TiSCH network, where RPL <xref target="RFC
	t"/> is used as the mesh routing protocol, the		6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> is used as
	network ID can be constructed from a truncated SHA256 hash of the prefix (/64) o		the mesh routing protocol, the
	f the		network ID can be constructed from a truncated SHA-256 hash of the prefix (/64)
			of the
	network. This will be done by the RPL DODAG root and communicated by the RPL		network. This will be done by the RPL DODAG root and communicated by the RPL
	Configuration Option payloads, so it is not calculated more than once.		Configuration Option payloads, so it is not calculated more than once.
	This is just a suggestion for a default algorithm: it may be set in any		This is just a suggestion for a default algorithm: it may be set in any
	convenience way that results in a non-identifing value.		convenient way that results in a non-identifying value.
	In some LLNs where multiple PANIDs may lead to the same management device		In some LLNs where multiple PANIDs may lead to the same management device
	(the Join Registrar/Coordinator - JRC), then a common value that is the same acr oss all the PANs MUST be		(the Join Registrar/Coordinator (JRC)), then a common value that is the same acr oss all the PANs <bcp14>MUST</bcp14> be
	configured.		configured.
	Pledges that see the same networkID will not waste time		Pledges that see the same network ID will not waste time
	attempting to enroll multiple times with the same network that when the network		attempting to enroll multiple times with the same network when the network has m
	has multiple attachment points.</dd>		ultiple attachment points.</dd>
	<dt/>		<dt pn="section-2-4.31"/>
	<dd>If the network ID is derived as suggested, then it will be an opaque		<dd pn="section-2-4.32">If the network ID is derived as suggested, then
	,		it will be an opaque,
	seemingly random value, and will not directly reveal any information about the n		seemingly random value and will not directly reveal any information about the ne
	etwork.		twork.
	An attacker can match this value across many transmissions to map the extent		An attacker can match this value across many transmissions to map the extent
	of a network beyond what the PANID might already provide.</dd>		of a network beyond what the PANID might already provide.</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="default">		<section anchor="security-considerations" numbered="true" toc="include" remo
	<name>Security Considerations</name>		veInRFC="false" pn="section-3">
	<t>All of the contents of this Information Element are transmitted in the		<name slugifiedName="name-security-considerations">Security Considerations
	clear.		</name>
	The content of the Enhanced Beacon is not encrypted.		<t indent="0" pn="section-3-1">All of the contents of this IE are transmit
			ted in the clear.
			The content of the EB is not encrypted.
	This is a restriction in the cryptographic architecture of the 802.15.4 mechanis m.		This is a restriction in the cryptographic architecture of the 802.15.4 mechanis m.
	In order to decrypt or do integrity checking of layer-2 frames in TSCH, the		In order to decrypt or do integrity checking of Layer 2 frames in TSCH, the
	TSCH Absolute Slot Number (ASN) is needed.		TSCH ASN is needed.
	The Enhanced Beacon provides the ASN to new (and long-sleeping) nodes.</t>		The EB provides the ASN to new (and long-sleeping) nodes.</t>
	<t>The sensitivity of each field is described within the description of ea		<t indent="0" pn="section-3-2">The sensitivity of each field is described
	ch field.</t>		within the description of each field.</t>
	<t>The Enhanced Beacon is authenticated at the layer-2 level using 802.15.		<t indent="0" pn="section-3-3">The EB is authenticated at the Layer 2 leve
	4		l using 802.15.4
	mechanisms using the network-wide keying material. Nodes which are enrolled		mechanisms using the network-wide keying material. Nodes that are enrolled
	will have the network-wide keying material and can validate the beacon.</t>		will have the network-wide keying material and can validate the beacon.</t>
	<t>Pledges which have not yet enrolled are unable to authenticate the beac ons,		<t indent="0" pn="section-3-4">Pledges that have not yet enrolled are unab le to authenticate the beacons
	and will be forced to temporarily take the contents on faith.		and will be forced to temporarily take the contents on faith.
	After enrollment, a newly enrolled node will be able to return to the beacon and		After enrollment, a newly enrolled node will be able to return to the beacon and
	validate it.</t>		validate it.</t>
	<t>In addition to the enrollment and join information described in this		<t indent="0" pn="section-3-5">In addition to the enrollment and join info
	document, the Enhanced Beacon contains a description of the TSCH schedule to		rmation described in this
			document, the EB contains a description of the TSCH schedule to
	be used by the transmitter of this packet.		be used by the transmitter of this packet.
	The schedule can provide an attacker with a list of channels and frequencies		The schedule can provide an attacker with a list of channels and frequencies
	on which communication will occur.		on which communication will occur.
	Knowledge of this can help an attacker to more efficiently jam		Knowledge of this can help an attacker to more efficiently jam
	communications, although there is future work being considered to make some		communications, although there is future work being considered to make some
	of the schedule less visible.		of the schedule less visible.
	Encrypting the schedule does not prevent an attacker from jamming, but rather		Encrypting the schedule does not prevent an attacker from jamming, but rather
	increases the energy cost of doing that jamming.</t>		increases the energy cost of doing that jamming.</t>
	</section>		</section>
	<section anchor="privacy-considerations" numbered="true" toc="default">		<section anchor="privacy-considerations" numbered="true" toc="include" remov
	<name>Privacy Considerations</name>		eInRFC="false" pn="section-4">
	<t>The use of a network ID may reveal information about the network.		<name slugifiedName="name-privacy-considerations">Privacy Considerations</
	The use of a SHA256 hash of the DODAGID (see <xref target="RFC6550" format="defa		name>
	ult"/>), rather than using the DODAGID itself		<t indent="0" pn="section-4-1">The use of a network ID may reveal informat
	directly provides some privacy for the the addresses used within the network,		ion about the network.
			The use of a SHA-256 hash of the DODAGID (see <xref target="RFC6550" format="def
			ault" sectionFormat="of" derivedContent="RFC6550"/>), rather than using the DODA
			GID itself
			directly provides some privacy for the addresses used within the network,
	as the DODAGID is usually the IPv6 address of the root of the RPL mesh.</t>		as the DODAGID is usually the IPv6 address of the root of the RPL mesh.</t>
	<t>An interloper with a radio sniffer would be able to use the network ID to map		<t indent="0" pn="section-4-2">An interloper with a radio sniffer would be able to use the network ID to map
	out the extent of the mesh network.</t>		out the extent of the mesh network.</t>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="include" removeIn
	<name>IANA Considerations</name>		RFC="false" pn="section-5">
	<t>IANA is asked to assign a new number TBD-XXX from Registry		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	"IEEE Std 802.15.4 IETF IE Subtype IDs" as defined by <xref target="RFC8137" for		<t indent="0" pn="section-5-1">IANA has assigned the following value in th
	mat="default"/>.</t>		e
	<t>This entry should be called 6tisch-Join-Info, and should refer to this		"IEEE Std 802.15.4 IETF IE Subtype IDs" registry, as defined by <xref target="RF
	document.</t>		C8137" format="default" sectionFormat="of" derivedContent="RFC8137"/>.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table anchor="iana" align="center" pn="table-1">
	Value Subtype-ID Reference		<thead>
	---- ---------- -----------		<tr>
	TBD-XXX 6tisch-Join-Inbfo [this document]		<th align="left" colspan="1" rowspan="1">Value</th>
	]]></artwork>		<th align="left" colspan="1" rowspan="1">Subtype ID</th>
	</section>		<th align="left" colspan="1" rowspan="1">Reference</th>
	<section anchor="acknowledgements" numbered="true" toc="default">		</tr>
	<name>Acknowledgements</name>		</thead>
	<t>Thomas Watteyne provided extensive editorial comments on the document.		<tbody>
	Carles Gomez Montenegro generated a detailed review of the document at WGLC.		<tr>
	Tim Evens provided a number of useful editorial suggestions.</t>		<td align="left" colspan="1" rowspan="1">2</td>
			<td align="left" colspan="1" rowspan="1">6tisch-Join-Info</td>
			<td align="left" colspan="1" rowspan="1">RFC 9032</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<displayreference target="I-D.ietf-roll-enrollment-priority" to="NETWORK-ENR
	<name>References</name>		OLLMENT"/>
	<references>		<references pn="section-6">
	<name>Normative References</name>		<name slugifiedName="name-references">References</name>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2		<references pn="section-6.1">
	119">		<name slugifiedName="name-normative-references">Normative References</na
			me>
			<reference anchor="IEEE.802.15.4" target="https://ieeexplore.ieee.org/do
			cument/7460875" quoteTitle="true" derivedAnchor="IEEE.802.15.4">
	<front>		<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit		<title>IEEE Standard for Low-Rate Wireless Networks</title>
	le>		<author>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>		<organization showOnFrontPage="true">IEEE</organization>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="BCP" value="14"/>
	<author initials="S." surname="Bradner" fullname="S. Bradner">
	<organization/>
	</author>		</author>
	<date year="1997" month="March"/>		<date month="April" year="2016"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>		</front>
			<seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
	</reference>		</reference>
	<reference anchor="BCP14" target="https://www.rfc-editor.org/info/rfc817 4">		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119" quoteTitle="true" derivedAnchor="RFC2119">
	<front>		<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	tle>		le>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>		<author initials="S." surname="Bradner" fullname="S. Bradner">
	<seriesInfo name="RFC" value="8174"/>		<organization showOnFrontPage="true"/>
	<seriesInfo name="BCP" value="14"/>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>		</author>
	<date year="2017" month="May"/>		<date year="1997" month="March"/>
	<abstract>		<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying tha t only UPPERCASE usage of the key words have the defined special meanings.</t>		<t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often ca pitalized. This document defines these words as they should be interpreted in IE TF documents. This document specifies an Internet Best Current Practices for th e Internet Community, and requests discussion and suggestions for improvements.< /t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>		</reference>
	<reference anchor="RFC8137" target="https://www.rfc-editor.org/info/rfc8 137">		<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4 861" quoteTitle="true" derivedAnchor="RFC4861">
	<front>		<front>
	<title>IEEE 802.15.4 Information Element for the IETF</title>		<title>Neighbor Discovery for IP version 6 (IPv6)</title>
	<seriesInfo name="DOI" value="10.17487/RFC8137"/>		<author initials="T." surname="Narten" fullname="T. Narten">
	<seriesInfo name="RFC" value="8137"/>		<organization showOnFrontPage="true"/>
	<author initials="T." surname="Kivinen" fullname="T. Kivinen">
	<organization/>
	</author>		</author>
	<author initials="P." surname="Kinney" fullname="P. Kinney">		<author initials="E." surname="Nordmark" fullname="E. Nordmark">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2017" month="May"/>		<author initials="W." surname="Simpson" fullname="W. Simpson">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="H." surname="Soliman" fullname="H. Soliman">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="September"/>
	<abstract>		<abstract>
	<t>IEEE Std 802.15.4 defines Information Elements (IEs) that can b e used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry fo r the IETF and describes how the IE is formatted to provide subtypes.</t>		<t indent="0">This document specifies the Neighbor Discovery proto col for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to dis cover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="4861"/>
			<seriesInfo name="DOI" value="10.17487/RFC4861"/>
	</reference>		</reference>
	<reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6 775">		<reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6 775" quoteTitle="true" derivedAnchor="RFC6775">
	<front>		<front>
	<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wirel ess Personal Area Networks (6LoWPANs)</title>		<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wirel ess Personal Area Networks (6LoWPANs)</title>
	<seriesInfo name="DOI" value="10.17487/RFC6775"/>
	<seriesInfo name="RFC" value="6775"/>
	<author initials="Z." surname="Shelby" fullname="Z. Shelby" role="ed itor">		<author initials="Z." surname="Shelby" fullname="Z. Shelby" role="ed itor">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti ">		<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti ">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="E." surname="Nordmark" fullname="E. Nordmark">		<author initials="E." surname="Nordmark" fullname="E. Nordmark">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="C." surname="Bormann" fullname="C. Bormann">		<author initials="C." surname="Bormann" fullname="C. Bormann">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2012" month="November"/>		<date year="2012" month="November"/>
	<abstract>		<abstract>
	<t>The IETF work in IPv6 over Low-power Wireless Personal Area Net work (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar l ink technologies have limited or no usage of multicast signaling due to energy c onservation. In addition, the wireless network may not strictly follow the trad itional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not des igned for non- transitive wireless links, as its reliance on the traditional IPv 6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple op timizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar ne tworks. The document thus updates RFC 4944 to specify the use of the optimizati ons defined here. [STANDARDS-TRACK]</t>		<t indent="0">The IETF work in IPv6 over Low-power Wireless Person al Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and othe r similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly foll ow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the trad itional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describe s simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, an d duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="6775"/>
			<seriesInfo name="DOI" value="10.17487/RFC6775"/>
	</reference>		</reference>
	<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4 861">		<reference anchor="RFC8137" target="https://www.rfc-editor.org/info/rfc8 137" quoteTitle="true" derivedAnchor="RFC8137">
	<front>		<front>
	<title>Neighbor Discovery for IP version 6 (IPv6)</title>		<title>IEEE 802.15.4 Information Element for the IETF</title>
	<seriesInfo name="DOI" value="10.17487/RFC4861"/>		<author initials="T." surname="Kivinen" fullname="T. Kivinen">
	<seriesInfo name="RFC" value="4861"/>		<organization showOnFrontPage="true"/>
	<author initials="T." surname="Narten" fullname="T. Narten">
	<organization/>
	</author>
	<author initials="E." surname="Nordmark" fullname="E. Nordmark">
	<organization/>
	</author>		</author>
	<author initials="W." surname="Simpson" fullname="W. Simpson">		<author initials="P." surname="Kinney" fullname="P. Kinney">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="H." surname="Soliman" fullname="H. Soliman">		<date year="2017" month="May"/>
	<organization/>		<abstract>
			<t indent="0">IEEE Std 802.15.4 defines Information Elements (IEs)
			that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.1
			5 Assigned Numbers Authority (ANA) manages the registry of the Information Eleme
			nts. This document formulates a request for ANA to allocate a number from that
			registry for the IETF and describes how the IE is formatted to provide subtypes.
			</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8137"/>
			<seriesInfo name="DOI" value="10.17487/RFC8137"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
			tle>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2007" month="September"/>		<date year="2017" month="May"/>
	<abstract>		<abstract>
	<t>This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find router s, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t>		<t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by cla rifying that only UPPERCASE usage of the key words have the defined special mea nings.</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>		</reference>
	<reference anchor="I-D.ietf-6tisch-minimal-security" target="http://www. ietf.org/internet-drafts/draft-ietf-6tisch-minimal-security-15.txt">		<reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9 031" quoteTitle="true" derivedAnchor="RFC9031">
	<front>		<front>
	<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>		<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-minimal-s		<author initials="M" surname="Vučinić" fullname="Mališa Vučinić" rol
	ecurity-15"/>		e="editor">
	<author initials="M" surname="Vucinic" fullname="Malisa Vucinic">		<organization showOnFrontPage="true"/>
	<organization/>
	</author>		</author>
	<author initials="J" surname="Simon" fullname="Jonathan Simon">		<author initials="J" surname="Simon" fullname="Jonathan Simon">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="K" surname="Pister" fullname="Kris Pister">		<author initials="K" surname="Pister" fullname="Kris Pister">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="M" surname="Richardson" fullname="Michael Richards on">		<author initials="M" surname="Richardson" fullname="Michael Richards on">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date month="December" day="10" year="2019"/>		<date month="May" year="2021"/>
	<abstract>
	<t>This document describes the minimal framework required for a ne
	w device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of
	IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (j
	oin registrar/coordinator, a central entity), share a symmetric key. How this k
	ey is provisioned is out of scope of this document. Through a single CoAP (Cons
	trained Application Protocol) request-response exchange secured by OSCORE (Objec
	t Security for Constrained RESTful Environments), the pledge requests admission
	into the network and the JRC configures it with link-layer keying material and o
	ther parameters. The JRC may at any time update the parameters through another
	request-response exchange secured by OSCORE. This specification defines the Con
	strained Join Protocol and its CBOR (Concise Binary Object Representation) data
	structures, and describes how to configure the rest of the 6TiSCH communication
	stack for this join process to occur in a secure manner. Additional security me
	chanisms may be added on top of this minimal framework.</t>
	</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="9031"/>
			<seriesInfo name="DOI" value="10.17487/RFC9031"/>
	</reference>		</reference>
	<reference anchor="ieee802154" target="http://standards.ieee.org/findstd		</references>
	s/standard/802.15.4-2015.html">		<references pn="section-6.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="I-D.ietf-roll-enrollment-priority" quoteTitle="true"
			target="https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-04" deri
			vedAnchor="NETWORK-ENROLLMENT">
	<front>		<front>
	<title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access Contro		<title>Controlling Secure Network Enrollment in RPL networks</title>
	l (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal A		<author fullname="Michael Richardson">
	rea Networks</title>		<organization showOnFrontPage="true">Sandelman Software Works</org
	<author initials="." surname="IEEE standard for Information Technolo		anization>
	gy">
	<organization/>
	</author>		</author>
	<date year="2015"/>		<author fullname="Rahul Arvind Jadhav">
	</front>		<organization showOnFrontPage="true">Huawei Tech</organization>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="BCP" value="14"/>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>		</author>
	<date year="2017" month="May"/>		<author fullname="Pascal Thubert">
	<abstract>		<organization showOnFrontPage="true">Cisco Systems</organization>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	</reference>
	</references>
	<references>
	<name>Informative References</name>
	<reference anchor="I-D.ietf-6tisch-architecture" target="http://www.ietf
	.org/internet-drafts/draft-ietf-6tisch-architecture-28.txt">
	<front>
	<title>An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4<
	/title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-architect
	ure-28"/>
	<author initials="P" surname="Thubert" fullname="Pascal Thubert">
	<organization/>
	</author>		</author>
	<date month="October" day="29" year="2019"/>		<author fullname="Huimin She">
			<organization showOnFrontPage="true">Cisco Systems</organization>
			</author>
			<date month="February" day="7" year="2021"/>
	<abstract>		<abstract>
	<t>This document describes a network architecture that provides lo		<t indent="0"> [I-D.ietf-6tisch-enrollment-enhanced-beacon] defi
	w- latency, low-jitter and high-reliability packet delivery. It combines a high		nes a method by
	-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel		which a potential [I-D.ietf-6tisch-minimal-security] enrollment proxy
	hopping (TSCH) to meet the requirements of LowPower wireless deterministic appl		can announce itself as a available for new Pledges to enroll on a
	ications.</t>		network. The announcement includes a priority for enrollment. This
			document provides a mechanism by which a RPL DODAG root can disable
			enrollment announcements, or adjust the base priority for enrollment
			operation.
			</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-roll-enrollment-pr
			iority-04"/>
			<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
			roll-enrollment-priority-04.txt"/>
			<refcontent>Work in Progress</refcontent>
	</reference>		</reference>
	<reference anchor="RFC8180" target="https://www.rfc-editor.org/info/rfc8 180">		<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4 862" quoteTitle="true" derivedAnchor="RFC4862">
	<front>		<front>
	<title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Co		<title>IPv6 Stateless Address Autoconfiguration</title>
	nfiguration</title>		<author initials="S." surname="Thomson" fullname="S. Thomson">
	<seriesInfo name="DOI" value="10.17487/RFC8180"/>		<organization showOnFrontPage="true"/>
	<seriesInfo name="RFC" value="8180"/>
	<seriesInfo name="BCP" value="210"/>
	<author initials="X." surname="Vilajosana" fullname="X. Vilajosana"
	role="editor">
	<organization/>
	</author>		</author>
	<author initials="K." surname="Pister" fullname="K. Pister">		<author initials="T." surname="Narten" fullname="T. Narten">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="T." surname="Watteyne" fullname="T. Watteyne">		<author initials="T." surname="Jinmei" fullname="T. Jinmei">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2017" month="May"/>		<date year="2007" month="September"/>
	<abstract>		<abstract>
	<t>This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of op eration specifies the baseline set of protocols that need to be supported and th e recommended configurations and modes of operation sufficient to enable a 6TiSC H functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Cha nnel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, includi ng the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabli ng interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal co nfiguration provides the necessary bandwidth for network and security bootstrapp ing and defines the proper link between the IETF protocols that interface to IEE E Std 802.15.4 TSCH. This minimal mode of operation should be implemented by al l 6TiSCH-compliant devices.</t>		<t indent="0">This document specifies the steps a host takes in de ciding how to autoconfigure its interfaces in IP version 6. The autoconfigurati on process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection pr ocedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]< /t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="4862"/>
			<seriesInfo name="DOI" value="10.17487/RFC4862"/>
	</reference>		</reference>
	<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6 550">		<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6 550" quoteTitle="true" derivedAnchor="RFC6550">
	<front>		<front>
	<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</ title>		<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</ title>
	<seriesInfo name="DOI" value="10.17487/RFC6550"/>
	<seriesInfo name="RFC" value="6550"/>
	<author initials="T." surname="Winter" fullname="T. Winter" role="ed itor">		<author initials="T." surname="Winter" fullname="T. Winter" role="ed itor">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="P." surname="Thubert" fullname="P. Thubert" role=" editor">		<author initials="P." surname="Thubert" fullname="P. Thubert" role=" editor">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="A." surname="Brandt" fullname="A. Brandt">		<author initials="A." surname="Brandt" fullname="A. Brandt">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="J." surname="Hui" fullname="J. Hui">		<author initials="J." surname="Hui" fullname="J. Hui">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="R." surname="Kelsey" fullname="R. Kelsey">		<author initials="R." surname="Kelsey" fullname="R. Kelsey">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="P." surname="Levis" fullname="P. Levis">		<author initials="P." surname="Levis" fullname="P. Levis">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="K." surname="Pister" fullname="K. Pister">		<author initials="K." surname="Pister" fullname="K. Pister">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="R." surname="Struik" fullname="R. Struik">		<author initials="R." surname="Struik" fullname="R. Struik">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">		<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="R." surname="Alexander" fullname="R. Alexander">		<author initials="R." surname="Alexander" fullname="R. Alexander">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2012" month="March"/>		<date year="2012" month="March"/>
	<abstract>		<abstract>
	<t>Low-Power and Lossy Networks (LLNs) are a class of network in w hich both the routers and their interconnect are constrained. LLN routers typic ally operate with constraints on processing power, memory, and energy (battery p ower). Their interconnects are characterized by high loss rates, low data rates , and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices in side the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN to wards a central control point). This document specifies the IPv6 Routing Protoc ol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby mu ltipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to t he devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t>		<t indent="0">Low-Power and Lossy Networks (LLNs) are a class of n etwork in which both the routers and their interconnect are constrained. LLN ro uters typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen t o thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Rou ting Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a centr al control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="6550"/>
			<seriesInfo name="DOI" value="10.17487/RFC6550"/>
	</reference>		</reference>
	<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7 554">		<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7 554" quoteTitle="true" derivedAnchor="RFC7554">
	<front>		<front>
	<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in t he Internet of Things (IoT): Problem Statement</title>		<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in t he Internet of Things (IoT): Problem Statement</title>
	<seriesInfo name="DOI" value="10.17487/RFC7554"/>
	<seriesInfo name="RFC" value="7554"/>
	<author initials="T." surname="Watteyne" fullname="T. Watteyne" role ="editor">		<author initials="T." surname="Watteyne" fullname="T. Watteyne" role ="editor">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="M." surname="Palattella" fullname="M. Palattella">		<author initials="M." surname="Palattella" fullname="M. Palattella">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="L." surname="Grieco" fullname="L. Grieco">		<author initials="L." surname="Grieco" fullname="L. Grieco">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2015" month="May"/>		<date year="2015" month="May"/>
	<abstract>		<abstract>
	<t>This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control ( MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks ( LLNs). The set of goals enumerated in this document form an initial set only.</ t>		<t indent="0">This document describes the environment, problem sta tement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Acces s Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="7554"/>
			<seriesInfo name="DOI" value="10.17487/RFC7554"/>
	</reference>		</reference>
	<reference anchor="I-D.ietf-6lo-backbone-router" target="http://www.ietf .org/internet-drafts/draft-ietf-6lo-backbone-router-17.txt">		<reference anchor="RFC8180" target="https://www.rfc-editor.org/info/rfc8 180" quoteTitle="true" derivedAnchor="RFC8180">
	<front>		<front>
	<title>IPv6 Backbone Router</title>		<title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Co
	<seriesInfo name="Internet-Draft" value="draft-ietf-6lo-backbone-rou		nfiguration</title>
	ter-17"/>		<author initials="X." surname="Vilajosana" fullname="X. Vilajosana"
	<author initials="P" surname="Thubert" fullname="Pascal Thubert">		role="editor">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="C" surname="Perkins" fullname="Charles Perkins">		<author initials="K." surname="Pister" fullname="K. Pister">
	<organization/>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abe		<author initials="T." surname="Watteyne" fullname="T. Watteyne">
	gnoli">		<organization showOnFrontPage="true"/>
	<organization/>
	</author>		</author>
	<date month="February" day="20" year="2020"/>		<date year="2017" month="May"/>
	<abstract>		<abstract>
	<t>This document updates RFC 6775 and RFC 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called Backbone Routers. Backbone Routers are placed along the wireless edge of a Backbone, an d federate multiple wireless links to form a single Multi-Link Subnet.</t>		<t indent="0">This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be suppo rted and the recommended configurations and modes of operation sufficient to ena ble a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time- Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. T his minimal mode uses a collection of protocols with the respective configuratio ns, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framew ork, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that inter face to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implem ented by all 6TiSCH-compliant devices.</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="BCP" value="210"/>
			<seriesInfo name="RFC" value="8180"/>
			<seriesInfo name="DOI" value="10.17487/RFC8180"/>
	</reference>		</reference>
	<reference anchor="I-D.ietf-roll-enrollment-priority" target="http://www .ietf.org/internet-drafts/draft-ietf-roll-enrollment-priority-00.txt">		<reference anchor="RFC8929" target="https://www.rfc-editor.org/info/rfc8 929" quoteTitle="true" derivedAnchor="RFC8929">
	<front>		<front>
	<title>Enabling secure network enrollment in RPL networks</title>		<title>IPv6 Backbone Router</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-roll-enrollment-		<author initials="P." surname="Thubert" fullname="P. Thubert" role="
	priority-00"/>		editor">
	<author initials="M" surname="Richardson" fullname="Michael Richards		<organization showOnFrontPage="true"/>
	on">
	<organization/>
	</author>		</author>
	<date month="September" day="16" year="2019"/>		<author initials="C.E." surname="Perkins" fullname="C.E. Perkins">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="E." surname="Levy-Abegnoli" fullname="E. Levy-Abeg
			noli">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2020" month="November"/>
	<abstract>		<abstract>
	<t>[I-D.6tisch-enrollment-enhanced-beacon] defines a method by whi ch a potential [I-D.ietf-6tisch-minimal-security] can announce itself as a avail able for new Pledges to Join a network. The announcement includes a priority fo r join. This document provides a mechanism by which a RPL DODAG root can disabl e join announcements, or adjust the base priority for join operation.</t>		<t indent="0">This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a bac kbone and federate multiple wireless links to form a single Multi-Link Subnet (M LSN).</t>
	</abstract>		</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="8929"/>
			<seriesInfo name="DOI" value="10.17487/RFC8929"/>
	</reference>		</reference>
	<reference anchor="RFC4662" target="https://www.rfc-editor.org/info/rfc4 662">		<reference anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9 030" quoteTitle="true" derivedAnchor="RFC9030">
	<front>		<front>
	<title>A Session Initiation Protocol (SIP) Event Notification Extens		<title>An Architecture for IPv6 over the Time-Slotted Channel Hoppin
	ion for Resource Lists</title>		g Mode of IEEE 802.15.4 (6TiSCH)</title>
	<seriesInfo name="DOI" value="10.17487/RFC4662"/>		<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
	<seriesInfo name="RFC" value="4662"/>		e="editor">
	<author initials="A. B." surname="Roach" fullname="A. B. Roach">		<organization showOnFrontPage="true"/>
	<organization/>
	</author>
	<author initials="B." surname="Campbell" fullname="B. Campbell">
	<organization/>
	</author>
	<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
	<organization/>
	</author>		</author>
	<date year="2006" month="August"/>		<date month="May" year="2021"/>
	<abstract>
	<t>This document presents an extension to the Session Initiation P
	rotocol (SIP)-Specific Event Notification mechanism for subscribing to a homogen
	eous list of resources. Instead of sending a SUBSCRIBE for each resource indivi
	dually, the subscriber can subscribe to an entire list and then receive notifica
	tions when the state of any of the resources in the list changes. [STANDARDS-TR
	ACK]</t>
	</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="9030"/>
			<seriesInfo name="DOI" value="10.17487/RFC9030"/>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
			<section anchor="acknowledgements" numbered="false" toc="include" removeInRF
			C="false" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgments">Acknowledgments</name>
			<t indent="0" pn="section-appendix.a-1"><contact fullname="Thomas Watteyne
			"/> provided extensive editorial comments on the document.
			<contact fullname="Carles Gomez Montenegro"/> generated a detailed review of the
			document at Working Group Last Call.
			<contact fullname="Tim Evens"/> provided a number of useful editorial suggestion
			s.</t>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="edit
			or">
			<organization showOnFrontPage="true">Universidad Diego Portales</organiz
			ation>
			<address>
			<postal>
			<street>Escuela de Informática y Telecomunicaciones</street>
			<street>Av. Ejército 441</street>
			<city>Santiago</city>
			<region>Región Metropolitana</region>
			<country>Chile</country>
			</postal>
			<phone>+56 (2) 676-8121</phone>
			<email>diego.dujovne@mail.udp.cl</email>
			</address>
			</author>
			<author initials="M." surname="Richardson" fullname="Michael Richardson">
			<organization showOnFrontPage="true">Sandelman Software Works</organizat
			ion>
			<address>
			<email>mcr+ietf@sandelman.ca</email>
			</address>
			</author>
			</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIACg9UF4AA9VcbXMbyXH+Pr9iQn0wWEdAJEVRMl2uGCJ5JzoUyZA8n12p
	VGqwOwDmuNhFdhakYJ38W/Jb8svydPfM7iwIST7nQypMOQIW89LTr0/39N5w
	OFSNawp7oi/Oz8/12/3D0cHr0ZG+KKdVvTCNq0p9XtiFLRtty8ws/aqQp9VU
	H9+7u9P3+o+VK7Upc31e1lVR8NhkvjKTSW0faQeNh/ri9MPN47HKq6w0C2yc
	12baDJ1tpsPjxvlsPrTtOvg4N2Vm8+HEmqwqhwdHSvkGm/2HKaoSs5t6ZZVy
	y/pE4w/ffHO4v//b/UNlamvo4UXZ2Lq0jXqa8Rgtu+ifqvrBlTP9Q12tlurh
	SX6Mo4dnRJbKTMPPfZMrtXT8+YXOTKlX3mpT12atB26qTVHotfW7GgecGz/X
	c1tb9ULroW6qTD74qm5qO/Xh23rBXzQNOKHJ+BiHnPA2uZ2aVdF4jIi/y6Q4
	HBzxtvSr8ECZVTOv6hPFJ9HD8K/WrsSIs5E+W/1cPZa2fS4COHN2VsXf9MDm
	rqnq3XZQVYNvP5bu0dbe5SYP429AqimYDPnzoNyCW+c+W9nCgPpOCzKj1/re
	FjarFqsSXzMohvV7evw40uc/2zrDnvro6KBdDQ/WJ/rOlI0zs2pP39oZad0H
	29TVsiocdMB0g6tV2dQYfzp3RXe85ZxV5LvXx3pwuKuP3xwP3x4cdnvYhXEF
	FJDOM8rl/H+gZ6NVvhxlxXY+fhjpW5fNTZ17KHeflR/oB1tsG8BsxHlyWyyg
	PnfVtHmCirIa+k2SFln9HVnEH3ycMMqMUqoUdj5akvHt96eHBwe/pY/vTm8O
	jk7oyduDN0fy29uDV2/CsOM3b16Hj0dvjw/o48XwbJTa3MKVbmGKobfZqibe
	Y4yz1sIjHLw+EpVqTD0jCe/Mm2Z58vIlGyIdc0QjRzjhy6krc9iKb397GV3K
	8HAf/8ybRbEji4nb2WG/c9fko9b57OkbUzcjTZ9P9E+uht54D9HnbrXQ4yyj
	b6cVJF4VevBhfLrL3udmvvbQrEJfmrWt9eDm/V929d3SZm6Kx+SJPPufy+pp
	eGsa2618A82uSswcw2XoK9s8kUyEzL5JsQIIyfGA4tMSd3lvs3lZFdVsLSvk
	2OtE0+nhp+I4keCmEEydzV1js2ZVRwm/PXi7H6X4+nX8+OY1yUQNh0NtJjA8
	kzVKXWBv8seLCqYH9yycvT9LGFstlzBbWGDjrHBjUlcmz4yHlyFtLNwCBOTw
	OMoH1kFSCwwmFrePoN1laQs/AjXVCh7Ta4oB+h5Dh3dF1dAapzJIvceu5GgH
	RN2uLoW/ClSXHrshbIiP1+/Yx+vB+btdPa0N7QqvgEVg3pnVzdzqZW3h8TI+
	H76rsBjouJ87rxFUVhx/lnX16HIiWy8sUev8Qk/W+mkOy9Qmh49zLHKXSC6D
	4pMGKWJMaZ90WdESg2Vh8xk5d+IBws5M+8JaPpOMWCAKTCzCQl07nOPJNXOw
	g+jbPBseV3UO9cTB2HvXj5ZDCc7TiqIvppHIeeHyHL4NweOCND9fZUxz+Pv0
	AieeIFD7z0p9+hRU5PNneGGPY02IlfN2J/q4TVR6Q1RRkz596lzB58+j/xtV
	U9/UtE3yf5Wm5XB7mNoJwWNxnwpM9TSRSGVKA4EaBmzzVWHBnr4uIoy7klWR
	dOri/P77rfBqcHG+q/1q0qyXltRjWZjMwmPgI+23lXYaJpquf44orENPPeWW
	ocRW8j4q6LQwc1FBHnYKdjua9mTWfAgLsRVF9UR8AWEUG8SN2o8gTjRcB72D
	/vOwqni0+Z7YmfoZaMxN12wYa/qZJmwQap9RGhY+fwciXrzQP4rOIsTpgyN4
	1xqhit2r1p32J48/C+kPFtYO0Xm98+HHu/udPflXX13z59vzf/3x4vb8jD7f
	vR9fXrYfVBhx9/76x8uz7lM38/T6w4fzqzOZjKe690jtfBj/Bb/QEXeub+4v
	rq/GlztyqlQtyAYgFPgNR5gTno1U2XgVTTanOTj2f/8Xzv3p0z+FeA+jli8U
	6vHlaW5L2a0qi3X4CgaulVkuralZxICnAO9ATQVAl/Haz6unkkEqmKyuMRwa
	nrCWEO6E5L8qmYxPn74Wq0AFxgT1UPAAIjkOxMNDfbcus3ldle6vkhCocatC
	csgwUx+Lswlh7/PnvS9qvgLIJoNaLSagHLOWq3pZeYvw7Pu7RX83nkA34UA0
	OQ19JRMH47srceucxBC6dNleX1/FKdGkxi5ANJaAvQGXTp2tN8ZGXzAPjsjb
	/1xxuEpnGGZpzqAkzGNnSoR9T84I3BvDL7xrQ584b/vR+SYGPyNzgosL8peT
	ckxSpgCYyddsbuxl8ZtpdBcwb21m3SNRYGQzMnViKrGCHl9hHRWCH7uaAtoE
	XZrAD8tGspb465brrNWuCR4EC1N0hN6xqiMAkY5zWDYBkBmmWEeClwB/7VHC
	DnC+tR2meyQxTnaqLVuUaeNKpxtRgJ6ioZuVRgztma8HPoCGzVXNgSb6ocgx
	BciJBMhymDjYX/gwi05v+POQQwnYVM6aOW18sL/PKgwPFsaCwhr/T3HgqFZF
	rgFokONxnCHzPeCReon9YRVVmW+EzuBaQZXNvfgPxUylYUSuJMojNe4wThJ4
	aZTEUT3OkdHBltkBA+Xcjnf3KH29sm42n+DDGey8wpi1Glyd7QZy7aMtJV54
	aH5mU0t/tWl7yPmR6scN75C2Ia0LUJw40CcBWt/ogsH7qz0RMGUrDGJiBN0C
	5gSCJboZ5MfyrFslX4DLjoX95fOP1MUU6+nbsYanlrkdnoOQbcPKxEKlB1tO
	hoXudgMibJFH02p9pGKPZBfQaEkbPjn4aFhI3HUPtrKCTa41J8yeDGpcIBlZ
	zebCHMrqwJwaqCO6CLOgTJhUrztuaSlhMvWadswrAr/QOQ+DYodIJD8604m9
	f5grOgzNn1G6DgyFiA5Cazg2pE++20dhU+s4kNzCv5Oe3RF4ZSzkSN7k8y1M
	CIi3gn7LBqy2TxUWNMjB4L4brpyQoUyBlrpjdEZMU1alFzLBWGz3O3Gq5BbF
	X4lLyStQWFbQCGGqsFqcZQ58mUuG0eJD+vluT5nEM5iimot164G35Hf+uQPX
	MW6NR6936YyE6BHcRWPUqoSzrtdLBrm1IXg1UqnkoscLnld8YZA2GLIsWGR+
	FXTkLiJL4ia7SZetClNjmMkosjnvV7Z1BIyzgM44XY4PW0CnIsOVOhhFjJXo
	pxyZPOIja3pZlcOFIZZXKw8iKS+mkJaxM2VuYw9KeL9hFeRRgFGKhcQjhtG0
	Fw53ONIXDQ8K6oXP5Tr4QU8EggieMLHTip09Ieog8SBj3xJAxPSMnG1ctoWw
	QxEP+74a6XG6ElEwN48cyKLmMCUbSMQLCA/EhCWXLqOIyJxYgv3L2hFkSGLl
	S8giKwisNAI7xt47Kic0nO42DWIQPo1oCfgjrLtYsUIsCHOHqBTpwrxGZC5u
	BF7mycJA8S/VYjgJxTrbMFTwYgHEs5rQyRvzQJbzV5gqsTxwfy94fleCtaJP
	HCupZtUlHCAeGKlpedxGqQUW3QCFVA0UOHhBCpZVAFf2I5dnltWTrdlKLyvv
	121JRg8uL69AN2spRmt87bLvCtArk4xyZtkRQX0nJnuYVCUYFoLCADAuFmiC
	bXmy6g7fFtUwzhrKrM+fsakEagolnL9QLDfhoIACSOQd8RdbttTlkKors6Y9
	sytJzJm4ResFsWQwf0zcXoTSg5vxFeLSOelEnC6xgjWUYhI8AelA3CRW8Eio
	U1dYcXcxvAhNs5Xzc6HW4NF0Cp8L8WGvizOmTT7SyVI41q8DSKzGjnN4MVuf
	kMDZNR0cDyf4/GgKuCOJceQc51D5MqQ88HJAxgELNyQ7IO8JqxZ9th8bHfLe
	YvNYLQTwKaVJwScu4AEE4R7jQud3dxjHIQEC5ELFQTRLcERoCXkPlgixHyeX
	0B8Wmxo/J39mJODSMq80axuW0n+6HF/BgGZipWIDLWWRLjZWSCOeLARkrvSM
	EZdIkTq2xSARsuVcyInuhHSf7dxMyeWapDz13AixSx+l0wmkWnrYwVziaWLS
	yKN9uxRlXVGTuqINnJZIYU9DhOywogdlpIjZhG4t4ycwlJYcqTu2vXhemvEE
	pQyFMbLkduHWyghA1A5RlayQS7cYCmBCboSxq3BNckM/R+yGH1EDibmvXyOj
	3OXYQNNv6qqpsqqQmjD5kcHtzSXCQ23hqUIcYp9XTaRMB0rE8QXZNC2+kLPS
	sYQDrfAmtnCWYlLKkwyIjUInciI52RMja0YBNBDHptgtZba2WhgyyIh6mRhy
	H6l9eko/Wo/X5oZpJiVG7UIJUdSJ6xLQTAJnlDrw2kzZ1zeImgAhTN1sVUua
	STXGdmy37Uh9D9YlotBgd/wdfIuL9JL2hOpgmbls3DAk2pizFD1ouc9UrCY/
	ky5hwemKahVatLzH21hD89WCqjHLVet94LScJNwt28MZha30HRG+Ys+E9B5y
	JO2bWAJNeW7zAIALR9mXBO6C6//JtIDNaC0AeOhmzyPDVM4pC3sWw6d1tYCe
	zxwpKU1meRTuwRYRv0QxpGSO1JmVUk+P1c9O81UG/i5aerBKibvBS7R6YQoC
	qE0INFSGmtHa80VEMceX72739BJB3k1AtCsfq4KzNaABuShkEidQA+IoDfeM
	ICXV3dD0UHJIdQzKS2z0EWy0SCczIeGWVMQmSR72L5gXMGabGdJnsnWL5AV+
	dLXEKl1aSUp8dnHd5khBKoTAHg0ixqSwgQjIcdwPp8TuZ5SJXm3xig8l3MMc
	/8vJuQcGwnHR1vOU7Y4xI7mQfp4gRzICCjVynodN1e2CKJI1eNVFqyFPjNXj
	NEr1DGclUp+qoQYjdR1L44H4JNjIRc4GLb/xUsOKhXOBoy5mAIJvwdvEF9Ww
	wbYy42oYCt9K4wAcY9iRMewYqffgVPe9ZQ7XSjgxMmA7Vea+pOZ000RFzo5l
	bZ02MRznlWwQPWRTr7gmGvNBqhhhSwldFFFNQUC4iz9nVNxwgoRD7fPVG6gu
	woRpGNDUdgb3UYun6O4QzuNtQcyyu9IyQkkWJtP4MC7Yh6zQXjX0KKa0gVNE
	utrbKNP2qGNo1ha66NvdajK8pwXpapaoiFiq8wJsG5SREBSiZes9+FyquISl
	etcAvitdgHL9pb+DLc8Otzx7JUvsY8KhfqWP9Gt9rN/ot/q3v+YZL/Ld8H/5
	f7zKL/jf/buz4Z///Gem7JfbX25+IbWjX2CKH9dsnzxuw1xl/BdpSf++9o2f
	BFqWlLu26//yRXZv/4u0bKz9K1fp+PL8jzPlG+YK9+hMTWaHwAVfpOVLmwzk
	DrkhP3nz+4Pdf4CWv/9vOy3/uL701v7HaNlc+1eu8m2+JKDtW7Rs+eXR1I6j
	priEPQRcCh4Hx8AQ5NGe0/K3X3mCzb+/fV1f/s6//wf6sl3+6tOJfuFse/NM
	fTm/39kWIHY+K0Vl4xN1wtGxpgQZmb7XfLNK0GNWVhTtOpC0bCR+hjvUiSSB
	EOg+31TiW5kDR8HB39KyFJ+21ef17XBaUF7teb4LwVYmS/mRIzyCuhTawyIU
	MeeVb4aM9eSqAAicL+xAIlfPOJEMSTj1+1TDfl4xuLscU5MRiJ7ZJiCPWVFN
	TCH3G2EuReEKYJH2CywhApOa7rbCaACOvc6QtlwtFwMIjAwXayCFj73egWtO
	ecC8EzxGsu0p6nor1bpaDtxyyYS7IeEUi4FQA/E1XkpqoyBy7qIiVLknIyJ2
	kjUDPqalgRF+khIi5bqSDVA6jLXprkAt3GzexLtOGwq+cx6U21i3W5V0aoae
	lH7SzQeE1mbLZZW066juBiDp4WGxxhYguaaiemO6FRdoKWxYL5eu1FekuNb6
	YGsw8Ia07yLgco4y46ARN6nmJTXTbQGJfB7xgeG0ouqZxBoQx3fswPJ2T3eM
	CoA7ZwneRy6yrkaueb7WwGACvr1cPMVtYR+WI9+NF66BHXdVs4pY7B5NhpUX
	S5gJtuwwBg8ZdN93TyI9khh0xNDOpA9gYkncqTpLFN0NFhhvHz4Cu11yOVdg
	crfSjPFt3Vutm29S/hqv06YI9bwbYbN9kW6F/0QbekJOMC+Gnvsf9/f1gM0k
	7MpWvf/xjdWDwprkOZK1jjM4JMZMe2wI+VCXAvk5a15JVhKqIhH883keJawl
	pbXAnuuSL/naAl9szSmq6kFHiwlZDcSScNO31Zu+mDryugvIul+UU5mBFnDm
	VOFpmRdWb72wGus5rLiVHy3y9W2o2oHcC36mjFeKGZJFOnlTO/JNeCLqTFeQ
	q5rr4dflrCLDZOSwrSxPzEk7w6Nw6Ho45D2ei4xPRq7NWv9GrAHnegg6xhp+
	uBOf7sT4Mlnzsdi7U4odHPfg+PJ2N1SCGEJ2F+7iQClzVrG3Q1JEytiDUgk9
	WIOTzkpLWdFwuk11BLlb7FcuYllCJblzWlTb0IYgGPZ3iWGJf08FmQzm+JcM
	DtlksFe/UcbhxJ/OYLIMASs601jZ8b26MOV6dSi4Lri5xksGHhhMpx6kx94N
	9eeP5AZirYYvFZIEnXo4uKm3bNosPZT1LkIZJESxYv2FDJR3JuG3VxCi2Fmx
	inXARZV3ncNqYnzENfAwLJquwSSbuwLBQmrQ3ePt+q/awtBI3QRTZ7Ag4Kln
	7jjO3BZL31X/pbbiJUZwrXyx5FskqZlzIQmGRNUmqPi41DHGtS8tJEURaggI
	tUDb66bgum/VSJW6WKvN+DlSVzwuNDDUz5Uo3POE0levKil3AuJfhP1JKA7x
	uyV0o4VxO7lSQJ8Ez7YZ53llkkzufL1acuRLkt3oCnoJMKucMCnxB2e8KhMz
	vKaLCFKpM1dz+VONs3UGYKd/qM1yrgdn12fjH3Z1XfVbB0TP9zoN3WsroRyM
	EufaFYtVGoqYL+SVguxDcxdBT8aKG/d5XbBSUuskdMXALJMe+p69R1AW+rRS
	wNGLXEKOXHd0xuY68w6KquKVzKN9dpUlwqfrqW2iDaV2vk+nVIEyj9WChBoK
	391V10j9+Dx8fhj/pY3BvUqgpB1cdmVUHDaSO5fzTUP76jIUopkiuX+3hZu5
	ruKrZI0vOWkTHfIzBJTZZdM1oP8dlrxHfSoUPWOuEO6s8niPK5BVLg7UdmaT
	pnT2GWNMG6JFWH0M0bO0CBjUF4BxCrBjstAh6uMjySQHbyXP3+V+lJiU1bZF
	0iqBpW29moN1CsIHFxdnu1FxL135MLysKKuJK4ZfOlIl7hjvq8xxpFhKtuWk
	n2JI1Xe+9Z3at/snJy+Pj0ZajtOhL+k1aqE4n+tCLtyobfAxjT8bl78bOJos
	z9aKE88YII+Ojw85QPaheXdTso0PzFO2/wBPo23LpVPIj37jVRE6+AI9e+EW
	IYJa6gWy3zwF9Uim9zatOiYqUWWInz5qZEZ9ez2ZmsfK5T7c/gVCTZmme6HX
	YpjH/sRnXU6UA5OB1uJFL1+pyOaQdz07yGVyhtTUQqoMlAfEyqOoKeVVd2fP
	Bexmi0oibyULTuIXJNchtzbBCpGmV/SStbrS11BKX9QpzTf3JE/poCCfG1uL
	vRKBxmvfJICHe0VuYopXrt2tSujGK2dRKnRnqKa1NC872Zk4XRhpa17GV608
	cgjLmXf/NqDTTr4DUAkC49tRRvrYnnMlShjstImbb3k3IhY4THx3sz2jCFnA
	c4edYxgKTRp8QRZh6DLcu7B9qucXzOTrObOO6mHordJS+tzu3o8PXx/LG57B
	YoOfGMAjRIez+VZS23tD6UmCfBkhCECQfuDWklOATH3HSTVKSj6IMOuiMrno
	X1dQSBidtl5QEIraRi9lMJ6ehc6J0HgY3jbtoPxJhMWhaMdtT2u6u3m0peNG
	dM61SI2kOSq8TkK9glErwfGIZUvB1dxrIXJrO6VC+KHN4BDyePvOd9dQWjOz
	4U0aMnw1aF3KrdyMmfrlacXJCKObof7j7elu26RLfKUmV4G8oZWkXd5kdUUh
	hpKGeWjyCOVM1TU2dFBdnKl93uMAFWJBkxiejG/kFSEVWuICGBWU0h1cXnhq
	/WSvZ0J6Q2K5KT6l4k47XZoFBZJ1qP/iWfNEEoHo5Q8RPQGweOUaVZS0ZWmo
	NUvhjIS24DyQJ+UwhIg0YjcZO1IGvzQGpkzxtVz3IPuzlwX67pVsDiOp37FD
	VkEi7KxCYcF77hnnRsKlgFFqV+Gm464ZamLX1DDf3lUL9hGs275dIP6Z3np5
	oe9idSy29odkT41xvGDfmdxm+taxbXt3y9RpDSR/Ft3aZeKqz94LFPNt6y9J
	3zTZFmXO6btRPKqaUaKBhCN9FSdu0L7J37bLjXotL7nlNTgtqji1mzEnkKhm
	DGmxTozu4Q05Jy/9iePkm/uvvFPDgciGBpjn5+0hN0wgkihcDuIrlsP4iuVu
	C4LvBR954IDHkApxMaJFX12NsHsDMzxcxnJMNyO+oPJcEv3e5qBMkRkFFL1A
	eCEeRSarricx/JJo/PCJWoseLN85LKjkiZCM0LCZQccERnXdnd9apW1ZhOG4
	PCaN8Q2Q1mUlKRgp2do2XT2Bdl6VjD0o9UhOnqzl91TaQwr9z0LWCddWwf26
	IvQN9y0GocVAErB57k7sEsg9aUwokrbG7g6H3FCgp7bQ6TKGg67SptoD84tG
	Fx0+jGPTpmSQzuXo1DH1XrLjNo5YRdz+0lnoWPAcKHsaRaM3+lgqFWF2CONp
	fTT6kSW5wEbMo53KHeShG830cCh1vHEbmRSc5KVYPlsC1BSBbpZ2tgHEyaER
	8h6pf0EmI33ukRLalMpMvR3J1/ZeC4WwfjYL1VuYssL4TkrDIZ2QX9cmFqBe
	UgoPveAMBVRMeuLpuYhE10BcHDsXZxjNqR3Vdl0uKeiwgDuyGbKBzgW39FJ1
	Ak4dlCFXpYYaH9+lK21NrzlWws+8kl1g62GuBIibcGWyGR9IZqv4zkQSZ6Vz
	iSPhN6Jgb4UtsJKxISWyUjnqCqR74UAC7TpvEycg4bPFVLWBufW0DL7iHVDM
	lPgKI+YyorKJ74wwWwUg3e7h25eT2jL5RiLLqDZ8JqxLGFzea+SiQUE5R9Tq
	2uSu0r7kulVXzItOIDaUJnwWIKAiVwUMxO0Y7nctgS/0xfhq/EyE/JA7nh5E
	LZH7u1kZOqZCETe257BWBbC5Vu1/syL57+WEjqy7cGcONLsj11ZT7p6CH0i6
	p+KLPFQRXieZeXgVINxpEcIdEtoQzBWGId2woac9cVr9Bim++cK/gZpem8yt
	5eJgZtMJ1KwT/5W//m/hL50SWdMndjKt8Nu/9d50/nc2pXH2EB1PeNvvfl4t
	wKKfCCGvS9tehsZWZIQr+W/RUKQjtxODCof19uCnpobf0D9Avf+qP3DsAZah
	u/qSOztzdtlw3sRaGKeDeIOmdA1zjf7ph8tTmKVb6PNHevWlpSZ9yxiqOF0V
	CVldFhX/Ow3UlKrU/wD5JxZBWUkAAA==
	</rfc>		</rfc>
End of changes. 154 change blocks.
	669 lines changed or deleted		722 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/