< draft-kelsey-intarea-mesh-link-establishment-05.txt   draft-kelsey-intarea-mesh-link-establishment-06.txt >
Internet Area WG R. Kelsey Internet Area WG R. Kelsey
Internet-Draft Silicon Labs Internet-Draft Silicon Labs
Intended status: Standards Track February 21, 2013 Intended status: Standards Track May 23, 2014
Expires: August 25, 2013 Expires: November 24, 2014
Mesh Link Establishment Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-05 draft-kelsey-intarea-mesh-link-establishment-06
Abstract Abstract
This document defines the mesh link establishment (MLE) protocol for This document defines the mesh link establishment (MLE) protocol for
establishing and configuring secure radio links in IEEE 802.15.4 establishing and configuring secure radio links in IEEE 802.15.4
radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop
mesh networks by adding three capabilities: 1) dynamically mesh networks by adding three capabilities: 1) dynamically
configuring and securing radio links, 2) enabling network-wide configuring and securing radio links, 2) enabling network-wide
changes to radio parameters, and 3) detecting neighboring devices. changes to radio parameters, and 3) detecting neighboring devices.
MLE operates below the routing layer, insulating it from the details MLE operates below the routing layer, insulating it from the details
of configuring, securing, and maintaining individual radio links of configuring, securing, and maintaining individual radio links
within a larger mesh network. within a larger mesh network.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 25, 2013. This Internet-Draft will expire on November 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Link Configuration . . . . . . . . . . . . . . . . . . . . 6 4.1. Link Configuration . . . . . . . . . . . . . . . . . . . 5
4.2. Parameter Dissemination . . . . . . . . . . . . . . . . . 6 4.2. Parameter Dissemination . . . . . . . . . . . . . . . . . 5
4.3. Neighbor Detection . . . . . . . . . . . . . . . . . . . . 7 4.3. Neighbor Detection . . . . . . . . . . . . . . . . . . . 5
5. Security Formats . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Formats . . . . . . . . . . . . . . . . . . . . . . 5
6. Command Format . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Command Format . . . . . . . . . . . . . . . . . . . . . . . 6
7. TLV Formats . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. TLV Formats . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Source Address . . . . . . . . . . . . . . . . . . . . . 8
7.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 8
7.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 9
7.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . . 11 7.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . 9
7.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 11 7.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . 9
7.8. Network Parameter . . . . . . . . . . . . . . . . . . . . 13 7.8. Network Parameter . . . . . . . . . . . . . . . . . . . . 10
7.9. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 14 7.9. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 11
8. Message transmission . . . . . . . . . . . . . . . . . . . . . 15 8. Message transmission . . . . . . . . . . . . . . . . . . . . 12
9. Processing of incoming messages . . . . . . . . . . . . . . . 17 9. Processing of incoming messages . . . . . . . . . . . . . . . 13
10. Link Configuration . . . . . . . . . . . . . . . . . . . . . . 18 10. Link Configuration . . . . . . . . . . . . . . . . . . . . . 13
11. Parameter Dissemination . . . . . . . . . . . . . . . . . . . 19 11. Parameter Dissemination . . . . . . . . . . . . . . . . . . . 14
12. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . . 20 12. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
14.1. Security Suites . . . . . . . . . . . . . . . . . . . . . 22 14.1. Security Suites . . . . . . . . . . . . . . . . . . . . 16
14.2. Command Types . . . . . . . . . . . . . . . . . . . . . . 22 14.2. Command Types . . . . . . . . . . . . . . . . . . . . . 17
14.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 22 14.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . 17
14.4. Network Parameters . . . . . . . . . . . . . . . . . . . . 23 14.4. Network Parameters . . . . . . . . . . . . . . . . . . . 17
15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
16.1. Normative References . . . . . . . . . . . . . . . . . . . 25 16.1. Normative References . . . . . . . . . . . . . . . . . . 18
16.2. Informative References . . . . . . . . . . . . . . . . . . 25 16.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The configuration of individual links in IEEE 802.15.4 mesh networks The configuration of individual links in IEEE 802.15.4 mesh networks
falls into a gap between standards. The IEEE 802.15.4 standard falls into a gap between standards. The IEEE 802.15.4 standard
provides for static point-to-point and star topologies while the provides for static point-to-point and star topologies while the
routing (L3) protocols used in multi-hop mesh networks assume that routing (L3) protocols used in multi-hop mesh networks assume that
the L2 links are already up and running. Effective mesh networking the L2 links are already up and running. Effective mesh networking
using IEEE 802.15.4 requires identifying, configuring, and securing using IEEE 802.15.4 requires identifying, configuring, and securing
usable links to neighboring devices as the network's membership and usable links to neighboring devices as the network's membership and
skipping to change at page 5, line 7 skipping to change at page 4, line 25
message and used to detect replayed messages. message and used to detect replayed messages.
IDR Inverse Delivery Ratio; the number of IDR Inverse Delivery Ratio; the number of
transmission attempts divided by the number of transmission attempts divided by the number of
successful transmissions in a given direction successful transmissions in a given direction
over a link. Used in computing the ETX value for over a link. Used in computing the ETX value for
a link. a link.
3. Applicability 3. Applicability
This protocol extends IEEE 802.15.4 with additional capabilities This protocol provides configuration and management mechanisms for
needed for multi-hop mesh networks. The protocol is designed to be using IEEE 802.15.4 links in IP-based multi-hop mesh networks. The
easily extended to add additional features or to be adapted for use protocol is designed to be easily extended to add additional
with other radio standards. 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
Section 4) as IEEE 802.15.4.
4. Overview 4. Overview
MLE adds three capabilities to IEEE 802.15.4: MLE adds three capabilities to IEEE 802.15.4:
o Dynamically configuring and securing radio links. o Dynamically configuring and securing radio links.
o Enabling network-wide changes to radio parameters. o Enabling network-wide changes to radio parameters.
o Detecting neighboring devices. o Detecting neighboring devices.
skipping to change at page 6, line 27 skipping to change at page 5, line 8
devices, is to make link management more efficient by detecting devices, is to make link management more efficient by detecting
unreliable links before any effort is spent configuring them. unreliable links before any effort is spent configuring them.
All MLE messages are sent using UDP. While UDP is not an obvious 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 choice for a protocol used for L2 configuration, it was chosen to
simplify integration of MLE into existing systems. simplify integration of MLE into existing systems.
4.1. Link Configuration 4.1. Link Configuration
Link configuration is done using link-local unicasts to exchange IEEE Link configuration is done using link-local unicasts to exchange IEEE
802.15.4 radio parameters (addresses, node capabilities, frame 802.15.4 radio parameters (addresses, node capabilities, and frame
counters) between neighbors. Link configuration messages are either counters) between neighbors. Link configuration messages are either
a request that the link be configured, or an acceptance or rejection a request that the link be configured, or an acceptance or rejection
of such a request. of such a request.
IEEE 802.15.4 security uses frame counters to detect replayed IEEE 802.15.4 security uses frame counters to detect replayed
messages. MLE uses a two-message challenge and response protocol to messages. MLE uses a two-message challenge and response protocol to
ensure that the MLE message containing a neighbor's frame counter is ensure that the MLE message containing a neighbor's frame counter is
not itself a replayed message. not itself a replayed message.
4.2. Parameter Dissemination 4.2. Parameter Dissemination
skipping to change at page 8, line 10 skipping to change at page 5, line 50
configuring unusable links, devices can use MLE to send link-local configuring unusable links, devices can use MLE to send link-local
multicasts containing their local link quality estimates. multicasts containing their local link quality estimates.
Neighboring nodes can then form an estimate of the two-way quality of Neighboring nodes can then form an estimate of the two-way quality of
their link to the sender. their link to the sender.
5. Security Formats 5. Security Formats
One of the main functions of MLE is to initialize link-layer One of the main functions of MLE is to initialize link-layer
security. This means that MLE itself cannot rely on 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. To avoid the cost and complexity of adding a second
security suite, MLE reuses that of 802.15.4. This document describes security suite, MLE reuses that of 802.15.4. [AES] in Counter with
two security suites, one with no security and the other using CBC-MAC Mode [CCM] as described in [IEEE802154]. Later extensions
Advanced Encryption Standard 128 [AES] in Counter with CBC-MAC Mode may include other security suites for use with other radio standards.
[CCM] as described in [IEEE802154]. Later extensions may include
other security suites for use with other radio standards.
An MLE message begins with single byte indicating the security suite 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 in that message. If that initial byte is "255" no security is
used and the messages has no additional security data. An initial used and the messages has no additional security data. An initial
byte of "0" indicates that the message is secured as described in byte of "0" indicates that the message is secured (encrypted and
[IEEE802154] (all codes are to be confirmed by IANA; see Section 14). authenticated) as described in [IEEE802154]. MLE messages thus have
MLE messages thus have one of the two following formats: one of the two following formats:
+-----+------------+---------+-----+ +-----+------------+---------+-----+
| 0 | Aux Header | Command | MIC | | 0 | Aux Header | Command | MIC |
+-----+------------+---------+-----+ +-----+------------+---------+-----+
+-----+---------+ +-----+---------+
| 255 | Command | | 255 | Command |
+-----+---------+ +-----+---------+
Aux Header Auxiliary Security Header as described in [IEEE802154]. Aux Header Auxiliary Security Header as described in [IEEE802154].
Command MLE command; see Section 6. Command MLE command; see Section 6.
MIC Message Integrity Code as described in [IEEE802154]. MIC Message Integrity Code as described in [IEEE802154].
MLE security MUST NOT use any key that is being used by the link (or
any other) layer. [CCM] requires that each key and nonce pair be
used exactly once, which is most easily achieved by using different
keys.
If MLE security is in use each device MUST maintain an outgoing MLE If MLE security is in use each device MUST maintain an outgoing MLE
frame counter for use in securing outgoing packets in compliance with frame counter for use in securing outgoing packets in compliance with
[CCM]. This MAY be the same frame counter used for securing 802.15.4 [CCM]. This MAY be the same frame counter used for securing 802.15.4
frames; in this case the same counter value MUST NOT be used for frames. Other than the above requirements, the distribution or
securing both an 802.15.4 message and an MLE message. 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
MLE security MUST NOT use any key that is being used by the link (or required by [CCM]. In particular, frame counters MUST NOT be reused
any other) layer. Other than the above requirements, the for any given key; if the outgoing MLE frame counter reaches its
distribution or derivation of the key(s) used for MLE security is maximum value (0xFFFFFFFF), secured MLE messages MUST NOT be sent
outside the scope of this document. until a new key is available, at which point the outgoing MLE frame
counter MAY be set back to zero.
6. Command Format 6. Command Format
MLE messages consist of a command type and a series of type-length- MLE messages consist of a command type and a series of type-length-
value parameters. value parameters.
+--------------+-----+-----+-----+ +--------------+-----+-----+-----+
| Command Type | TLV | ... | TLV | | Command Type | TLV | ... | TLV |
+--------------+-----+-----+-----+ +--------------+-----+-----+-----+
Command Type An eight-bit unsigned integer identifying the type of Command Type An eight-bit unsigned integer identifying the type of
message. This document defines the following commands message. This document defines the following commands:
(all codes are to be confirmed by IANA, see Section 14):
0 Link Request. A request to establish a link to a 0 Link Request. A request to establish a link to a
neighbor. neighbor.
1 Link Accept. Accept a requested link. 1 Link Accept. Accept a requested link.
2 Link Accept and Request. Accept a requested link 2 Link Accept and Request. Accept a requested link
and request a link with the sender of the original and request a link with the sender of the original
request. request.
skipping to change at page 10, line 9 skipping to change at page 7, line 39
and Request, and Link Reject) are collectively referred and Request, and Link Reject) are collectively referred
to as link configuration messages. to as link configuration messages.
TLVs Zero or more TLV frames. These are described in TLVs Zero or more TLV frames. These are described in
Section 7. Section 7.
7. TLV Formats 7. TLV Formats
Values are encoded using a type-length-value format, where the type 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 and length are one byte each and the length field contains the length
of the value in bytes. There are no alignment requirements and no of the value in bytes. TLVs are stored serially with no padding
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.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type An eight-bit unsigned integer giving the type of Type An eight-bit unsigned integer giving the type of
the value, from IANA registry Section 14.3. the value, from IANA registry Section 14.3.
skipping to change at page 10, line 51 skipping to change at page 8, line 35
The Mode TLV (TLV Type 1) has a Value containing a byte string 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 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 message. The format of the value is that of the Capability
Information field in the 802.15.4 Associate command as described in Information field in the 802.15.4 Associate command as described in
[IEEE802154]. [IEEE802154].
7.3. Timeout 7.3. Timeout
The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned
integer, most significant byte first. The value is the expected integer. The value is the expected maximum interval between
maximum interval between transmissions by the sender, in seconds. transmissions by the sender, in seconds. This allows the receiver to
This allows the receiver to more accurately timeout a link to a more accurately timeout a link to a neighbor that polls for its
neighbor that polls for its incoming messages. incoming messages.
7.4. Challenge 7.4. Challenge
The Challenge TLV (TLV Type 3) has a Value containing a randomly- The Challenge TLV (TLV Type 3) has a Value containing a randomly-
chosen byte string that is used to determine the freshness of any chosen byte string that is used to determine the freshness of any
reply to this message. The recommendations in [RFC4086] apply with reply to this message. The recommendations in [RFC4086] apply with
regard to generation of the challenge value. A new value MUST be regard to generation of the challenge value. The byte string MUST be
chosen for each Challenge TLV transmitted. An important part of at least 4 bytes in length and a new value MUST be chosen for each
replay protection is determining if a newly-heard neighbor is Challenge TLV transmitted. An important part of replay protection is
actually present or is a set of recorded messages. This is done by determining if a newly-heard neighbor is actually present or is a set
sending a random challenge value to the neighbor and then receiving of recorded messages. This is done by sending a random challenge
that same value in a Response TLV sent by the neighbor. value to the neighbor and then receiving that same value in a
Response TLV sent by the neighbor.
7.5. Response 7.5. Response
The Response TLV (TLV Type 4) has a Value containing a byte string The Response TLV (TLV Type 4) has a Value containing a byte string
copied from a Challenge TLV. copied from a Challenge TLV.
7.6. Link-layer Frame Counter 7.6. Link-layer Frame Counter
The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing 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 the sender's current outgoing link-layer Frame Counter, encoded as an
N-bit unsigned integer, most significant byte first. For 802.15.4 N-bit unsigned integer. For 802.15.4 this is a 32-bit value.
this is a 32-bit value.
7.7. Link Quality 7.7. Link Quality
The Link Quality TLV (TLV Type 6) reports the sender's measured link The Link Quality TLV (TLV Type 6) reports the sender's measured link
quality for messages received from its neighbors. The format of the quality for messages received from its neighbors. The format of the
Link Quality value is as follows: Link Quality value is as follows:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 27 skipping to change at page 11, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Delay | Parameter ID | Delay
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter ID The ID of the parameter to be changed. Parameter ID The ID of the parameter to be changed.
Delay The delay before setting the parameter, in Delay The delay before setting the parameter, in
milliseconds. This is a four-byte unsigned milliseconds. This is a four-byte unsigned
integer, most significant byte first. Having a integer. Having a delay gives time for the new
delay gives time for the new value to propagate value to propagate throughout the network. It
throughout the network. It may also be used for may also be used for limiting the time a
limiting the time a particular parameter setting particular parameter setting is in use, by
is in use, by including two different values for including two different values for a single
a single parameter, with two different delays. parameter, with two different delays.
Value A byte string containing the new value of the Value A byte string containing the new value of the
parameter. The format of this value is parameter. The format of this value is
determined by the particular parameter determined by the particular parameter
Update messages SHOULD contain only Network Parameter TLVs. Update Update messages MUST contain only Network Parameter TLVs. Update
messages with new parameter settings SHOULD be multicast to the messages with new parameter settings are normally multicast to the
entire MLE domain. They MAY also be unicast to nodes that have just 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 joined the network or otherwise do not have up-to-data parameter
information. information.
The defined Network Parameters are: The defined Network Parameters are:
0 Channel 0 Channel
1 PAN ID 1 PAN ID
2 Permit Joining 2 Permit Joining
3 Beacon Payload 3 Beacon Payload
(values to be confirmed by IANA)
7.9. MLE Frame Counter 7.9. MLE Frame Counter
The MLE Frame Counter TLV (TLV Type 8) has a Value containing the 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 sender's current outgoing MLE Frame Counter, encoded as an 32-bit
unsigned integer, most significant byte first. unsigned integer.
8. Message transmission 8. Message transmission
MLE messages SHOULD be sent using the assigned UDP port number MLE messages SHOULD be sent using the assigned UDP port number
(19788) as both the source and destination port. Link configuration (19788) as both the source and destination port. Link configuration
and advertisement messages MUST be sent with an IP Hop Limit of 255, 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 either to a link-local unicast address or to the link-local all-nodes
(FF02::1) or all-routers (FF02::2) multicast addresses. Update (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- messages MAY be sent as above, or MAY be sent to a site-local all-
MLE-nodes multicast address (to be assigned by IANA). MLE-nodes multicast address (to be assigned by IANA).
Outgoing link configuration and advertisement messages SHOULD be Outgoing link configuration and advertisement messages SHOULD be
secured using the procedure specified in [AES] and [CCM] using the secured using the procedure specified in [AES] and [CCM] using the
auxiliary security header as described in [IEEE802154]. Key choice auxiliary security header as described in [IEEE802154]. The one
is outside the scope of this document. The authenticated data exception to this is messages sent to or from a device that is
consists of the following three values concatenated together: 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.
IP source address The authenticated data consists of the following three values
IP destination address concatenated together:
auxiliary security header
IP source address
IP destination address
auxiliary security header
The secured data consists of the messages body following the The secured data consists of the messages body following the
auxiliary security header (the command ID and TLVs). The security auxiliary security header (the command ID and TLVs). The security
suite identifier is not included in either the authenticated data or suite identifier is not included in either the authenticated data or
the secured data. the secured data. Key choice is outside the scope of this document.
In order to allow update messages to be forwarded multiple hops, In order to allow update messages to be forwarded multiple hops,
outgoing update messages, SHOULD be secured at the link layer and outgoing update messages, MUST be secured at the link layer, if link
SHOULD NOT be secured by MLE. layer security is in use, and MUST NOT be secured by MLE.
A message sent in response to a multicast request, such as a A message sent in response to a multicast request, such as a
multicast Link Request, MUST be delayed by a random time between 0 multicast Link Request, MUST be delayed by a random time between 0
and MAX_RESPONSE_DELAY_TIME seconds. and MAX_RESPONSE_DELAY_TIME seconds, with a resolution of at least
1ms.
MAX_RESPONSE_DELAY_TIME 1 second MAX_RESPONSE_DELAY_TIME 1 second
If no response is received to a request, the request MAY be If no response is received to a unicast request, the request MAY be
retransmitted. Because MLE messages do not require complex retransmitted using a simple timeout mechanism. This is based on the
processing and are not relayed, a simple timeout scheme is used for retransmission mechanism used in DHCPv6 RFC 3315 [RFC3315],
retransmitting. This is based on the retransmission mechanism used simplified to use a single, fixed timeout. Unicast requests are not
in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed relayed, which avoids the need for a more elaborate mechanism.
timeout.
Parameter Default Description Parameter Default Description
------------------------------------------------------- -------------------------------------------------------
URT 1 sec Unicast Retransmission timeout. URT 1 sec Unicast Retransmission timeout.
MRT 5 sec Multicast Retransmission timeout. MRT 5 sec Multicast Retransmission timeout.
MRC 3 Maximum retransmission count. MRC 3 Maximum retransmission count.
For each transmission the appropriate URT or MRT value is multiplied For each transmission the appropriate URT or MRT value is multiplied
by a random number chosen with a uniform distribution between 0.9 and by a random number chosen with a uniform distribution between 0.9 and
1.1. The randomization factor is included to minimize 1.1 with a resolution of at least 1ms. The randomization factor is
synchronization of messages transmitted. included to minimize synchronization of messages transmitted.
9. Processing of incoming messages 9. Processing of incoming messages
Any incoming link configuration or advertisement message, or an Any incoming link configuration or advertisement message, or an
incoming update sent to a link-local address, whose IP Hop Limit is 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. not 255 may have been forwarded by a router and MUST be discarded.
Incoming Update messages that contain TLVs other than Network Incoming messages whose Command Type is a reserved value MUST be
Parameter TLVs SHOULD be ignored. Incoming Update Request messages ignored. Any TLVs in an incoming message whose TLV Type has a
that contain any TLVs SHOULD be ignored. reserved value MUST be ignored.
Unsecured incoming messages SHOULD be ignored. Secured incoming Incoming messages that are not secured with either MLE or link-layer
messages are decrypted and authenticated using the procedures security SHOULD be ignored. The one exception to this is messages
specified in [AES] and [CCM], with security material obtained from sent to or from a device that is joining the network and does not yet
the auxiliary security header as described in [IEEE802154]. The key have the necessary keys. Secured incoming messages are decrypted and
source may be obtained either from the link layer source address or authenticated using the procedures specified in [AES] and [CCM], with
from the auxiliary security header. security material obtained from the auxiliary security header as
described in [IEEE802154]. The key source may be obtained either
from the link layer source address or from the auxiliary security
header.
A device SHOULD maintain a separate incoming MLE frame counter for A device MUST maintain a separate incoming MLE frame counter for each
each neighbor. Any MLE message received with a frame counter the neighbor with which it establishes a link. Any MLE message received
same or lower than that of a previously received and authenticated with a frame counter the same or lower than that of a previously
message from the same source MUST be discarded. Messages for which received and authenticated message from the same source MUST be
no previous frame counter are available are not discarded and the discarded. Messages for which no previous frame counter are
counter value SHOULD be saved for comparison with later messages. available MAY be processed, but their counter value MUST be saved for
comparison with later messages.
10. Link Configuration 10. Link Configuration
The values that may need to be communicated to configure an 802.15.4 The values that may need to be communicated to configure an 802.15.4
link are: link are:
o Long (64-bit) and short (16-bit) addresses. o Long (64-bit) and short (16-bit) addresses.
o Capability Information, as in the 802.15.4 Association command in o Capability Information, as in the 802.15.4 Association command in
[IEEE802154], especially the Device Type and Receiver On When Idle [IEEE802154], especially the Device Type and Receiver On When Idle
fields. fields.
o Initialization of AES-CCM frame counters. o Initialization of AES-CCM frame counters.
A device wishing to establish a link to a neighbor SHOULD send a Link A device wishing to establish a link to a neighbor MUST send a Link
Request message containing the following: Request message containing the following:
o Source Address TLV, containing the sender's short (16-bit) MAC o Source Address TLV, containing the sender's short (16-bit) MAC
address. The sender's long (64-bit) MAC address MUST used as the address. The sender's long (64-bit) MAC address MUST used as the
MAC source address of the message. MAC source address of the message.
o Mode TLV, containing the sender's Capability data byte. o Mode TLV, containing the sender's Capability data byte.
o Timeout TLV, if the sender is an rxOffWhenIdle device. o Timeout TLV, if the sender is an rxOffWhenIdle device.
o Challenge TLV, whose size is determined by the network o Challenge TLV, whose size is determined by the network
configuration. configuration.
If the neighbor has sufficient resources to maintain an additional The neighbor SHOULD respond with a Link Accept message containing the
link, it SHOULD respond with a Link Accept message containing the
same TLVs (with its own values), but with a Response TLV in place of 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 the Challenge TLV and with added Link-layer Frame Counter and MLE
Frame Counter TLVs. The MLE Frame Counter TLV MAY be omitted if the Frame Counter TLVs. If large numbers of Link Request messages arrive
sender uses the same counter for both MLE and 802.15.4 messages. If a device MAY reduce or completely suspend sending Link Accept
the neighbor also required a liveness check, it MAY include its own messages, and MAY send Link Reject messages instead. The MLE Frame
challenge, and use the Link Accept And Request message type. 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.
If a node receives a secured 802.15.4 unicast from a neighbor for 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 whom it does not have link configuration data, the receiving node
SHOULD respond with a Link Reject message to inform the neighbor that SHOULD respond with a Link Reject message to inform the neighbor that
the link is not configured. the link is not configured. If large numbers of such messages arrive
a device MAY reduce or completely suspend sending Link Reject
messages.
Link Configuration messages are used to establish 802.15.4 security Link Configuration messages are used to establish 802.15.4 security
and so SHOULD NOT be secured at the 802.15.4 layer. and so MUST NOT be secured at the 802.15.4 layer.
11. Parameter Dissemination 11. Parameter Dissemination
Update messages may be sent to change the channel, PAN ID, and/or Update messages may be sent to change the channel, PAN ID, and/or
permit joining flags on all nodes. Determining when these values permit joining flags on all nodes. Determining when these values
should be changed is beyond the scope of this document. should be changed is beyond the scope of this document.
To make a network-wide change to one of these parameters, an MLE To make a network-wide change to one of these parameters, an MLE
update messages SHOULD be sent to an appropriate multicast address, update messages SHOULD be sent to an appropriate multicast address,
such as the site-local all-node, all-routers or all-MLE-nodes such as the site-local all-node, all-routers or all-MLE-nodes
multicast address (to be assigned by IANA). This requires some form multicast address (to be assigned by IANA). Alternatively, MLE
of multi-hop multicast forwarding; these messages are sent update messages MAY be unicast to individual devices, either to avoid
infrequently, so forwarding with simple flooding is sufficient. 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.
A single update message MAY contain multiple values for the same A single update message MAY contain multiple values for the same
parameter with different time delays. In particular, the permit parameter with different time delays. In particular, the permit
joining flag can be enabled for a limited time by including both on joining flag can be enabled for a limited time by including both on
and off values in a single update message. and off values in a single update message.
A device that does not have the current network values, either A device that does not have the current network values, either
because it has just joined the network or for any other reason, MAY because it has just joined the network or for any other reason, MAY
send a unicast Update Request to a neighbor. The neighbor responds send a unicast Update Request to a neighbor. The neighbor responds
by sending an Update message containing the current values of the by sending an Update message containing the current values of the
skipping to change at page 22, line 41 skipping to change at page 17, line 19
Value Meaning Reference Value Meaning Reference
0 Link Request This document 0 Link Request This document
1 Link Accept This document 1 Link Accept This document
2 Link Accept and Request This document 2 Link Accept and Request This document
3 Link Reject This document 3 Link Reject This document
4 Advertisement This document 4 Advertisement This document
5 Update This document 5 Update This document
6 Update Request This document 6 Update Request This document
Values 6-255 are currently unassigned. Values 7-255 are currently unassigned.
14.3. TLV Types 14.3. TLV Types
IANA is requested to create a subregistry, called "TLV Types". IANA is requested to create a subregistry, called "TLV Types".
Values range from 0 to 255. Values range from 0 to 255.
Value Meaning Reference Value Meaning Reference
0 Source Address This document 0 Source Address This document
1 Mode This document 1 Mode This document
2 Timeout This document 2 Timeout This document
3 Challenge This document 3 Challenge This document
4 Response This document 4 Response This document
5 Link-layer Frame Counter This document 5 Link-layer Frame Counter This document
6 Link Quality This document 6 Link Quality This document
7 Network Parameter This document 7 Network Parameter This document
8 MLE Frame Counter This document 8 MLE Frame Counter This document
Values 8-255 are currently unassigned. Values 9-255 are currently unassigned.
14.4. Network Parameters 14.4. Network Parameters
IANA is requested to create a subregistry, called "Network IANA is requested to create a subregistry, called "Network
Parameters". Values range from 0 to 255. Parameters". Values range from 0 to 255.
Value Meaning Reference Value Meaning Reference
0 Channel This document 0 Channel This document
1 PAN ID This document 1 PAN ID This document
2 Permit Joining This document 2 Permit Joining This document
skipping to change at page 25, line 15 skipping to change at page 18, line 41
16. References 16. References
16.1. Normative References 16.1. Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001. (AES)", FIPS 197, November 2001.
[CCM] National Institute of Standards and Technology, [CCM] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The "Recommendation for Block Cipher Modes of Operation: The
CCM Mode for Authentication and Confidentiality", SP 800- CCM Mode for Authentication and Confidentiality", SP
38C, May 2004. 800-38C, May 2004.
[IEEE802154] [IEEE802154]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Wireless Personal Area Networks", IEEE Standard 802.15.4- "Wireless Personal Area Networks", IEEE Standard
2006, 2006. 802.15.4-2006, 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
16.2. Informative References 16.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
 End of changes. 43 change blocks. 
142 lines changed or deleted 164 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/