One document matched: draft-kelsey-6lo-mesh-link-establishment-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3315 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC4086 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC4861 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-kelsey-6lo-mesh-link-establishment-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Mesh Link Establishment">Mesh Link Establishment</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Kelsey" initials="R.K." surname="Kelsey">
<organization>Silicon Labs</organization>
<address>
<postal>
<street>343 Congress St</street>
<city>Boston</city>
<region>Massachusetts</region>
<code>02210</code>
<country>USA</country>
</postal>
<phone>+1 617 951 1225</phone>
<email>richard.kelsey@silabs.com</email>
</address>
</author>
<date year="2015" />
<area>Internet Area</area>
<workgroup>6lo</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document defines the mesh link establishment (MLE)
protocol for establishing and configuring secure radio links in
IEEE 802.15.4 radio mesh networks.
MLE extends IEEE 802.15.4 for use in multihop mesh networks by
adding three capabilities:
1) dynamically configuring and securing radio links,
2) enabling network-wide changes to radio parameters, and
3) determining link quality prior to link configuration
MLE operates below the routing layer, insulating it from
the details of configuring, securing, and maintaining
individual radio links within a larger mesh network.
</t>
</abstract>
</front>
<!-- ================================================================ -->
<middle>
<section title="Introduction">
<t>
The configuration of individual links in IEEE 802.15.4
mesh networks
falls into a gap between standards.
The IEEE 802.15.4 standard provides for static point-to-point
and star topologies
while the routing (L3) protocols used in multi-hop mesh
networks assume that the L2 links are already up and running.
Effective mesh networking using IEEE 802.15.4 requires
identifying,
configuring, and securing usable links to neighboring devices
as the network's membership and physical environment change.
Newly usable links need to be identified and configured
automatically, where configuration values can include
link-layer addresses, transmit and receive modes,
security parameters, and so forth.
</t><t>
Security configuration is particularly important, as
IEEE 802.15.4's replay protection applies only between
a joining device and the IEEE 802.15.4 coordinator via
which it joins the network.
Replay protection with other neighbors requires a
synchronization step that is not specified by
IEEE 802.15.4.
</t><t>
MLE can also be used to distribute
configuration values that are shared across a network,
such as the channel and PAN ID.
Network-wide configuration uses multicasts and requires some
form of multi-hop multicast forwarding.
These messages are sent infrequently, so forwarding with
simple flooding is sufficient.
</t><t>
One of the most important properties of a radio link, how
reliably the two neighbors can communicate, often cannot be
determined unilaterally by either neighbor.
Many 802.15.4 links are asymmetric, where messages traveling
one way across the link are received more or less
reliably than messages traveling in the opposite direction.
There is a chicken and egg problem here.
It is a waste of effort to configure a link that does
not have sufficient two-way reliability to be useful,
but the two-way reliability cannot be determined without
exchanging messages over the link.
MLE resolves this by allowing a node to
periodically multicast an estimate of the quality of its links.
This allows a node to determine if it has a usable
radio link to a neighbor without first configuring
that link.
</t><t>
MLE was developed as part of the ZigBee IP networking standard
<xref target="ZigBeeIP"/>.
This document describes the protocol as it was used in that
standard.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described
in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology">
<t>
<list style="hanging" hangIndent="20">
<t hangText="ETX"> Expected Transmission Count
<xref target="RFC6551"/>; the
number of transmission attempts required to send
a packet over a particular link. Defined to
be the product of the IDR values for both directions.
A perfect link has an ETX of 1, less than perfect links
have higher ETX values.
</t>
<t hangText="Frame counter">A value that is incremented
with each new secured message and used to detect replayed
messages.
</t>
<t hangText="IDR"> Inverse Delivery Ratio; the number
of transmission attempts divided by the number of
successful transmissions in a given direction over a link.
Used in computing the ETX value for a link.
</t>
</list>
</t>
</section>
<section title="Applicability">
<t>
This protocol provides configuration and management mechanisms
for using IEEE 802.15.4 links in IP-based multi-hop mesh networks.
The protocol is designed to be easily extended to add additional
features.
It could also be adapted for use with other single-hop link
protocols that have some of the same features
(message encryption, one-hop multicast) and omissions
(listed at the start of <xref target="sec:Overview"/>)
as IEEE 802.15.4.
</t>
</section>
<section title="Overview" anchor="sec:Overview">
<t>
MLE adds three capabilities to IEEE 802.15.4:
<list style="symbols">
<t> Dynamically configuring and securing radio links. </t>
<t> Enabling network-wide changes to radio parameters. </t>
<t> Determining link quality, prior to link configuration. </t>
</list>
The first two are mutually independent; either one can be used
without the other.
The purpose of the third, determining link quality, is to
make link management more efficient by detecting unreliable
links before any effort is spent configuring them.
</t>
<t>
All MLE messages are sent using UDP.
While UDP is not an obvious choice for a protocol used for L2
configuration, it was chosen to simplify integration of MLE
into existing systems.
</t>
<section title="Link Configuration">
<t>
Link configuration is done using link-local unicasts to
exchange IEEE 802.15.4 radio parameters (addresses,
node capabilities, and frame counters) between neighbors.
Link configuration messages are either a request that the link
be configured, or an acceptance or rejection of such a request.
</t>
<t>
IEEE 802.15.4 security uses frame counters to detect
replayed messages.
MLE uses a two-message challenge and response protocol
to ensure that the MLE message containing a neighbor's
frame counter is not itself a replayed message.
</t>
</section>
<section title="Parameter Dissemination">
<t>
Network-wide changes to radio parameters, such as moving
the network to a new channel, is done by multicasting the
new value(s) to all devices in the network.
Along with the values themselves, the multicast messages
include a delay value indicating when the new value takes
effect.
The delay avoids having the parameters change while the
multicast is still propagating.
</t>
<t>
In addition to network wide dissemination,
a device that does not have the current network values,
either because it has just joined the network or for any
other reason, can send a unicast request to a neighbor.
The neighbor will respond by sending the current network
values.
</t>
</section>
<section title="Link Quality Determination">
<t>
802.15.4 links can be asymmetric in that a link between
neighboring devices may be much more reliable in one direction
than in the other.
This limits the usefulness of unilateral link quality detection:
a link that looks strong to one device may not be usable because
it works poorly in the other direction.
To avoid wasting effort configuring unusable links, devices can
use MLE to send link-local multicasts containing their local
link quality estimates.
Neighboring nodes can then form an estimate of the two-way
quality of their link to the sender.
</t>
</section>
</section>
<section title="Security Formats">
<t>
One of the main functions of MLE is to initialize link-layer
security.
This means that MLE itself cannot rely on link-layer security.
To avoid the cost and complexity of adding a second security
suite, MLE reuses that of 802.15.4.
<xref target="AES"></xref> in Counter with CBC-MAC Mode
<xref target="CCM"></xref> as described in <xref target="IEEE802154"/>.
Later extensions may include other security suites for use
with other radio standards.
</t><t>
An MLE message begins with single byte indicating the
security suite used in that message.
If that initial byte is "255" no security is used and the
messages has no additional security data.
An initial byte of "0" indicates that the message is secured
(encrypted and authenticated) as
described in <xref target="IEEE802154"/>.
MLE messages thus have one of the two following formats:
<figure align="left">
<artwork align="left"><![CDATA[
+-----+------------+---------+-----+
| 0 | Aux Header | Command | MIC |
+-----+------------+---------+-----+
+-----+---------+
| 255 | Command |
+-----+---------+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="12">
<t hangText="Aux Header"> Auxiliary Security Header as described
in <xref target="IEEE802154"/>. </t>
<t hangText="Command"> MLE command; see
<xref target="sec:commands"/>. </t>
<t hangText="MIC"> Message Integrity Code as described
in <xref target="IEEE802154"/>. </t>
</list>
</t>
<t>
MLE security MUST NOT use any key that is being used by the link (or
any other) layer. <xref target="CCM"/> requires that each
key and nonce pair be used exactly once, which is most easily
achieved by using different keys.
</t><t>
If MLE security is in use each device MUST maintain an
outgoing MLE frame counter for use in securing outgoing packets
in compliance with <xref target="CCM"/>.
This MAY be the same frame counter used for securing 802.15.4
frames.
Other than the above requirements, the distribution or derivation of
the key(s) used for MLE security is outside the scope of this document.
The outgoing MLE frame counter MUST be handled as required by
<xref target="CCM"/>.
In particular, frame counters MUST NOT
be reused for any given key; if the outgoing MLE frame counter
reaches its maximum value (0xFFFFFFFF), secured MLE messages
MUST NOT be sent until a new key is available, at which point the
outgoing MLE frame counter MAY be set back to zero.
</t>
</section>
<section title="Command Format" anchor="sec:commands">
<t>
MLE messages consist of a command type and a series of type-length-value
parameters.
</t>
<t>
<figure align="left">
<artwork align="left"><![CDATA[
+--------------+-----+-----+-----+
| Command Type | TLV | ... | TLV |
+--------------+-----+-----+-----+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="12">
<t hangText="Command Type">
An eight-bit unsigned integer identifying the type of message.
This
document defines the following commands:
<list style="hanging" hangIndent="5">
<t hangText="0">Link Request. A request to establish a
link to a neighbor. </t>
<t hangText="1">Link Accept. Accept a requested link.</t>
<t hangText="2">Link Accept and Request. Accept a requested
link and request a link with the sender of the
original request. </t>
<t hangText="3">Link Reject. Reject a link request. </t>
<t hangText="4">Advertisement. Inform neighbors of
a device's link state.</t>
<t hangText="5">Update. Informs of changes to link parameters
shared by all nodes in a network.</t>
<t hangText="6">Update Request. Request that an Update message
be sent.</t>
</list>
The first four (Link Request, Link Accept,
Link Accept and Request, and Link Reject) are collectively
referred to as link configuration messages.
</t>
<t hangText="TLVs">
Zero or more TLV frames. These are described in
<xref target="sec:values"/>.
</t>
</list>
</t>
</section>
<section title="TLV Formats" anchor="sec:values">
<t>
Values are encoded using a type-length-value format,
where the type and length are one byte each and the
length field contains the length of the value in
bytes.
TLVs are stored serially with no padding between them.
They are byte-aligned but are not aligned in
any other way such as on 2 or 4 byte boundaries.
All values in TLVs are in network byte order.
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Type">An eight-bit unsigned integer giving
the type of the value, from IANA registry
<xref target="iana:tlvs"/>.
</t>
<t hangText="Length">An eight-bit unsigned integer giving
the length of the Value field in bytes.</t>
<t hangText="Value">Length bytes of value, formatted
as defined for the Type.</t>
</list>
</t>
<t>
With the exceptions of the Source Address TLV and Parameter TLV,
an MLE message MUST NOT
contain two or more TLVs of the same type.
To allow devices to have multiple source addresses,
an MLE message MAY contain two or more Source Address TLVs.
</t>
<section title="Source Address">
<t>
The Source Address TLV (TLV Type 0) has a Value containing
a byte string representing a link-layer address assigned
to the source of the message.
A given radio interface may have multiple link-layer addresses.
This TLV is used to communicate any source address(es) that
is not included in the message by the link layer itself.
</t>
</section>
<section title="Mode">
<t>
The Mode TLV (TLV Type 1) has a Value containing
a byte string representing the mode in which this link is
used by the source of the message.
The format of the value is that of the
Capability Information field in the 802.15.4 Associate command
as described in <xref target="IEEE802154"/>.
</t>
</section>
<section title="Timeout">
<t>
The Timeout TLV (TLV Type 2) has a Value containing
a 32-bit unsigned integer.
The value is the expected maximum interval between
transmissions by the sender, in seconds.
This allows the receiver to more accurately timeout a
link to a neighbor that polls for its incoming messages.
</t>
</section>
<section title="Challenge">
<t>
The Challenge TLV (TLV Type 3) has a Value containing
a randomly-chosen byte string that is used to determine
the freshness of any reply to this message.
The recommendations in
<xref target="RFC4086"/>
apply with regard to generation of the challenge value.
The byte string MUST be at least 4 bytes in length
and
a new value MUST be chosen for each Challenge TLV transmitted.
An important part of replay protection is determining
if a newly-heard neighbor is actually present or
is a set of recorded messages.
This is done by sending a random challenge value to
the neighbor and then receiving that same value
in a Response TLV sent by the neighbor.
</t>
</section>
<section title="Response">
<t>
The Response TLV (TLV Type 4) has a Value containing
a byte string copied from a Challenge TLV.
</t>
</section>
<section title="Link-layer Frame Counter">
<t>
The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing
the sender's current outgoing link-layer Frame Counter,
encoded as an N-byte unsigned integer.
For 802.15.4 this is a 4-byte value.
</t>
</section>
<section title="Link Quality">
<t>
The Link Quality TLV (TLV Type 6) reports the sender's measured
link quality for messages received from its neighbors.
The format of the Link Quality value is as follows:
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Res | Size | Neighbor Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="C">Complete: "1" if the message includes all
neighboring routers for which the source has link quality data.
Multicast Link Quality TLVs normally contain complete
information; a unicast to a particular neighbor would
normally contain only that neighbor's link quality
and would have the C flag set to "0".
</t>
<t hangText="Res">Reserved; MUST be set to 000
and SHOULD be ignored on receipt.
</t>
<t hangText="Size">The size in bytes of the included
neighbor link-layer addresses, minus 1. This supports addresses
of lengths 1 to 16 bytes.</t>
<t hangText="Neighbor Data">A sequence of neighbor records,
each containing receive and transmit state flags, the estimated
incoming link reliability (IDR), and the
neighbor's link-layer address.</t>
</list>
</t>
<t>
The neighbor data in a Link Quality TLV is formatted as follows:
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|O|P|reserved | Incoming IDR | Neighbor Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="I(ncoming)">"1" if the sender's Receive State
for this neighbor is true, "0" if not.
</t>
<t hangText="O(utgoing)">
"1" if the sender's Transmit State
for this neighbor is true, "0" if not.
</t>
<t hangText="P(riority)">
"1" if the sender expects to use this link for sending
messages, "0" if not. Given limited resources, the P flag
MAY be used in deciding which links should be maintained.
</t>
<t hangText="Incoming IDR">The estimated inverse delivery
ratio of messages
sent by the neighbor to the source of this message.
This is an eight-bit unsigned integer.
To allow for fractional IDR, the value encoded is multiplied by 32.
A perfect link, with an actual IDR of 1, would
have an Incoming IDR of 0x20.
A value of 0xFF indicates that the link is unusable.
</t>
<t hangText="Address">A link-layer address of a neighbor.</t>
</list>
The I and O flags are used to facilitate the two-way use
of links between neighboring routers.
</t>
<t>
A node that does not have a link configured to a neighbor but
receives a Link Quality TLV from that neighbor with the
node's O flag set to "1" SHOULD send an MLE message with a
Link Quality TLV with that neighbor's I bit set to "0".
This message may either be a regular multicast Advertisement
or a unicast to that neighbor containing only a single
Neighbor Data record.
</t>
</section>
<section title="Network Parameter">
<t>
The Parameter TLV (TLV Type 7) specifies the value of a
link-layer parameter shared across the network (as opposed to
a parameter specific to a particular link). The Value contains three
fields:
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Delay
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Parameter ID">The ID of the parameter to
be changed.</t>
<t hangText="Delay">The delay before setting
the parameter, in milliseconds. This is a four-byte
unsigned integer.
Having a delay gives time for
the new value to propagate throughout the network.
It may also be used for limiting the time a particular parameter
setting is in use, by including two different values for a
single parameter, with two different delays. </t>
<t hangText="Value">A byte string containing the new value of
the parameter. The format of this value is determined by
the particular parameter</t>
</list>
</t><t>
Update messages MUST contain only Network Parameter TLVs.
Update messages with new parameter settings are normally multicast
to the entire MLE domain.
They may also be unicast to nodes that have just joined the network
or otherwise do not have up-to-data parameter information.
</t><t>
The defined Network Parameters are:
<list style="hanging" hangIndent="5">
<t hangText="0">Channel</t>
<t hangText="1">PAN ID</t>
<t hangText="2">Permit Joining</t>
<t hangText="3">Beacon Payload</t>
</list>
</t>
</section>
<section title="MLE Frame Counter">
<t>
The MLE Frame Counter TLV (TLV Type 8) has a Value containing
the sender's current outgoing MLE Frame Counter,
encoded as an 32-bit unsigned integer.
</t>
</section>
</section>
<section title="Message transmission">
<t>
MLE messages SHOULD be sent using
the assigned UDP port number (19788)
as both the source and destination port.
Link configuration and advertisement messages MUST be sent with
an IP Hop Limit of 255, either to a link-local unicast address
or to the link-local all-nodes (FF02::1) or all-routers (FF02::2)
multicast addresses.
Update messages MAY be sent as above,
or MAY be sent to a site-local all-MLE-nodes
multicast address (to be assigned by IANA).
</t><t>
Outgoing link configuration and advertisement messages
SHOULD be secured using the
procedure specified in <xref target="AES"></xref> and
<xref target="CCM"></xref> using the auxiliary security
header as described in <xref target="IEEE802154"/>.
The one exception to this is
messages sent to or from a device that is joining the
network and does not yet have the necessary keys;
such unsecured messages MUST NOT contain Challenge,
Response, or Link-Layer Frame Counter TLVs.
</t><t>
The authenticated data consists of
the following three values concatenated together:
<figure align="center">
<artwork align="center"><![CDATA[
IP source address
IP destination address
auxiliary security header
]]>
</artwork>
</figure>
The secured data consists of the messages body following the
auxiliary security header (the command ID and TLVs).
The security suite identifier is not included in either the
authenticated data or the secured data.
Key choice is outside the scope of this document.
</t><t>
In order to allow update messages to be forwarded multiple hops,
outgoing update messages, MUST be secured at the link layer,
if link layer security is in use,
and MUST NOT be secured by MLE.
</t><t>
A message sent in response to a multicast request, such
as a multicast Link Request,
MUST be delayed by a random time between 0 and
MAX_RESPONSE_DELAY_TIME seconds, with a resolution of
at least 1ms.
<list style="hanging" hangIndent="5">
<t hangText="MAX_RESPONSE_DELAY_TIME"> 1 second </t>
</list>
</t><t>
If no response is received to a unicast request, the request
MAY be retransmitted using a simple timeout mechanism.
This is based on the retransmission mechanism used in
DHCPv6 <xref target="RFC3315">RFC 3315</xref>,
simplified to use a single, fixed timeout.
Unicast requests are not relayed, which avoids the need
for a more elaborate mechanism.
</t><t>
<figure align="left">
<artwork align="left"><![CDATA[
Parameter Default Description
-------------------------------------------------------
URT 1 sec Unicast Retransmission timeout.
MRT 5 sec Multicast Retransmission timeout.
MRC 3 Maximum retransmission count.
]]>
</artwork>
</figure>
</t><t>
For each transmission the appropriate URT or MRT value
is multiplied by
a random number chosen with a uniform distribution
between 0.9 and 1.1 with a resolution of at least 1ms.
The randomization factor is included to minimize
synchronization of messages transmitted.
</t>
</section>
<section title="Processing of incoming messages">
<t>
Any incoming link configuration or advertisement message, or
an incoming update sent to a link-local address,
whose IP Hop Limit is not 255
may have been forwarded by a router and MUST be discarded.
</t><t>
Incoming messages whose Command Type is a reserved value MUST be ignored.
Any TLVs in an incoming message whose TLV Type has a reserved value
MUST be ignored.
</t><t>
Incoming messages that are not secured with either MLE or
link-layer security SHOULD be ignored.
The one exception to this is
messages sent to or from a device that is joining the
network and does not yet have the necessary keys.
Secured incoming messages are decrypted and authenticated using the
procedures specified in <xref target="AES"></xref> and
<xref target="CCM"></xref>, with security material obtained
from the auxiliary security header as described in
<xref target="IEEE802154"/>.
The key source may be obtained either from the link layer source
address or from the auxiliary security header.
</t><t>
A device MUST maintain a separate incoming MLE frame counter for each
neighbor with which it establishes a link.
Any MLE message received with a frame counter the same or
lower than that of a previously received and authenticated
message from the same source MUST be discarded.
Messages for which no previous frame counter are available
MAY be processed, but their counter value MUST be saved for
comparison with later messages.
</t>
</section>
<section title="Link Configuration">
<t>
The values that may need to be communicated to configure
an 802.15.4 link are:
<list style="symbols">
<t> Long (64-bit) and short (16-bit) addresses. </t>
<t> Capability Information, as in the 802.15.4 Association
command in <xref target="IEEE802154"/>,
especially the Device Type
and Receiver On When Idle fields. </t>
<t> Initialization of AES-CCM frame counters.</t>
</list>
A device wishing to establish a link to a neighbor MUST
send a Link Request message containing the following:
<list style="symbols">
<t> Source Address TLV, containing the sender's short (16-bit) MAC
address. The sender's long (64-bit) MAC
address MUST used as the MAC source address of the message.</t>
<t> Mode TLV, containing the sender's Capability data byte. </t>
<t> Timeout TLV, if the sender is an rxOffWhenIdle device. </t>
<t> Challenge TLV, whose size is determined by the network
configuration.</t>
</list>
The neighbor SHOULD respond with a Link Accept message containing the
same TLVs (with its own values), but with a Response TLV in place
of the Challenge TLV and with added Link-layer Frame Counter
and MLE Frame Counter TLVs.
If large numbers of Link Request messages arrive a device MAY reduce
or completely suspend sending Link Accept messages, and MAY
send Link Reject messages instead.
The MLE Frame Counter TLV MAY be omitted if the sender uses
the same counter for both MLE and 802.15.4 messages.
If the neighbor also requires a liveness check, it MAY include
its own challenge, and use the Link Accept And Request message
type.
</t><t>
If a node receives a secured 802.15.4 unicast from a neighbor
for whom it does not have link configuration data,
the receiving node SHOULD respond with a Link Reject message to
inform the neighbor that the link is not configured.
If large numbers of such messages arrive a device MAY reduce
or completely suspend sending Link Reject messages.
</t>
<t>
Link Configuration messages are used to
establish 802.15.4 security and so MUST
NOT be secured at the 802.15.4 layer.
</t>
</section>
<section title="Parameter Dissemination">
<t>
Update messages may be sent to change the channel, PAN ID, and/or
permit joining flags on all nodes.
Determining when these values should be changed is beyond the
scope of this document.
</t>
<t>
To make a network-wide change to one of these parameters,
an MLE update messages SHOULD be sent to an appropriate
multicast address, such as the site-local all-node,
all-routers or all-MLE-nodes
multicast address (to be assigned by IANA).
Alternatively, MLE update messages MAY be unicast to
individual devices, either to avoid the cost of a
multicast or to have the parameter change apply to
only a subset of devices.
This requires some
form of multi-hop multicast forwarding;
these messages are sent infrequently, so forwarding with
simple flooding is sufficient.
</t>
<t>
A single update message MAY contain multiple values for the
same parameter with different time delays.
In particular, the permit joining flag can be enabled for a
limited time by including both on and off values in a
single update message.
</t>
<t>
A device that does not have the current network values,
either because it has just joined the network or for any
other reason, MAY send a unicast Update Request to a
neighbor.
The neighbor responds by sending an Update message
containing the current values of the parameters.
</t>
</section>
<section title="Neighbor Detection">
<t>
Nodes MAY send out periodic advertisements containing
the incoming IDR values for their neighbors.
The primary purpose of these messages is to allow nodes to
choose likely candidates for link establishment.
They can also be used to determine if existing links
continue to provide sufficient two-way reliability.
</t>
<t>
A node maintains two boolean values for each known neighbor:
<list style="hanging" hangIndent="10">
<t hangText="Receive State">
True if the node will accept incoming non-MLE messages from
that neighbor.</t>
<t hangText="Transmit State">
A local cache of the neighbor's Receive State corresponding to
this node.</t>
</list>
Both values default to false.
</t>
<t>
The Receive State is set to true when the node receives a
valid incoming link accept from the neighbor, and set to false
when the link configuration information is discarded for any
reason (link failure or timeout, for example).
</t>
<t>
The Transmit State is set to true when a link accept message is
sent to the neighbor.
When an advertisement message is received from the neighbor the
Transmit State is set to the Receive State
as reported in the advertisement.
If the advertisement's C flag is 1 and the receiving node's
address is not included in the advertisement, the recipient's
Transmit State for the sender is set to false.
</t>
<t>
These states are advisory only; a node may send a message to
a neighbor
regardless of its Transmit State for that neighbor.
Similarly, a node may unilaterally change its Receive State
(and discard any link configuration data)
without first informing the neighbor of its intention.
The change in Receive State will be reflected in the next
advertisement sent by the node.
</t>
<t>
Advertisement messages are used prior to
establishing 802.15.4 security and thus SHOULD
NOT be secured at the 802.15.4 layer.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t> The author would like to acknowledge the helpful comments of
Thomas Clausen, Robert Cragie, Colin O'Flynn, Edward Hill,
Matteo Paris, Kundok Park, Joseph Reddy, and Dario Tedeschi,
which greatly improved the document.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section title="IANA Considerations" anchor="sec:IANA">
<t>
IANA has assigned UDP port 19788 to MLE.
</t>
<t>
IANA is requested to establish a new top-level registry, called
"MLE: Mesh Link Establishment", to contain all MLE
objects, codepoints, and sub-registries.
</t><t>
The allocation policy for each new registry is by IETF review: new
values are assigned through the IETF review process .
</t>
<section title="Security Suites" anchor="iana:sec-suites">
<t>
IANA is requested to create a subregistry, called "Security Suites".
Values range from 0 to 255.
<figure align="left">
<artwork align="left">
<![CDATA[
Value Meaning Reference
0 802.15.4 Security This document
255 No Security This document
]]>
</artwork>
</figure>
Values 1-254 are currently unassigned.
</t>
</section>
<section title="Command Types" anchor="iana:commands">
<t>
IANA is requested to create a subregistry, called "Command Types".
Values range from 0 to 255.
<figure align="left">
<artwork align="left">
<![CDATA[
Value Meaning Reference
0 Link Request This document
1 Link Accept This document
2 Link Accept and Request This document
3 Link Reject This document
4 Advertisement This document
5 Update This document
6 Update Request This document
]]>
</artwork>
</figure>
Values 7-255 are currently unassigned.
</t>
</section>
<section title="TLV Types" anchor="iana:tlvs">
<t>
IANA is requested to create a subregistry, called "TLV Types".
Values range from 0 to 255.
<figure align="left">
<artwork align="left">
<![CDATA[
Value Meaning Reference
0 Source Address This document
1 Mode This document
2 Timeout This document
3 Challenge This document
4 Response This document
5 Link-layer Frame Counter This document
6 Link Quality This document
7 Network Parameter This document
8 MLE Frame Counter This document
]]>
</artwork>
</figure>
Values 9-255 are currently unassigned.
</t>
</section>
<section title="Network Parameters" anchor="iana:params">
<t>
IANA is requested to create a subregistry, called "Network Parameters".
Values range from 0 to 255.
<figure align="left">
<artwork align="left">
<![CDATA[
Value Meaning Reference
0 Channel This document
1 PAN ID This document
2 Permit Joining This document
3 Beacon Payload This document
]]>
</artwork>
</figure>
Values 4-255 are currently unassigned.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t> In general MLE has the strengths and weaknesses of the
link layer security that it inherits.
The one exception is that MLE's operation requires accepting and
acting on incoming Advertisements and Link Requests messages for
which the receiver has no prior knowledge of the sender's MLE
frame counter.
Because of this, implementers must be careful in how they use
information obtained from these possibly-replayed messages.
For example, information from unsecured messages should
not be used to modify any stored information obtained from
secured messages.
</t><t>
The Hop Limit field of received packets other than multihop
update messages is verified to contain
255, the maximum legal value. Because routers decrement the Hop
Limit on all packets they forward, received packets containing a Hop
Limit of 255 must have originated from a neighbor. This technique
is borrowed from IPv6 ND <xref target="RFC4861"/>.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<reference anchor="CCM">
<front>
<title>Recommendation for
Block Cipher Modes of
Operation: The CCM Mode for
Authentication and
Confidentiality
</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="May" year="2004"></date>
</front>
<seriesInfo name="SP" value="800-38C"></seriesInfo>
</reference>
<reference anchor="AES">
<front>
<title>Specification for the Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2001"></date>
</front>
<seriesInfo name="FIPS" value="197"></seriesInfo>
</reference>
<reference anchor="IEEE802154">
<front>
<title>Wireless Personal Area Networks</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2006"></date>
</front>
<seriesInfo name="IEEE Standard" value="802.15.4-2006"></seriesInfo>
</reference>
&RFC4086;
</references>
<references title="Informative References">
&RFC3315;
&RFC4861;
&RFC6551;
<reference anchor="ZigBeeIP" target="http://www.zigbee.org/non-menu-pages/zigbee-ip-download">
<front>
<title>ZigBee IP Specification</title>
<author>
<organization>ZigBee Alliance</organization>
</author>
<date year="2014"></date>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:34:32 |