idnits 2.17.1 draft-kelsey-6lo-mesh-link-establishment-00.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 (July 3, 2015) is 3220 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo R. Kelsey 3 Internet-Draft Silicon Labs 4 Intended status: Informational July 3, 2015 5 Expires: January 4, 2016 7 Mesh Link Establishment 8 draft-kelsey-6lo-mesh-link-establishment-00 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) determining link quality prior to 18 link configuration MLE operates below the routing layer, insulating 19 it from the details of configuring, securing, and maintaining 20 individual radio links 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 January 4, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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. Link Quality Determination . . . . . . . . . . . . . . . 5 64 5. Security Formats . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Command Format . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . 9 73 7.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . 9 74 7.8. Network Parameter . . . . . . . . . . . . . . . . . . . . 11 75 7.9. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 12 76 8. Message transmission . . . . . . . . . . . . . . . . . . . . 12 77 9. Processing of incoming messages . . . . . . . . . . . . . . . 13 78 10. Link Configuration . . . . . . . . . . . . . . . . . . . . . 14 79 11. Parameter Dissemination . . . . . . . . . . . . . . . . . . . 15 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 MLE was developed as part of the ZigBee IP networking standard 133 [ZigBeeIP]. This document describes the protocol as it was used in 134 that standard. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 [RFC2119]. 143 2. Terminology 145 ETX Expected Transmission Count [RFC6551]; the number 146 of transmission attempts required to send a 147 packet over a particular link. Defined to be the 148 product of the IDR values for both directions. A 149 perfect link has an ETX of 1, less than perfect 150 links have higher ETX values. 152 Frame counter A value that is incremented with each new secured 153 message and used to detect replayed messages. 155 IDR Inverse Delivery Ratio; the number of 156 transmission attempts divided by the number of 157 successful transmissions in a given direction 158 over a link. Used in computing the ETX value for 159 a link. 161 3. Applicability 163 This protocol provides configuration and management mechanisms for 164 using IEEE 802.15.4 links in IP-based multi-hop mesh networks. The 165 protocol is designed to be easily extended to add additional 166 features. It could also be adapted for use with other single-hop 167 link protocols that have some of the same features (message 168 encryption, one-hop multicast) and omissions (listed at the start of 169 Section 4) as IEEE 802.15.4. 171 4. Overview 173 MLE adds three capabilities to IEEE 802.15.4: 175 o Dynamically configuring and securing radio links. 177 o Enabling network-wide changes to radio parameters. 179 o Determining link quality, prior to link configuration. 181 The first two are mutually independent; either one can be used 182 without the other. The purpose of the third, determining link 183 quality, is to make link management more efficient by detecting 184 unreliable links before any effort is spent configuring them. 186 All MLE messages are sent using UDP. While UDP is not an obvious 187 choice for a protocol used for L2 configuration, it was chosen to 188 simplify integration of MLE into existing systems. 190 4.1. Link Configuration 192 Link configuration is done using link-local unicasts to exchange IEEE 193 802.15.4 radio parameters (addresses, node capabilities, and frame 194 counters) between neighbors. Link configuration messages are either 195 a request that the link be configured, or an acceptance or rejection 196 of such a request. 198 IEEE 802.15.4 security uses frame counters to detect replayed 199 messages. MLE uses a two-message challenge and response protocol to 200 ensure that the MLE message containing a neighbor's frame counter is 201 not itself a replayed message. 203 4.2. Parameter Dissemination 205 Network-wide changes to radio parameters, such as moving the network 206 to a new channel, is done by multicasting the new value(s) to all 207 devices in the network. Along with the values themselves, the 208 multicast messages include a delay value indicating when the new 209 value takes effect. The delay avoids having the parameters change 210 while the multicast is still propagating. 212 In addition to network wide dissemination, a device that does not 213 have the current network values, either because it has just joined 214 the network or for any other reason, can send a unicast request to a 215 neighbor. The neighbor will respond by sending the current network 216 values. 218 4.3. Link Quality Determination 220 802.15.4 links can be asymmetric in that a link between neighboring 221 devices may be much more reliable in one direction than in the other. 222 This limits the usefulness of unilateral link quality detection: a 223 link that looks strong to one device may not be usable because it 224 works poorly in the other direction. To avoid wasting effort 225 configuring unusable links, devices can use MLE to send link-local 226 multicasts containing their local link quality estimates. 227 Neighboring nodes can then form an estimate of the two-way quality of 228 their link to the sender. 230 5. Security Formats 232 One of the main functions of MLE is to initialize link-layer 233 security. This means that MLE itself cannot rely on link-layer 234 security. To avoid the cost and complexity of adding a second 235 security suite, MLE reuses that of 802.15.4. [AES] in Counter with 236 CBC-MAC Mode [CCM] as described in [IEEE802154]. Later extensions 237 may include other security suites for use with other radio standards. 239 An MLE message begins with single byte indicating the security suite 240 used in that message. If that initial byte is "255" no security is 241 used and the messages has no additional security data. An initial 242 byte of "0" indicates that the message is secured (encrypted and 243 authenticated) as described in [IEEE802154]. MLE messages thus have 244 one of the two following formats: 246 +-----+------------+---------+-----+ 247 | 0 | Aux Header | Command | MIC | 248 +-----+------------+---------+-----+ 249 +-----+---------+ 250 | 255 | Command | 251 +-----+---------+ 253 Aux Header Auxiliary Security Header as described in [IEEE802154]. 255 Command MLE command; see Section 6. 257 MIC Message Integrity Code as described in [IEEE802154]. 259 MLE security MUST NOT use any key that is being used by the link (or 260 any other) layer. [CCM] requires that each key and nonce pair be 261 used exactly once, which is most easily achieved by using different 262 keys. 264 If MLE security is in use each device MUST maintain an outgoing MLE 265 frame counter for use in securing outgoing packets in compliance with 266 [CCM]. This MAY be the same frame counter used for securing 802.15.4 267 frames. Other than the above requirements, the distribution or 268 derivation of the key(s) used for MLE security is outside the scope 269 of this document. The outgoing MLE frame counter MUST be handled as 270 required by [CCM]. In particular, frame counters MUST NOT be reused 271 for any given key; if the outgoing MLE frame counter reaches its 272 maximum value (0xFFFFFFFF), secured MLE messages MUST NOT be sent 273 until a new key is available, at which point the outgoing MLE frame 274 counter MAY be set back to zero. 276 6. Command Format 278 MLE messages consist of a command type and a series of type-length- 279 value parameters. 281 +--------------+-----+-----+-----+ 282 | Command Type | TLV | ... | TLV | 283 +--------------+-----+-----+-----+ 285 Command Type An eight-bit unsigned integer identifying the type of 286 message. This document defines the following commands: 288 0 Link Request. A request to establish a link to a 289 neighbor. 291 1 Link Accept. Accept a requested link. 293 2 Link Accept and Request. Accept a requested link 294 and request a link with the sender of the original 295 request. 297 3 Link Reject. Reject a link request. 299 4 Advertisement. Inform neighbors of a device's link 300 state. 302 5 Update. Informs of changes to link parameters 303 shared by all nodes in a network. 305 6 Update Request. Request that an Update message be 306 sent. 308 The first four (Link Request, Link Accept, Link Accept 309 and Request, and Link Reject) are collectively referred 310 to as link configuration messages. 312 TLVs Zero or more TLV frames. These are described in 313 Section 7. 315 7. TLV Formats 317 Values are encoded using a type-length-value format, where the type 318 and length are one byte each and the length field contains the length 319 of the value in bytes. TLVs are stored serially with no padding 320 between them. They are byte-aligned but are not aligned in any other 321 way such as on 2 or 4 byte boundaries. All values in TLVs are in 322 network byte order. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Value ... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type An eight-bit unsigned integer giving the type of 331 the value, from IANA registry Section 14.3. 333 Length An eight-bit unsigned integer giving the length 334 of the Value field in bytes. 336 Value Length bytes of value, formatted as defined for 337 the Type. 339 With the exceptions of the Source Address TLV and Parameter TLV, an 340 MLE message MUST NOT contain two or more TLVs of the same type. To 341 allow devices to have multiple source addresses, an MLE message MAY 342 contain two or more Source Address TLVs. 344 7.1. Source Address 346 The Source Address TLV (TLV Type 0) has a Value containing a byte 347 string representing a link-layer address assigned to the source of 348 the message. A given radio interface may have multiple link-layer 349 addresses. This TLV is used to communicate any source address(es) 350 that is not included in the message by the link layer itself. 352 7.2. Mode 354 The Mode TLV (TLV Type 1) has a Value containing a byte string 355 representing the mode in which this link is used by the source of the 356 message. The format of the value is that of the Capability 357 Information field in the 802.15.4 Associate command as described in 358 [IEEE802154]. 360 7.3. Timeout 362 The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned 363 integer. The value is the expected maximum interval between 364 transmissions by the sender, in seconds. This allows the receiver to 365 more accurately timeout a link to a neighbor that polls for its 366 incoming messages. 368 7.4. Challenge 370 The Challenge TLV (TLV Type 3) has a Value containing a randomly- 371 chosen byte string that is used to determine the freshness of any 372 reply to this message. The recommendations in [RFC4086] apply with 373 regard to generation of the challenge value. The byte string MUST be 374 at least 4 bytes in length and a new value MUST be chosen for each 375 Challenge TLV transmitted. An important part of replay protection is 376 determining if a newly-heard neighbor is actually present or is a set 377 of recorded messages. This is done by sending a random challenge 378 value to the neighbor and then receiving that same value in a 379 Response TLV sent by the neighbor. 381 7.5. Response 383 The Response TLV (TLV Type 4) has a Value containing a byte string 384 copied from a Challenge TLV. 386 7.6. Link-layer Frame Counter 388 The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing 389 the sender's current outgoing link-layer Frame Counter, encoded as an 390 N-byte unsigned integer. For 802.15.4 this is a 4-byte value. 392 7.7. Link Quality 394 The Link Quality TLV (TLV Type 6) reports the sender's measured link 395 quality for messages received from its neighbors. The format of the 396 Link Quality value is as follows: 398 0 1 2 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |C| Res | Size | Neighbor Data ... 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 C Complete: "1" if the message includes all 405 neighboring routers for which the source has link 406 quality data. Multicast Link Quality TLVs 407 normally contain complete information; a unicast 408 to a particular neighbor would normally contain 409 only that neighbor's link quality and would have 410 the C flag set to "0". 412 Res Reserved; MUST be set to 000 and SHOULD be 413 ignored on receipt. 415 Size The size in bytes of the included neighbor link- 416 layer addresses, minus 1. This supports 417 addresses of lengths 1 to 16 bytes. 419 Neighbor Data A sequence of neighbor records, each containing 420 receive and transmit state flags, the estimated 421 incoming link reliability (IDR), and the 422 neighbor's link-layer address. 424 The neighbor data in a Link Quality TLV is formatted as follows: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |I|O|P|reserved | Incoming IDR | Neighbor Address ... 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 I(ncoming) "1" if the sender's Receive State for this 433 neighbor is true, "0" if not. 435 O(utgoing) "1" if the sender's Transmit State for this 436 neighbor is true, "0" if not. 438 P(riority) "1" if the sender expects to use this link for 439 sending messages, "0" if not. Given limited 440 resources, the P flag MAY be used in deciding 441 which links should be maintained. 443 Incoming IDR The estimated inverse delivery ratio of messages 444 sent by the neighbor to the source of this 445 message. This is an eight-bit unsigned integer. 446 To allow for fractional IDR, the value encoded is 447 multiplied by 32. A perfect link, with an actual 448 IDR of 1, would have an Incoming IDR of 0x20. A 449 value of 0xFF indicates that the link is 450 unusable. 452 Address A link-layer address of a neighbor. 454 The I and O flags are used to facilitate the two-way use of links 455 between neighboring routers. 457 A node that does not have a link configured to a neighbor but 458 receives a Link Quality TLV from that neighbor with the node's O flag 459 set to "1" SHOULD send an MLE message with a Link Quality TLV with 460 that neighbor's I bit set to "0". This message may either be a 461 regular multicast Advertisement or a unicast to that neighbor 462 containing only a single Neighbor Data record. 464 7.8. Network Parameter 466 The Parameter TLV (TLV Type 7) specifies the value of a link-layer 467 parameter shared across the network (as opposed to a parameter 468 specific to a particular link). The Value contains three fields: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Parameter ID | Delay 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Value ... 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Parameter ID The ID of the parameter to be changed. 480 Delay The delay before setting the parameter, in 481 milliseconds. This is a four-byte unsigned 482 integer. Having a delay gives time for the new 483 value to propagate throughout the network. It 484 may also be used for limiting the time a 485 particular parameter setting is in use, by 486 including two different values for a single 487 parameter, with two different delays. 489 Value A byte string containing the new value of the 490 parameter. The format of this value is 491 determined by the particular parameter 493 Update messages MUST contain only Network Parameter TLVs. Update 494 messages with new parameter settings are normally multicast to the 495 entire MLE domain. They may also be unicast to nodes that have just 496 joined the network or otherwise do not have up-to-data parameter 497 information. 499 The defined Network Parameters are: 501 0 Channel 503 1 PAN ID 505 2 Permit Joining 507 3 Beacon Payload 509 7.9. MLE Frame Counter 511 The MLE Frame Counter TLV (TLV Type 8) has a Value containing the 512 sender's current outgoing MLE Frame Counter, encoded as an 32-bit 513 unsigned integer. 515 8. Message transmission 517 MLE messages SHOULD be sent using the assigned UDP port number 518 (19788) as both the source and destination port. Link configuration 519 and advertisement messages MUST be sent with an IP Hop Limit of 255, 520 either to a link-local unicast address or to the link-local all-nodes 521 (FF02::1) or all-routers (FF02::2) multicast addresses. Update 522 messages MAY be sent as above, or MAY be sent to a site-local all- 523 MLE-nodes multicast address (to be assigned by IANA). 525 Outgoing link configuration and advertisement messages SHOULD be 526 secured using the procedure specified in [AES] and [CCM] using the 527 auxiliary security header as described in [IEEE802154]. The one 528 exception to this is messages sent to or from a device that is 529 joining the network and does not yet have the necessary keys; such 530 unsecured messages MUST NOT contain Challenge, Response, or Link- 531 Layer Frame Counter TLVs. 533 The authenticated data consists of the following three values 534 concatenated together: 536 IP source address 537 IP destination address 538 auxiliary security header 540 The secured data consists of the messages body following the 541 auxiliary security header (the command ID and TLVs). The security 542 suite identifier is not included in either the authenticated data or 543 the secured data. Key choice is outside the scope of this document. 545 In order to allow update messages to be forwarded multiple hops, 546 outgoing update messages, MUST be secured at the link layer, if link 547 layer security is in use, and MUST NOT be secured by MLE. 549 A message sent in response to a multicast request, such as a 550 multicast Link Request, MUST be delayed by a random time between 0 551 and MAX_RESPONSE_DELAY_TIME seconds, with a resolution of at least 552 1ms. 554 MAX_RESPONSE_DELAY_TIME 1 second 555 If no response is received to a unicast request, the request MAY be 556 retransmitted using a simple timeout mechanism. This is based on the 557 retransmission mechanism used in DHCPv6 RFC 3315 [RFC3315], 558 simplified to use a single, fixed timeout. Unicast requests are not 559 relayed, which avoids the need for a more elaborate mechanism. 561 Parameter Default Description 562 ------------------------------------------------------- 563 URT 1 sec Unicast Retransmission timeout. 564 MRT 5 sec Multicast Retransmission timeout. 565 MRC 3 Maximum retransmission count. 567 For each transmission the appropriate URT or MRT value is multiplied 568 by a random number chosen with a uniform distribution between 0.9 and 569 1.1 with a resolution of at least 1ms. The randomization factor is 570 included to minimize synchronization of messages transmitted. 572 9. Processing of incoming messages 574 Any incoming link configuration or advertisement message, or an 575 incoming update sent to a link-local address, whose IP Hop Limit is 576 not 255 may have been forwarded by a router and MUST be discarded. 578 Incoming messages whose Command Type is a reserved value MUST be 579 ignored. Any TLVs in an incoming message whose TLV Type has a 580 reserved value MUST be ignored. 582 Incoming messages that are not secured with either MLE or link-layer 583 security SHOULD be ignored. The one exception to this is messages 584 sent to or from a device that is joining the network and does not yet 585 have the necessary keys. Secured incoming messages are decrypted and 586 authenticated using the procedures specified in [AES] and [CCM], with 587 security material obtained from the auxiliary security header as 588 described in [IEEE802154]. The key source may be obtained either 589 from the link layer source address or from the auxiliary security 590 header. 592 A device MUST maintain a separate incoming MLE frame counter for each 593 neighbor with which it establishes a link. Any MLE message received 594 with a frame counter the same or lower than that of a previously 595 received and authenticated message from the same source MUST be 596 discarded. Messages for which no previous frame counter are 597 available MAY be processed, but their counter value MUST be saved for 598 comparison with later messages. 600 10. Link Configuration 602 The values that may need to be communicated to configure an 802.15.4 603 link are: 605 o Long (64-bit) and short (16-bit) addresses. 607 o Capability Information, as in the 802.15.4 Association command in 608 [IEEE802154], especially the Device Type and Receiver On When Idle 609 fields. 611 o Initialization of AES-CCM frame counters. 613 A device wishing to establish a link to a neighbor MUST send a Link 614 Request message containing the following: 616 o Source Address TLV, containing the sender's short (16-bit) MAC 617 address. The sender's long (64-bit) MAC address MUST used as the 618 MAC source address of the message. 620 o Mode TLV, containing the sender's Capability data byte. 622 o Timeout TLV, if the sender is an rxOffWhenIdle device. 624 o Challenge TLV, whose size is determined by the network 625 configuration. 627 The neighbor SHOULD respond with a Link Accept message containing the 628 same TLVs (with its own values), but with a Response TLV in place of 629 the Challenge TLV and with added Link-layer Frame Counter and MLE 630 Frame Counter TLVs. If large numbers of Link Request messages arrive 631 a device MAY reduce or completely suspend sending Link Accept 632 messages, and MAY send Link Reject messages instead. The MLE Frame 633 Counter TLV MAY be omitted if the sender uses the same counter for 634 both MLE and 802.15.4 messages. If the neighbor also requires a 635 liveness check, it MAY include its own challenge, and use the Link 636 Accept And Request message type. 638 If a node receives a secured 802.15.4 unicast from a neighbor for 639 whom it does not have link configuration data, the receiving node 640 SHOULD respond with a Link Reject message to inform the neighbor that 641 the link is not configured. If large numbers of such messages arrive 642 a device MAY reduce or completely suspend sending Link Reject 643 messages. 645 Link Configuration messages are used to establish 802.15.4 security 646 and so MUST NOT be secured at the 802.15.4 layer. 648 11. Parameter Dissemination 650 Update messages may be sent to change the channel, PAN ID, and/or 651 permit joining flags on all nodes. Determining when these values 652 should be changed is beyond the scope of this document. 654 To make a network-wide change to one of these parameters, an MLE 655 update messages SHOULD be sent to an appropriate multicast address, 656 such as the site-local all-node, all-routers or all-MLE-nodes 657 multicast address (to be assigned by IANA). Alternatively, MLE 658 update messages MAY be unicast to individual devices, either to avoid 659 the cost of a multicast or to have the parameter change apply to only 660 a subset of devices. This requires some form of multi-hop multicast 661 forwarding; these messages are sent infrequently, so forwarding with 662 simple flooding is sufficient. 664 A single update message MAY contain multiple values for the same 665 parameter with different time delays. In particular, the permit 666 joining flag can be enabled for a limited time by including both on 667 and off values in a single update message. 669 A device that does not have the current network values, either 670 because it has just joined the network or for any other reason, MAY 671 send a unicast Update Request to a neighbor. The neighbor responds 672 by sending an Update message containing the current values of the 673 parameters. 675 12. Neighbor Detection 677 Nodes MAY send out periodic advertisements containing the incoming 678 IDR values for their neighbors. The primary purpose of these 679 messages is to allow nodes to choose likely candidates for link 680 establishment. They can also be used to determine if existing links 681 continue to provide sufficient two-way reliability. 683 A node maintains two boolean values for each known neighbor: 685 Receive State True if the node will accept incoming non-MLE messages 686 from that neighbor. 688 Transmit State A local cache of the neighbor's Receive State 689 corresponding to this node. 691 Both values default to false. 693 The Receive State is set to true when the node receives a valid 694 incoming link accept from the neighbor, and set to false when the 695 link configuration information is discarded for any reason (link 696 failure or timeout, for example). 698 The Transmit State is set to true when a link accept message is sent 699 to the neighbor. When an advertisement message is received from the 700 neighbor the Transmit State is set to the Receive State as reported 701 in the advertisement. If the advertisement's C flag is 1 and the 702 receiving node's address is not included in the advertisement, the 703 recipient's Transmit State for the sender is set to false. 705 These states are advisory only; a node may send a message to a 706 neighbor regardless of its Transmit State for that neighbor. 707 Similarly, a node may unilaterally change its Receive State (and 708 discard any link configuration data) without first informing the 709 neighbor of its intention. The change in Receive State will be 710 reflected in the next advertisement sent by the node. 712 Advertisement messages are used prior to establishing 802.15.4 713 security and thus SHOULD NOT be secured at the 802.15.4 layer. 715 13. Acknowledgements 717 The author would like to acknowledge the helpful comments of Thomas 718 Clausen, Robert Cragie, Colin O'Flynn, Edward Hill, Matteo Paris, 719 Kundok Park, Joseph Reddy, and Dario Tedeschi, which greatly improved 720 the document. 722 14. IANA Considerations 724 IANA has assigned UDP port 19788 to MLE. 726 IANA is requested to establish a new top-level registry, called "MLE: 727 Mesh Link Establishment", to contain all MLE objects, codepoints, and 728 sub-registries. 730 The allocation policy for each new registry is by IETF review: new 731 values are assigned through the IETF review process . 733 14.1. Security Suites 735 IANA is requested to create a subregistry, called "Security Suites". 736 Values range from 0 to 255. 738 Value Meaning Reference 739 0 802.15.4 Security This document 740 255 No Security This document 742 Values 1-254 are currently unassigned. 744 14.2. Command Types 746 IANA is requested to create a subregistry, called "Command Types". 747 Values range from 0 to 255. 749 Value Meaning Reference 750 0 Link Request This document 751 1 Link Accept This document 752 2 Link Accept and Request This document 753 3 Link Reject This document 754 4 Advertisement This document 755 5 Update This document 756 6 Update Request This document 758 Values 7-255 are currently unassigned. 760 14.3. TLV Types 762 IANA is requested to create a subregistry, called "TLV Types". 763 Values range from 0 to 255. 765 Value Meaning Reference 766 0 Source Address This document 767 1 Mode This document 768 2 Timeout This document 769 3 Challenge This document 770 4 Response This document 771 5 Link-layer Frame Counter This document 772 6 Link Quality This document 773 7 Network Parameter This document 774 8 MLE Frame Counter This document 776 Values 9-255 are currently unassigned. 778 14.4. Network Parameters 780 IANA is requested to create a subregistry, called "Network 781 Parameters". Values range from 0 to 255. 783 Value Meaning Reference 784 0 Channel This document 785 1 PAN ID This document 786 2 Permit Joining This document 787 3 Beacon Payload This document 789 Values 4-255 are currently unassigned. 791 15. Security Considerations 793 In general MLE has the strengths and weaknesses of the link layer 794 security that it inherits. The one exception is that MLE's operation 795 requires accepting and acting on incoming Advertisements and Link 796 Requests messages for which the receiver has no prior knowledge of 797 the sender's MLE frame counter. Because of this, implementers must 798 be careful in how they use information obtained from these possibly- 799 replayed messages. For example, information from unsecured messages 800 should not be used to modify any stored information obtained from 801 secured messages. 803 The Hop Limit field of received packets other than multihop update 804 messages is verified to contain 255, the maximum legal value. 805 Because routers decrement the Hop Limit on all packets they forward, 806 received packets containing a Hop Limit of 255 must have originated 807 from a neighbor. This technique is borrowed from IPv6 ND [RFC4861]. 809 16. References 811 16.1. Normative References 813 [AES] National Institute of Standards and Technology, 814 "Specification for the Advanced Encryption Standard 815 (AES)", FIPS 197, November 2001. 817 [CCM] National Institute of Standards and Technology, 818 "Recommendation for Block Cipher Modes of Operation: The 819 CCM Mode for Authentication and Confidentiality", SP 820 800-38C, May 2004. 822 [IEEE802154] 823 Institute of Electrical and Electronics Engineers, 824 "Wireless Personal Area Networks", IEEE Standard 825 802.15.4-2006, 2006. 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, March 1997. 830 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 831 Requirements for Security", BCP 106, RFC 4086, June 2005. 833 16.2. Informative References 835 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 836 and M. Carney, "Dynamic Host Configuration Protocol for 837 IPv6 (DHCPv6)", RFC 3315, July 2003. 839 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 840 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 841 September 2007. 843 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 844 Barthel, "Routing Metrics Used for Path Calculation in 845 Low-Power and Lossy Networks", RFC 6551, March 2012. 847 [ZigBeeIP] 848 ZigBee Alliance, "ZigBee IP Specification", 2014, 849 . 851 Author's Address 853 Richard Kelsey 854 Silicon Labs 855 343 Congress St 856 Boston, Massachusetts 02210 857 USA 859 Phone: +1 617 951 1225 860 Email: richard.kelsey@silabs.com