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" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc symrefs="yes"?> ipr="trust200902"
<?rfc consensus="yes"?> docName="draft-ietf-6tisch-enrollment-enhanced-beacon-14"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft number="9032"
-ietf-6tisch-enrollment-enhanced-beacon-14" category="std" obsoletes="" updates= obsoletes=""
"" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs updates=""
="true" version="3"> submissionType="IETF"
category="std"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="2"
sortRefs="true"
symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.39.0 --> <!-- 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"/>
ed-beacon-14"/>
<author initials="D." surname="Dujovne" fullname="Diego Dujovne (editor)"> <author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="ed
<organization>Universidad Diego Portales</organization> itor">
<address> <organization>Universidad Diego Portales</organization>
<postal> <address>
<street>Escuela de Informatica y Telecomunicaciones, Av. Ejercito 441< <postal>
/street> <street>Escuela de Informática y Telecomunicaciones</street>
<city>Santiago, Region Metropolitana</city> <street>Av. Ejército 441</street>
<country>Chile</country> <city>Santiago</city>
</postal> <region>Región Metropolitana</region>
<phone>+56 (2) 676-8121</phone> <country>Chile</country>
<email>diego.dujovne@mail.udp.cl</email> </postal>
</address> <phone>+56 (2) 676-8121</phone>
</author> <email>diego.dujovne@mail.udp.cl</email>
</address>
</author>
<author initials="M." surname="Richardson" fullname="Michael Richardson"> <author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization> <organization>Sandelman Software Works</organization>
<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 year="2021" month="May"/>
<area>Internet</area> <area>Internet</area>
<workgroup>6tisch Working Group</workgroup> <workgroup>6TiSCH</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>BRSKI</keyword>
<keyword>enroll</keyword>
<keyword>zero-touch</keyword>
<keyword>DODAG balancing</keyword>
<keyword>LLN balancing</keyword>
<abstract> <abstract>
<t>In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are lim <t>In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4,
ited to opportunities for broadcasts are limited to
specific times and specific channels. Routers in a Time-Slotted Channel specific times and specific channels. Routers in a
Hopping (TSCH) network 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>
</front> </front>
<middle> <middle>
<section anchor="problems" numbered="true" toc="default"> <section anchor="problems" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC7554" format="default"/> describes the use of the Time <t><xref target="RFC7554" format="default"/> describes the use of the Time
-Slotted Channel Hopping (TSCH) mode of <xref target="ieee802154" format="defaul -Slotted Channel Hopping (TSCH) mode of <xref target="IEEE.802.15.4" format="def
t"/>.</t> ault"/>.</t>
<t>In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are lim <t>In TSCH mode of IEEE Std 802.15.4, opportunities for broadcasts are lim
ited to ited 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 ace <t>This document defines a new IETF Information Element (IE) subtype to pl ace
into the Enhanced Beacon (EB) to provide join and enrollment information to pros pective into the EB to provide join and enrollment information to prospective
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>The following subsections explain the problem being solved, which
justify carrying the join and enrollement information in the EB.</t> justifies carrying the join and enrollment information in the EB.</t>
<section anchor="Terminology" numbered="true" toc="default"> <section anchor="Terminology" numbered="true" toc="default">
<name>Use of BCP 14 Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <t>
"MAY", and "OPTIONAL" in this document are to be interpreted as The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target= IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"RFC8174" format="default"/> when, and only when, they NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>Other terminology can be found in <xref target="I-D.ietf-6tisch-archi "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
tecture" format="default"/> in section be interpreted as
2.1.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>Other terminology can be found in <xref target="RFC9030"
sectionFormat="of" section="2.1"/>.</t>
</section> </section>
<section anchor="layer-2-synchronization" numbered="true" toc="default"> <section anchor="layer-2-synchronization" numbered="true" toc="default">
<name>Layer-2 Synchronization</name> <name>Layer 2 Synchronization</name>
<t>As explained in section 6 of <xref target="RFC8180" format="default"/ <t>As explained in <xref target="RFC8180"
>, the Enhanced Beacon (EB) sectionFormat="of" section="4.5.2"/>, the EB
has a number of purposes: synchronization of the Absolute Slot Number (ASN) and has a number of purposes: it carries synchronization information such as the
Join Metric, carrying the timeslot template identifier, carrying the channel ho Absolute Slot Number (ASN) and Join Metric and identifiers for
pping sequence identifier, and indicating the TSCH SlotFrame.</t> the timeslot template and the channel hopping sequence, and it
<t>An EB announces the existence of a TSCH network, and of the nodes indicates the TSCH slotframe.</t>
<t>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 work to <t>The EB may also be used as a means for a node already part of the net work to
re-synchronize <xref target="RFC7554" format="default"/>.</t> resynchronize <xref target="RFC7554" format="default"/>.</t>
<t>There are a limited number of timeslots designated as broadcast slots by each <t>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 ertisements" numbered="true" toc="default"> <section anchor="layer-3-synchronization-ipv6-router-solicitations-and-adv ertisements" numbered="true" toc="default">
<name>Layer-3 synchronization: IPv6 Router Solicitations and Advertiseme <name>Layer 3 Synchronization: IPv6 Router Solicitations and Advertiseme
nts</name> nts</name>
<t>At layer 3, <xref target="RFC4861" format="default"/> defines a mecha <t>At Layer 3, <xref target="RFC4861" format="default"/> defines a mecha
nism by which nodes learn about nism by which nodes learn about
routers by receiving multicast Router Advertisements (RA). 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>Although <xref target="RFC6775" format="default"/> reduces the amount of multicast 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"/>) is consumed with
unencrypted traffic. unencrypted traffic.
<xref target="RFC6775" format="default"/> already allows for a unicast reply to such an RS.</t> <xref target="RFC6775" format="default"/> 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 wing <t>This is a particularly acute issue for the join process for the follo wing
reasons:</t> reasons:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Use of a multicast slot by even a non-malicious unauthenticated no de for <li>Use of a multicast slot by even a non-malicious unauthenticated no de for
a Router Solicitation (RS) may overwhelm that time slot.</li> a Router Solicitation (RS) may overwhelm that timeslot.</li>
<li>It may require many seconds of on-time before a new pledge receive <li>It may require many seconds of on-time before a new pledge receive
s a Router s a
Advertisement (RA) that it can use.</li> Router Advertisement (RA) that it can use.</li>
<li>A new pledge may have to receive many Enhanced Beacons (EB) before <li>A new pledge may have to receive many EBs before it can pick an
it can pick an appropriate network and/or closest Join Proxy to attach to.
appropriate network and/or closest Join Assistant 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="default">
<name>Layer-2 Selection</name> <name>Layer 2 Selection</name>
<t>In a complex Low-power and Lossy Networks (LLN), multiple LLNs may be <t>In a complex Low-power and Lossy Network (LLN), multiple LLNs may
connected together by backbone routers ( technology such as <xref target="I-D.i be connected together by Backbone Routers (technology such as
etf-6lo-backbone-router" format="default"/>), resulting in an area that is servi <xref target="RFC8929" format="default"/>), resulting in an area that is
ced by multiple distinct Layer-2 instances. serviced by multiple, distinct Layer 2 instances.
These are called Personal Area Networks (PAN). These are called Personal Area Networks (PANs).
Each instance will have a separate Layer-2 security profile, and will be disting Each instance will have a separate Layer 2 security profile and will be distingu
uished by a different PANID. ished by a different PANID.
The PANID is part of the <xref target="ieee802154" format="default"/> layer-2 he
ader: it is a 16-bit value which is chosen to be unique, and it contributes cont The PANID is part of the Layer 2 header as defined in <xref target="IEEE.802.15.
ext to the layer-2 security mechanisms. 4" format="default"/>:
The PANID provides a context similar to the ESSID does in 802.11 networking, and it is a 16-bit value that is chosen to be unique, and
can be conceived of in a similar fashion as the 802.3 ethernet VLAN tag in that it contributes context to the Layer 2 security mechanisms.
it provides context for all layer-2 addresses.</t> The PANID provides a context similar to the Extended Service Set ID (ESSID)
<t>A device which is already enrolled in a network may find after a long in 802.11 networking and can be considered similar to
sleep that it needs to resynchronize to the Layer 2 network. the 802.3 Ethernet VLAN tag in that it provides context for all Layer 2 addresse
The enrollment keys that it has will be specific to a PANID, but it may have mor s.</t>
e than one set of keys. <t>A device that is already enrolled in a network may find after
Such a device may wish to connect to a PAN that is experiencing less congestion, a long sleep that it needs to resynchronize with the Layer 2 network.
or which has a shalower The device's enrollment keys will be specific to a PANID, but the device may hav
(<xref target="RFC6550" format="default"/>) Routing Protocol for LLNs (RPL) tree e more than one set of keys.
. Such a device may wish to connect to a PAN that is experiencing less congestion
It may even observe PANs for which it does not have keys, but which is believes or that has a shallower
it may have credentials that would allow it to join.</t> Routing Protocol for LLNs (RPL) tree <xref target="RFC6550" format="default"/>.
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>In order to identify which PANs are part of the same backbone network , the network ID is introduced in this extension. <t>In order to identify which PANs are part 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 network ID can be done with an configuration option, which is the subject of fu ture work.</t> For RPL networks <xref target="RFC6550" format="default"/>, configuration of the network ID can be done with a configuration option, which is the subject of fut ure work.</t>
<t>In order to provide some input to the choice of which PAN to use, the PAN priority field has been added. <t>In order to provide some input to the choice 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>The parent selection process <xref target="RFC6550" format="default"/
O messages from all available parents. >
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="default">
<name>Protocol Definition</name> <name>Protocol Definition</name>
<t><xref target="RFC8137" format="default"/> creates a registry for new IE TF IE subtypes. <t><xref target="RFC8137" format="default"/> creates a registry for new IE TF IE subtypes.
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>The new IE subtype structure is as follows. As explained in
<xref target="RFC8137" format="default"/> the length of the Sub-Type Content can be calculated from the <xref target="RFC8137" format="default"/>, 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">
<name>IE subtype structure</name> <name>IE Subtype Structure</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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">
<dt>res:</dt> <dt>res:</dt>
<dd> <dd>
reserved bits MUST be ignored upon receipt, and SHOULD be set to 0 when sendin g.</dd> Reserved bits <bcp14>MUST</bcp14> be ignored upon receipt and <bcp14>SHOULD</b cp14> be set to 0 when sending.</dd>
<dt>R:</dt> <dt>R:</dt>
<dd> <dd>
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/>
<dd>In most cases, every node sending a beacon will set this flag, and i n a <dd>In most cases, every node sending a beacon will set this flag, and i n 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>P:</dt>
<dd> <dd>
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/>
<dd>This bit only indicates if another part of the structure is present, and <dd>This bit only indicates if another part of the structure 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>proxy prio (proxy priority):</dt>
<dd> <dd>
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"/>.
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/>
<dd>Lower values in this field indicate that the transmitter may have mo re <dd>Lower values in this field indicate that the transmitter may have mo re
capacity to handle unencrypted traffic. capacity to handle unencrypted traffic.
A higher value may indicate that the transmitter is low on neighbor cache entrie s, or other resources. A higher value may indicate that the transmitter is low on neighbor cache entrie s or other resources.
Ongoing work such as <xref target="I-D.ietf-roll-enrollment-priority" format="de fault"/> documents one way to set this field.</dd> Ongoing work such as <xref target="I-D.ietf-roll-enrollment-priority" format="de fault"/> documents one way to set this field.</dd>
<dt>rank priority:</dt> <dt>rank priority:</dt>
<dd> <dd>
The rank "priority" is set by the IPv6 LLN Router (6LR) which sent the beacon The rank priority is set by the IPv6 LLN Router (6LR) that sent the beacon and
and is an is an
indication of how willing this 6LR is to serve as an RPL <xref target="RFC6550" indication of how willing this 6LR is to serve as a RPL parent <xref target="RFC
format="default"/> parent within a 6550" format="default"/> 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"/>.
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/>
<dd>An attacker can use this value to determine which nodes are potentia lly <dd>An attacker can use this value to determine which nodes are potentia lly
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>PAN priority:</dt>
<dd> <dd>
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"/>, typic
ally, the 6LBR) to indicate the relative ally the 6LBR) to indicate the relative
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/>
<dd>An attacker can use this value, along with the observed PANID in the Beacon <dd>An attacker can use this value, along with the observed 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>Join Proxy Interface ID:</dt>
<dd> <dd>
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"/>.</dd>
<dt/> <dt/>
<dd>This field communicates the Interface ID bits that should be used fo <dd>This field communicates the IID bits that should be used for this no
r this node's de's
layer-3 address, if it should not be derived from the layer-2 address. 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>network ID:</dt>
<dd> <dd>
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/>
<dd>In a 6tisch network, where RPL <xref target="RFC6550" format="defaul <dd>In a 6TiSCH network, where RPL <xref target="RFC6550" format="defaul
t"/> is used as the mesh routing protocol, the t"/> is used as the mesh routing protocol, the
network ID can be constructed from a truncated SHA256 hash of the prefix (/64) o network ID can be constructed from a truncated SHA-256 hash of the prefix (/64)
f the 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/>
<dd>If the network ID is derived as suggested, then it will be an opaque , <dd>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 etwork. seemingly random value and will not directly reveal any information about the ne 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="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>All of the contents of this Information Element are transmitted in the <t>All of the contents of this IE are transmitted in the clear.
clear. The content of the EB is not encrypted.
The content of the Enhanced Beacon 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 ch field.</t> <t>The sensitivity of each field is described within the description of ea ch field.</t>
<t>The Enhanced Beacon is authenticated at the layer-2 level using 802.15. <t>The EB is authenticated at the Layer 2 level using 802.15.4
4 mechanisms using the network-wide keying material. Nodes that are enrolled
mechanisms using the network-wide keying material. Nodes which 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>Pledges that have not yet enrolled are unable to authenticate the beaco ns
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>In addition to the enrollment and join information described in this
document, the Enhanced Beacon contains a description of the TSCH schedule to 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="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>The use of a network ID may reveal information about the network. <t>The use of a network ID may reveal information about the network.
The use of a SHA256 hash of the DODAGID (see <xref target="RFC6550" format="defa The use of a SHA-256 hash of the DODAGID (see <xref target="RFC6550" format="def
ult"/>), rather than using the DODAGID itself ault"/>), rather than using the DODAGID itself
directly provides some privacy for the the addresses used within the network, 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>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="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is asked to assign a new number TBD-XXX from Registry <t>IANA has assigned the following value in the
"IEEE Std 802.15.4 IETF IE Subtype IDs" as defined by <xref target="RFC8137" for "IEEE Std 802.15.4 IETF IE Subtype IDs" registry, as defined by <xref target="RF
mat="default"/>.</t> C8137" format="default"/>.</t>
<t>This entry should be called 6tisch-Join-Info, and should refer to this
document.</t> <table anchor="iana">
<artwork name="" type="" align="left" alt=""><![CDATA[
Value Subtype-ID Reference <thead>
---- ---------- ----------- <tr>
TBD-XXX 6tisch-Join-Inbfo [this document] <th>Value</th>
]]></artwork> <th>Subtype ID</th>
</section> <th>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>2</td>
<td>6tisch-Join-Info</td>
<td>RFC 9032</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-roll-enrollment-priority" to="NETWORK-ENROLLM
ENT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
le> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8137.
<seriesInfo name="RFC" value="2119"/> xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.
<author initials="S." surname="Bradner" fullname="S. Bradner"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.
</author> xml"/>
<date year="1997" month="March"/>
<abstract> <reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9031">
<t>In many standards track documents several words are used to sig <front>
nify the requirements in the specification. These words are often capitalized. <title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
This document defines these words as they should be interpreted in IETF document <author initials="M" surname="Vučinić" fullname=" Mališa Vučinić"
s. This document specifies an Internet Best Current Practices for the Internet role="editor">
Community, and requests discussion and suggestions for improvements.</t> <organization/>
</abstract> </author>
</front> <author initials="J" surname="Simon" fullname="Jonathan Simon">
</reference> <organization/>
<reference anchor="BCP14" target="https://www.rfc-editor.org/info/rfc817 </author>
4"> <author initials="K" surname="Pister" fullname="Kris Pister">
<front> <organization/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti </author>
tle> <author initials="M" surname="Richardson" fullname="Michael Richardson">
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <organization/>
<seriesInfo name="RFC" value="8174"/> </author>
<seriesInfo name="BCP" value="14"/> <date month="May" year="2021"/>
<author initials="B." surname="Leiba" fullname="B. Leiba"> </front>
<organization/> <seriesInfo name="RFC" value="9031"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC9031"/>
<date year="2017" month="May"/> </reference>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco <reference
l specifications. This document aims to reduce the ambiguity by clarifying tha anchor="IEEE.802.15.4"
t only UPPERCASE usage of the key words have the defined special meanings.</t> target="https://ieeexplore.ieee.org/document/7460875">
</abstract> <front>
</front> <title>IEEE Standard for Low-Rate Wireless Networks</title>
</reference> <author>
<reference anchor="RFC8137" target="https://www.rfc-editor.org/info/rfc8 <organization>IEEE</organization>
137">
<front>
<title>IEEE 802.15.4 Information Element for the IETF</title>
<seriesInfo name="DOI" value="10.17487/RFC8137"/>
<seriesInfo name="RFC" value="8137"/>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization/>
</author>
<author initials="P." surname="Kinney" fullname="P. Kinney">
<organization/>
</author>
<date year="2017" month="May"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6
775">
<front>
<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">
<organization/>
</author>
<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti
">
<organization/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization/>
</author>
<date year="2012" month="November"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4
861">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
<seriesInfo name="RFC" value="4861"/>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization/>
</author>
<author initials="W." surname="Simpson" fullname="W. Simpson">
<organization/>
</author>
<author initials="H." surname="Soliman" fullname="H. Soliman">
<organization/>
</author>
<date year="2007" month="September"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-6tisch-minimal-security" target="http://www.
ietf.org/internet-drafts/draft-ietf-6tisch-minimal-security-15.txt">
<front>
<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-minimal-s
ecurity-15"/>
<author initials="M" surname="Vucinic" fullname="Malisa Vucinic">
<organization/>
</author>
<author initials="J" surname="Simon" fullname="Jonathan Simon">
<organization/>
</author>
<author initials="K" surname="Pister" fullname="Kris Pister">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization/>
</author>
<date month="December" day="10" year="2019"/>
<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>
</reference>
<reference anchor="ieee802154" target="http://standards.ieee.org/findstd
s/standard/802.15.4-2015.html">
<front>
<title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access Contro
l (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal A
rea Networks</title>
<author initials="." surname="IEEE standard for Information Technolo
gy">
<organization/>
</author>
<date year="2015"/>
</front>
</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"/> <date month="April" year="2016"/>
<abstract> </front>
<t>RFC 2119 specifies common key words that may be used in protoco <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
l specifications. This document aims to reduce the ambiguity by clarifying tha <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
t only UPPERCASE usage of the key words have the defined special meanings.</t> </reference>
</abstract>
</front>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-6tisch-architecture" target="http://www.ietf
.org/internet-drafts/draft-ietf-6tisch-architecture-28.txt"> <reference anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9030">
<front> <front>
<title>An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4< <title>An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IE
/title> EE 802.15.4 (6TiSCH)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-architect
ure-28"/> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<author initials="P" surname="Thubert" fullname="Pascal Thubert"> <organization/>
<organization/> </author>
</author>
<date month="October" day="29" year="2019"/> <date month="May" year="2021"/>
<abstract>
<t>This document describes a network architecture that provides lo </front>
w- latency, low-jitter and high-reliability packet delivery. It combines a high <seriesInfo name="RFC" value="9030"/>
-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel <seriesInfo name="DOI" value="10.17487/RFC9030"/>
hopping (TSCH) to meet the requirements of LowPower wireless deterministic appl </reference>
ications.</t>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8180.
</front> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.
<reference anchor="RFC8180" target="https://www.rfc-editor.org/info/rfc8 xml"/>
180"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7554.
<front> xml"/>
<title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Co <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8929.
nfiguration</title> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8180"/>
<seriesInfo name="RFC" value="8180"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ro
<seriesInfo name="BCP" value="210"/> ll-enrollment-priority.xml"/>
<author initials="X." surname="Vilajosana" fullname="X. Vilajosana"
role="editor"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.
<organization/> xml"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization/>
</author>
<author initials="T." surname="Watteyne" fullname="T. Watteyne">
<organization/>
</author>
<date year="2017" month="May"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6
550">
<front>
<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">
<organization/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization/>
</author>
<author initials="A." surname="Brandt" fullname="A. Brandt">
<organization/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization/>
</author>
<author initials="R." surname="Kelsey" fullname="R. Kelsey">
<organization/>
</author>
<author initials="P." surname="Levis" fullname="P. Levis">
<organization/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization/>
</author>
<author initials="R." surname="Alexander" fullname="R. Alexander">
<organization/>
</author>
<date year="2012" month="March"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7
554">
<front>
<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">
<organization/>
</author>
<author initials="M." surname="Palattella" fullname="M. Palattella">
<organization/>
</author>
<author initials="L." surname="Grieco" fullname="L. Grieco">
<organization/>
</author>
<date year="2015" month="May"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-6lo-backbone-router" target="http://www.ietf
.org/internet-drafts/draft-ietf-6lo-backbone-router-17.txt">
<front>
<title>IPv6 Backbone Router</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6lo-backbone-rou
ter-17"/>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization/>
</author>
<author initials="C" surname="Perkins" fullname="Charles Perkins">
<organization/>
</author>
<author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abe
gnoli">
<organization/>
</author>
<date month="February" day="20" year="2020"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-roll-enrollment-priority" target="http://www
.ietf.org/internet-drafts/draft-ietf-roll-enrollment-priority-00.txt">
<front>
<title>Enabling secure network enrollment in RPL networks</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-enrollment-
priority-00"/>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization/>
</author>
<date month="September" day="16" year="2019"/>
<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>
</abstract>
</front>
</reference>
<reference anchor="RFC4662" target="https://www.rfc-editor.org/info/rfc4
662">
<front>
<title>A Session Initiation Protocol (SIP) Event Notification Extens
ion for Resource Lists</title>
<seriesInfo name="DOI" value="10.17487/RFC4662"/>
<seriesInfo name="RFC" value="4662"/>
<author initials="A. B." surname="Roach" fullname="A. B. Roach">
<organization/>
</author>
<author initials="B." surname="Campbell" fullname="B. Campbell">
<organization/>
</author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/>
</author>
<date year="2006" month="August"/>
<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>
</reference>
</references> </references>
</references> </references>
</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==
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgments</name>
<t><contact fullname="Thomas Watteyne"/> provided extensive editorial comm
ents 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>
</back>
</rfc> </rfc>
 End of changes. 75 change blocks. 
782 lines changed or deleted 339 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/