idnits 2.17.1 draft-kelsey-intarea-mesh-link-establishment-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2014) is 3597 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area WG R. Kelsey 3 Internet-Draft Silicon Labs 4 Intended status: Standards Track May 23, 2014 5 Expires: November 24, 2014 7 Mesh Link Establishment 8 draft-kelsey-intarea-mesh-link-establishment-06 10 Abstract 12 This document defines the mesh link establishment (MLE) protocol for 13 establishing and configuring secure radio links in IEEE 802.15.4 14 radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop 15 mesh networks by adding three capabilities: 1) dynamically 16 configuring and securing radio links, 2) enabling network-wide 17 changes to radio parameters, and 3) detecting neighboring devices. 18 MLE operates below the routing layer, insulating it from the details 19 of configuring, securing, and maintaining individual radio links 20 within a larger mesh network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 24, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Link Configuration . . . . . . . . . . . . . . . . . . . 5 62 4.2. Parameter Dissemination . . . . . . . . . . . . . . . . . 5 63 4.3. Neighbor Detection . . . . . . . . . . . . . . . . . . . 5 64 5. Security Formats . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Command Format . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. TLV Formats . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Source Address . . . . . . . . . . . . . . . . . . . . . 8 68 7.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . 9 73 7.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . 9 74 7.8. Network Parameter . . . . . . . . . . . . . . . . . . . . 10 75 7.9. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 11 76 8. Message transmission . . . . . . . . . . . . . . . . . . . . 12 77 9. Processing of incoming messages . . . . . . . . . . . . . . . 13 78 10. Link Configuration . . . . . . . . . . . . . . . . . . . . . 13 79 11. Parameter Dissemination . . . . . . . . . . . . . . . . . . . 14 80 12. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . 15 81 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 14.1. Security Suites . . . . . . . . . . . . . . . . . . . . 16 84 14.2. Command Types . . . . . . . . . . . . . . . . . . . . . 17 85 14.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . 17 86 14.4. Network Parameters . . . . . . . . . . . . . . . . . . . 17 87 15. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 16.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 The configuration of individual links in IEEE 802.15.4 mesh networks 96 falls into a gap between standards. The IEEE 802.15.4 standard 97 provides for static point-to-point and star topologies while the 98 routing (L3) protocols used in multi-hop mesh networks assume that 99 the L2 links are already up and running. Effective mesh networking 100 using IEEE 802.15.4 requires identifying, configuring, and securing 101 usable links to neighboring devices as the network's membership and 102 physical environment change. Newly usable links need to be 103 identified and configured automatically, where configuration values 104 can include link-layer addresses, transmit and receive modes, 105 security parameters, and so forth. 107 Security configuration is particularly important, as IEEE 802.15.4's 108 replay protection applies only between a joining device and the IEEE 109 802.15.4 coordinator via which it joins the network. Replay 110 protection with other neighbors requires a synchronization step that 111 is not specified by IEEE 802.15.4. 113 MLE can also be used to distribute configuration values that are 114 shared across a network, such as the channel and PAN ID. Network- 115 wide configuration uses multicasts and requires some form of multi- 116 hop multicast forwarding. These messages are sent infrequently, so 117 forwarding with simple flooding is sufficient. 119 One of the most important properties of a radio link, how reliably 120 the two neighbors can communicate, often cannot be determined 121 unilaterally by either neighbor. Many 802.15.4 links are asymmetric, 122 where messages traveling one way across the link are received more or 123 less reliably than messages traveling in the opposite direction. 124 There is a chicken and egg problem here. It is a waste of effort to 125 configure a link that does not have sufficient two-way reliability to 126 be useful, but the two-way reliability cannot be determined without 127 exchanging messages over the link. MLE resolves this by allowing a 128 node to periodically multicast an estimate of the quality of its 129 links. This allows a node to determine if it has a usable radio link 130 to a neighbor without first configuring that link. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 2. Terminology 141 ETX Expected Transmission Count [RFC6551]; the number 142 of transmission attempts required to send a 143 packet over a particular link. Defined to be the 144 product of the IDR values for both directions. A 145 perfect link has an ETX of 1, less than perfect 146 links have higher ETX values. 148 Frame counter A value that is incremented with each new secured 149 message and used to detect replayed messages. 151 IDR Inverse Delivery Ratio; the number of 152 transmission attempts divided by the number of 153 successful transmissions in a given direction 154 over a link. Used in computing the ETX value for 155 a link. 157 3. Applicability 159 This protocol provides configuration and management mechanisms for 160 using IEEE 802.15.4 links in IP-based multi-hop mesh networks. The 161 protocol is designed to be easily extended to add additional 162 features. It could also be adapted for use with other single-hop 163 link protocols that have some of the same features (message 164 encryption, one-hop multicast) and omissions (listed at the start of 165 Section 4) as IEEE 802.15.4. 167 4. Overview 169 MLE adds three capabilities to IEEE 802.15.4: 171 o Dynamically configuring and securing radio links. 173 o Enabling network-wide changes to radio parameters. 175 o Detecting neighboring devices. 177 The first two are mutually independent; either one can be used 178 without the other. The purpose of the third, detecting neighboring 179 devices, is to make link management more efficient by detecting 180 unreliable links before any effort is spent configuring them. 182 All MLE messages are sent using UDP. While UDP is not an obvious 183 choice for a protocol used for L2 configuration, it was chosen to 184 simplify integration of MLE into existing systems. 186 4.1. Link Configuration 188 Link configuration is done using link-local unicasts to exchange IEEE 189 802.15.4 radio parameters (addresses, node capabilities, and frame 190 counters) between neighbors. Link configuration messages are either 191 a request that the link be configured, or an acceptance or rejection 192 of such a request. 194 IEEE 802.15.4 security uses frame counters to detect replayed 195 messages. MLE uses a two-message challenge and response protocol to 196 ensure that the MLE message containing a neighbor's frame counter is 197 not itself a replayed message. 199 4.2. Parameter Dissemination 201 Network-wide changes to radio parameters, such as moving the network 202 to a new channel, is done by multicasting the new value(s) to all 203 devices in the network. Along with the values themselves, the 204 multicast messages include a delay value indicating when the new 205 value takes effect. The delay avoids having the parameters change 206 while the multicast is still propagating. 208 In addition to network wide dissemination, a device that does not 209 have the current network values, either because it has just joined 210 the network or for any other reason, can send a unicast request to a 211 neighbor. The neighbor will respond by sending the current network 212 values. 214 4.3. Neighbor Detection 216 802.15.4 links can be asymmetric in that a link between neighboring 217 devices may be much more reliable in one direction than in the other. 218 This limits the usefulness of unilateral link quality detection: a 219 link that looks strong to one device may not be usable because it 220 works poorly in the other direction. To avoid wasting effort 221 configuring unusable links, devices can use MLE to send link-local 222 multicasts containing their local link quality estimates. 223 Neighboring nodes can then form an estimate of the two-way quality of 224 their link to the sender. 226 5. Security Formats 228 One of the main functions of MLE is to initialize link-layer 229 security. This means that MLE itself cannot rely on link-layer 230 security. To avoid the cost and complexity of adding a second 231 security suite, MLE reuses that of 802.15.4. [AES] in Counter with 232 CBC-MAC Mode [CCM] as described in [IEEE802154]. Later extensions 233 may include other security suites for use with other radio standards. 235 An MLE message begins with single byte indicating the security suite 236 used in that message. If that initial byte is "255" no security is 237 used and the messages has no additional security data. An initial 238 byte of "0" indicates that the message is secured (encrypted and 239 authenticated) as described in [IEEE802154]. MLE messages thus have 240 one of the two following formats: 242 +-----+------------+---------+-----+ 243 | 0 | Aux Header | Command | MIC | 244 +-----+------------+---------+-----+ 245 +-----+---------+ 246 | 255 | Command | 247 +-----+---------+ 249 Aux Header Auxiliary Security Header as described in [IEEE802154]. 251 Command MLE command; see Section 6. 253 MIC Message Integrity Code as described in [IEEE802154]. 255 MLE security MUST NOT use any key that is being used by the link (or 256 any other) layer. [CCM] requires that each key and nonce pair be 257 used exactly once, which is most easily achieved by using different 258 keys. 260 If MLE security is in use each device MUST maintain an outgoing MLE 261 frame counter for use in securing outgoing packets in compliance with 262 [CCM]. This MAY be the same frame counter used for securing 802.15.4 263 frames. Other than the above requirements, the distribution or 264 derivation of the key(s) used for MLE security is outside the scope 265 of this document. The outgoing MLE frame counter MUST be handled as 266 required by [CCM]. In particular, frame counters MUST NOT be reused 267 for any given key; if the outgoing MLE frame counter reaches its 268 maximum value (0xFFFFFFFF), secured MLE messages MUST NOT be sent 269 until a new key is available, at which point the outgoing MLE frame 270 counter MAY be set back to zero. 272 6. Command Format 274 MLE messages consist of a command type and a series of type-length- 275 value parameters. 277 +--------------+-----+-----+-----+ 278 | Command Type | TLV | ... | TLV | 279 +--------------+-----+-----+-----+ 281 Command Type An eight-bit unsigned integer identifying the type of 282 message. This document defines the following commands: 284 0 Link Request. A request to establish a link to a 285 neighbor. 287 1 Link Accept. Accept a requested link. 289 2 Link Accept and Request. Accept a requested link 290 and request a link with the sender of the original 291 request. 293 3 Link Reject. Reject a link request. 295 4 Advertisement. Inform neighbors of a device's link 296 state. 298 5 Update. Informs of changes to link parameters 299 shared by all nodes in a network. 301 6 Update Request. Request that an Update message be 302 sent. 304 The first four (Link Request, Link Accept, Link Accept 305 and Request, and Link Reject) are collectively referred 306 to as link configuration messages. 308 TLVs Zero or more TLV frames. These are described in 309 Section 7. 311 7. TLV Formats 313 Values are encoded using a type-length-value format, where the type 314 and length are one byte each and the length field contains the length 315 of the value in bytes. TLVs are stored serially with no padding 316 between them. They are byte-aligned but are not aligned in any other 317 way such as on 2 or 4 byte boundaries. All values in TLVs are in 318 network byte order. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | Value ... 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Type An eight-bit unsigned integer giving the type of 327 the value, from IANA registry Section 14.3. 329 Length An eight-bit unsigned integer giving the length 330 of the Value field in bytes. 332 Value Length bytes of value, formatted as defined for 333 the Type. 335 With the exceptions of the Source Address TLV and Parameter TLV, an 336 MLE message MUST NOT contain two or more TLVs of the same type. To 337 allow devices to have multiple source addresses, an MLE message MAY 338 contain two or more Source Address TLVs. 340 7.1. Source Address 342 The Source Address TLV (TLV Type 0) has a Value containing a byte 343 string representing a link-layer address assigned to the source of 344 the message. A given radio interface may have multiple link-layer 345 addresses. This TLV is used to communicate any source address(es) 346 that is not included in the message by the link layer itself. 348 7.2. Mode 350 The Mode TLV (TLV Type 1) has a Value containing a byte string 351 representing the mode in which this link is used by the source of the 352 message. The format of the value is that of the Capability 353 Information field in the 802.15.4 Associate command as described in 354 [IEEE802154]. 356 7.3. Timeout 358 The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned 359 integer. The value is the expected maximum interval between 360 transmissions by the sender, in seconds. This allows the receiver to 361 more accurately timeout a link to a neighbor that polls for its 362 incoming messages. 364 7.4. Challenge 366 The Challenge TLV (TLV Type 3) has a Value containing a randomly- 367 chosen byte string that is used to determine the freshness of any 368 reply to this message. The recommendations in [RFC4086] apply with 369 regard to generation of the challenge value. The byte string MUST be 370 at least 4 bytes in length and a new value MUST be chosen for each 371 Challenge TLV transmitted. An important part of replay protection is 372 determining if a newly-heard neighbor is actually present or is a set 373 of recorded messages. This is done by sending a random challenge 374 value to the neighbor and then receiving that same value in a 375 Response TLV sent by the neighbor. 377 7.5. Response 379 The Response TLV (TLV Type 4) has a Value containing a byte string 380 copied from a Challenge TLV. 382 7.6. Link-layer Frame Counter 384 The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing 385 the sender's current outgoing link-layer Frame Counter, encoded as an 386 N-bit unsigned integer. For 802.15.4 this is a 32-bit value. 388 7.7. Link Quality 390 The Link Quality TLV (TLV Type 6) reports the sender's measured link 391 quality for messages received from its neighbors. The format of the 392 Link Quality value is as follows: 394 0 1 2 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 |C| Res | Size | Neighbor Data ... 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 C Complete: "1" if the message includes all 401 neighboring routers for which the source has link 402 quality data. Multicast Link Quality TLVs 403 normally contain complete information; a unicast 404 to a particular neighbor would normally contain 405 only that neighbor's link quality and would have 406 the C flag set to "0". 408 Res Reserved; MUST be set to 000 and SHOULD be 409 ignored on receipt. 411 Size The size in bytes of the included neighbor link- 412 layer addresses, minus 1. This supports 413 addresses of lengths 1 to 16 bytes. 415 Neighbor Data A sequence of neighbor records, each containing 416 receive and transmit state flags, the estimated 417 incoming link reliability (IDR), and the 418 neighbor's link-layer address. 420 The neighbor data in a Link Quality TLV is formatted as follows: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |I|O|P|reserved | Incoming IDR | Neighbor Address ... 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 I(ncoming) "1" if the sender's Receive State for this 429 neighbor is true, "0" if not. 431 O(utgoing) "1" if the sender's Transmit State for this 432 neighbor is true, "0" if not. 434 P(riority) "1" if the sender expects to use this link for 435 sending messages, "0" if not. Given limited 436 resources, the P flag MAY be used in deciding 437 which links should be maintained. 439 Incoming IDR The estimated inverse delivery ratio of messages 440 sent by the neighbor to the source of this 441 message. This is an eight-bit unsigned integer. 442 To allow for fractional IDR, the value encoded is 443 multiplied by 32. A perfect link, with an actual 444 IDR of 1, would have an Incoming IDR of 0x20. A 445 value of 0xFF indicates that the link is 446 unusable. 448 Address A link-layer address of a neighbor. 450 The I and O flags are used to facilitate the two-way use of links 451 between neighboring routers. 453 A node that does not have a link configured to a neighbor but 454 receives a Link Quality TLV from that neighbor with the node's O flag 455 set to "1" SHOULD send an MLE message with a Link Quality TLV with 456 that neighbor's I bit set to "0". This message may either be a 457 regular multicast Advertisement or a unicast to that neighbor 458 containing only a single Neighbor Data record. 460 7.8. Network Parameter 462 The Parameter TLV (TLV Type 7) specifies the value of a link-layer 463 parameter shared across the network (as opposed to a parameter 464 specific to a particular link). The Value contains three fields: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Parameter ID | Delay 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Value ... 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Parameter ID The ID of the parameter to be changed. 476 Delay The delay before setting the parameter, in 477 milliseconds. This is a four-byte unsigned 478 integer. Having a delay gives time for the new 479 value to propagate throughout the network. It 480 may also be used for limiting the time a 481 particular parameter setting is in use, by 482 including two different values for a single 483 parameter, with two different delays. 485 Value A byte string containing the new value of the 486 parameter. The format of this value is 487 determined by the particular parameter 489 Update messages MUST contain only Network Parameter TLVs. Update 490 messages with new parameter settings are normally multicast to the 491 entire MLE domain. They may also be unicast to nodes that have just 492 joined the network or otherwise do not have up-to-data parameter 493 information. 495 The defined Network Parameters are: 497 0 Channel 499 1 PAN ID 501 2 Permit Joining 503 3 Beacon Payload 505 7.9. MLE Frame Counter 507 The MLE Frame Counter TLV (TLV Type 8) has a Value containing the 508 sender's current outgoing MLE Frame Counter, encoded as an 32-bit 509 unsigned integer. 511 8. Message transmission 513 MLE messages SHOULD be sent using the assigned UDP port number 514 (19788) as both the source and destination port. Link configuration 515 and advertisement messages MUST be sent with an IP Hop Limit of 255, 516 either to a link-local unicast address or to the link-local all-nodes 517 (FF02::1) or all-routers (FF02::2) multicast addresses. Update 518 messages MAY be sent as above, or MAY be sent to a site-local all- 519 MLE-nodes multicast address (to be assigned by IANA). 521 Outgoing link configuration and advertisement messages SHOULD be 522 secured using the procedure specified in [AES] and [CCM] using the 523 auxiliary security header as described in [IEEE802154]. The one 524 exception to this is messages sent to or from a device that is 525 joining the network and does not yet have the necessary keys; such 526 unsecured messages MUST NOT contain Challenge, Response, or Link- 527 Layer Frame Counter TLVs. 529 The authenticated data consists of the following three values 530 concatenated together: 532 IP source address 533 IP destination address 534 auxiliary security header 536 The secured data consists of the messages body following the 537 auxiliary security header (the command ID and TLVs). The security 538 suite identifier is not included in either the authenticated data or 539 the secured data. Key choice is outside the scope of this document. 541 In order to allow update messages to be forwarded multiple hops, 542 outgoing update messages, MUST be secured at the link layer, if link 543 layer security is in use, and MUST NOT be secured by MLE. 545 A message sent in response to a multicast request, such as a 546 multicast Link Request, MUST be delayed by a random time between 0 547 and MAX_RESPONSE_DELAY_TIME seconds, with a resolution of at least 548 1ms. 550 MAX_RESPONSE_DELAY_TIME 1 second 552 If no response is received to a unicast request, the request MAY be 553 retransmitted using a simple timeout mechanism. This is based on the 554 retransmission mechanism used in DHCPv6 RFC 3315 [RFC3315], 555 simplified to use a single, fixed timeout. Unicast requests are not 556 relayed, which avoids the need for a more elaborate mechanism. 558 Parameter Default Description 559 ------------------------------------------------------- 560 URT 1 sec Unicast Retransmission timeout. 561 MRT 5 sec Multicast Retransmission timeout. 562 MRC 3 Maximum retransmission count. 564 For each transmission the appropriate URT or MRT value is multiplied 565 by a random number chosen with a uniform distribution between 0.9 and 566 1.1 with a resolution of at least 1ms. The randomization factor is 567 included to minimize synchronization of messages transmitted. 569 9. Processing of incoming messages 571 Any incoming link configuration or advertisement message, or an 572 incoming update sent to a link-local address, whose IP Hop Limit is 573 not 255 may have been forwarded by a router and MUST be discarded. 575 Incoming messages whose Command Type is a reserved value MUST be 576 ignored. Any TLVs in an incoming message whose TLV Type has a 577 reserved value MUST be ignored. 579 Incoming messages that are not secured with either MLE or link-layer 580 security SHOULD be ignored. The one exception to this is messages 581 sent to or from a device that is joining the network and does not yet 582 have the necessary keys. Secured incoming messages are decrypted and 583 authenticated using the procedures specified in [AES] and [CCM], with 584 security material obtained from the auxiliary security header as 585 described in [IEEE802154]. The key source may be obtained either 586 from the link layer source address or from the auxiliary security 587 header. 589 A device MUST maintain a separate incoming MLE frame counter for each 590 neighbor with which it establishes a link. Any MLE message received 591 with a frame counter the same or lower than that of a previously 592 received and authenticated message from the same source MUST be 593 discarded. Messages for which no previous frame counter are 594 available MAY be processed, but their counter value MUST be saved for 595 comparison with later messages. 597 10. Link Configuration 599 The values that may need to be communicated to configure an 802.15.4 600 link are: 602 o Long (64-bit) and short (16-bit) addresses. 604 o Capability Information, as in the 802.15.4 Association command in 605 [IEEE802154], especially the Device Type and Receiver On When Idle 606 fields. 608 o Initialization of AES-CCM frame counters. 610 A device wishing to establish a link to a neighbor MUST send a Link 611 Request message containing the following: 613 o Source Address TLV, containing the sender's short (16-bit) MAC 614 address. The sender's long (64-bit) MAC address MUST used as the 615 MAC source address of the message. 617 o Mode TLV, containing the sender's Capability data byte. 619 o Timeout TLV, if the sender is an rxOffWhenIdle device. 621 o Challenge TLV, whose size is determined by the network 622 configuration. 624 The neighbor SHOULD respond with a Link Accept message containing the 625 same TLVs (with its own values), but with a Response TLV in place of 626 the Challenge TLV and with added Link-layer Frame Counter and MLE 627 Frame Counter TLVs. If large numbers of Link Request messages arrive 628 a device MAY reduce or completely suspend sending Link Accept 629 messages, and MAY send Link Reject messages instead. The MLE Frame 630 Counter TLV MAY be omitted if the sender uses the same counter for 631 both MLE and 802.15.4 messages. If the neighbor also requires a 632 liveness check, it MAY include its own challenge, and use the Link 633 Accept And Request message type. 635 If a node receives a secured 802.15.4 unicast from a neighbor for 636 whom it does not have link configuration data, the receiving node 637 SHOULD respond with a Link Reject message to inform the neighbor that 638 the link is not configured. If large numbers of such messages arrive 639 a device MAY reduce or completely suspend sending Link Reject 640 messages. 642 Link Configuration messages are used to establish 802.15.4 security 643 and so MUST NOT be secured at the 802.15.4 layer. 645 11. Parameter Dissemination 647 Update messages may be sent to change the channel, PAN ID, and/or 648 permit joining flags on all nodes. Determining when these values 649 should be changed is beyond the scope of this document. 651 To make a network-wide change to one of these parameters, an MLE 652 update messages SHOULD be sent to an appropriate multicast address, 653 such as the site-local all-node, all-routers or all-MLE-nodes 654 multicast address (to be assigned by IANA). Alternatively, MLE 655 update messages MAY be unicast to individual devices, either to avoid 656 the cost of a multicast or to have the parameter change apply to only 657 a subset of devices. This requires some form of multi-hop multicast 658 forwarding; these messages are sent infrequently, so forwarding with 659 simple flooding is sufficient. 661 A single update message MAY contain multiple values for the same 662 parameter with different time delays. In particular, the permit 663 joining flag can be enabled for a limited time by including both on 664 and off values in a single update message. 666 A device that does not have the current network values, either 667 because it has just joined the network or for any other reason, MAY 668 send a unicast Update Request to a neighbor. The neighbor responds 669 by sending an Update message containing the current values of the 670 parameters. 672 12. Neighbor Detection 674 Nodes MAY send out periodic advertisements containing the incoming 675 IDR values for their neighbors. The primary purpose of these 676 messages is to allow nodes to choose likely candidates for link 677 establishment. They can also be used to determine if existing links 678 continue to provide sufficient two-way reliability. 680 A node maintains two boolean values for each known neighbor: 682 Receive State True if the node will accept incoming non-MLE messages 683 from that neighbor. 685 Transmit State A local cache of the neighbor's Receive State 686 corresponding to this node. 688 Both values default to false. 690 The Receive State is set to true when the node receives a valid 691 incoming link accept from the neighbor, and set to false when the 692 link configuration information is discarded for any reason (link 693 failure or timeout, for example). 695 The Transmit State is set to true when a link accept message is sent 696 to the neighbor. When an advertisement message is received from the 697 neighbor the Transmit State is set to the Receive State as reported 698 in the advertisement. If the advertisement's C flag is 1 and the 699 receiving node's address is not included in the advertisement, the 700 recipient's Transmit State for the sender is set to false. 702 These states are advisory only; a node may send a message to a 703 neighbor regardless of its Transmit State for that neighbor. 704 Similarly, a node may unilaterally change its Receive State (and 705 discard any link configuration data) without first informing the 706 neighbor of its intention. The change in Receive State will be 707 reflected in the next advertisement sent by the node. 709 Advertisement messages are used prior to establishing 802.15.4 710 security and thus SHOULD NOT be secured at the 802.15.4 layer. 712 13. Acknowledgements 714 The author would like to acknowledge the helpful comments of Thomas 715 Clausen, Robert Cragie, Colin O'Flynn, Edward Hill, Matteo Paris, 716 Kundok Park, Joseph Reddy, and Dario Tedeschi, which greatly improved 717 the document. 719 14. IANA Considerations 721 IANA has assigned UDP port 19788 to MLE. 723 IANA is requested to establish a new top-level registry, called "MLE: 724 Mesh Link Establishment", to contain all MLE objects, codepoints, and 725 sub-registries. 727 The allocation policy for each new registry is by IETF review: new 728 values are assigned through the IETF review process . 730 14.1. Security Suites 732 IANA is requested to create a subregistry, called "Security Suites". 733 Values range from 0 to 255. 735 Value Meaning Reference 736 0 802.15.4 Security This document 737 255 No Security This document 739 Values 1-254 are currently unassigned. 741 14.2. Command Types 743 IANA is requested to create a subregistry, called "Command Types". 744 Values range from 0 to 255. 746 Value Meaning Reference 747 0 Link Request This document 748 1 Link Accept This document 749 2 Link Accept and Request This document 750 3 Link Reject This document 751 4 Advertisement This document 752 5 Update This document 753 6 Update Request This document 755 Values 7-255 are currently unassigned. 757 14.3. TLV Types 759 IANA is requested to create a subregistry, called "TLV Types". 760 Values range from 0 to 255. 762 Value Meaning Reference 763 0 Source Address This document 764 1 Mode This document 765 2 Timeout This document 766 3 Challenge This document 767 4 Response This document 768 5 Link-layer Frame Counter This document 769 6 Link Quality This document 770 7 Network Parameter This document 771 8 MLE Frame Counter This document 773 Values 9-255 are currently unassigned. 775 14.4. Network Parameters 777 IANA is requested to create a subregistry, called "Network 778 Parameters". Values range from 0 to 255. 780 Value Meaning Reference 781 0 Channel This document 782 1 PAN ID This document 783 2 Permit Joining This document 784 3 Beacon Payload This document 786 Values 4-255 are currently unassigned. 788 15. Security Considerations 790 In general MLE has the strengths and weaknesses of the link layer 791 security that it inherits. The one exception is that MLE's operation 792 requires accepting and acting on incoming Advertisements and Link 793 Requests messages for which the receiver has no prior knowledge of 794 the sender's MLE frame counter. Because of this, implementers must 795 be careful in how they use information obtained from these possibly- 796 replayed messages. For example, information from unsecured messages 797 should not be used to modify any stored information obtained from 798 secured messages. 800 The Hop Limit field of received packets other than multihop update 801 messages is verified to contain 255, the maximum legal value. 802 Because routers decrement the Hop Limit on all packets they forward, 803 received packets containing a Hop Limit of 255 must have originated 804 from a neighbor. This technique is borrowed from IPv6 ND [RFC4861]. 806 16. References 808 16.1. Normative References 810 [AES] National Institute of Standards and Technology, 811 "Specification for the Advanced Encryption Standard 812 (AES)", FIPS 197, November 2001. 814 [CCM] National Institute of Standards and Technology, 815 "Recommendation for Block Cipher Modes of Operation: The 816 CCM Mode for Authentication and Confidentiality", SP 817 800-38C, May 2004. 819 [IEEE802154] 820 Institute of Electrical and Electronics Engineers, 821 "Wireless Personal Area Networks", IEEE Standard 822 802.15.4-2006, 2006. 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 828 Requirements for Security", BCP 106, RFC 4086, June 2005. 830 16.2. Informative References 832 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 833 and M. Carney, "Dynamic Host Configuration Protocol for 834 IPv6 (DHCPv6)", RFC 3315, July 2003. 836 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 837 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 838 September 2007. 840 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 841 Barthel, "Routing Metrics Used for Path Calculation in 842 Low-Power and Lossy Networks", RFC 6551, March 2012. 844 Author's Address 846 Richard Kelsey 847 Silicon Labs 848 25 Thomson Place 849 Boston, Massachusetts 02210 850 USA 852 Phone: +1 617 951 1225 853 Email: richard.kelsey@silabs.com