idnits 2.17.1 draft-kelsey-intarea-mesh-link-establishment-04.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 (June 28, 2012) is 4320 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 Ember Corporation 4 Intended status: Standards Track June 28, 2012 5 Expires: December 30, 2012 7 Mesh Link Establishment 8 draft-kelsey-intarea-mesh-link-establishment-04 10 Abstract 12 This document defines the mesh link establishment (MLE) protocol for 13 establishing and configuring secure links in an ad hoc mesh radio 14 network. Effective mesh networking using radio links requires 15 identifying, configuring, and securing usable links to neighboring 16 devices. In an ad hoc mesh network a device's neighbors may come and 17 go as the network's membership and physical environment change. 18 Newly usable links need to be identified and configured 19 automatically, where configuration values can include link-layer 20 addresses, transmit and receive modes, security parameters, and so 21 forth. MLE includes the option of securing the configuration 22 messages themselves, as link-layer security is typically not 23 available prior to configuration. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 30, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Formats . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Command Format . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 8 67 6.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . . 9 72 6.7. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 9 73 6.8. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.9. Network Parameter . . . . . . . . . . . . . . . . . . . . 11 75 6.10. Network Parameter Request . . . . . . . . . . . . . . . . 12 76 7. Message transmission . . . . . . . . . . . . . . . . . . . . . 13 77 8. Processing of incoming messages . . . . . . . . . . . . . . . 15 78 9. Application to 802.15.4 . . . . . . . . . . . . . . . . . . . 16 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 11.1. Security Suites . . . . . . . . . . . . . . . . . . . . . 19 82 11.2. Command Types . . . . . . . . . . . . . . . . . . . . . . 19 83 11.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 19 84 11.4. Network Parameters . . . . . . . . . . . . . . . . . . . . 20 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 88 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 The configuration of individual links in an ad hoc mesh network can 94 fall into a gap between standards. Link layer standards typically 95 deal with individual links and networking standards assume that the 96 links are up and running. In an ad hoc mesh network a device's 97 neighbors may come and go as the network's membership and physical 98 environment change, requiring that new links be configured 99 automatically. The required configuration information can include 100 link layer addressing, transmit and receive modes, wake/sleep cycles, 101 and so on. 103 Security configuration is particularly important, as the link layer 104 may not be able to secure packets until after the link itself has 105 been configured. Existing IETF neighbor discovery protocols, such as 106 IPv6 ND [RFC4861] and NHDP [RFC6130] either require (IPv6 ND) or 107 recommend (NHDP) that their messages be sent over secured links. 108 While there are some similarities between these protocols and MLE, 109 they are actually complementary: MLE is entirely concerned with link- 110 layer configuration, including security, while IPv6 ND and NHDP use 111 already-configured links to discover IP properties of their 112 neighbors. 114 MLE can be used to configure individual links and to distribute 115 configuration values that are shared across a network. Per-link 116 configuration uses one-hop messages with link-local addresses. 117 Network-wide configuration uses multicasts and requires some form of 118 multi-hop multicast forwarding. 120 One of the most important properties of a radio link, how reliably 121 the two neighbors can communicate, often cannot be determined 122 unilaterally by either node. Many radio links are asymmetric, where 123 messages traveling one way across the link are received more or less 124 reliably than messages traveling in the opposite direction. There is 125 a chicken and egg problem here. It is a waste of effort to configure 126 a link that does not have sufficient two-way reliability to be 127 useful, but the two-way reliability cannot be determined without 128 exchanging messages over the link. MLE resolves this by allowing a 129 node to periodically multicast an estimate of the quality of its 130 links. This allows a node to determine if it has a usable radio link 131 to a neighbor without first configuring that link. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 [RFC2119]. 140 2. Terminology 142 ETX Expected Transmission Count [RFC6551]; the number 143 of transmission attempts required to send a 144 packet over a particular link. Defined to be the 145 product of the IDR values for both directions. A 146 perfect link has an ETX of 1, less than perfect 147 links have higher ETX values. 149 Frame counter A value that is incremented with each new secured 150 message and used to detect replayed messages. 152 IDR Inverse Delivery Ratio; the number of 153 transmission attempts divided by the number of 154 successful transmissions in a given direction 155 over a link. Used in computing the ETX value for 156 a link. 158 3. Overview 160 MLE provides a means of transmitting link configuration values. An 161 MLE message is one of: 163 Link configuration A one-hop unicast sent as part of establishing a 164 link with one particular neighbor. Link 165 configuration messages are either a request that 166 the link be configured, or an acceptance or 167 rejection of such a request. 169 Advertisement A one-hop multicast that advertise a node's link 170 quality estimates to its neighbors. 172 Update Messages that updates a shared configuration 173 value. These may be multicast or unicast. 175 If additional negotiation is required, establishment of a link may 176 require an exchange of two or more unicast messages. The only 177 multiple-message exchange in MLE protocol as described in this 178 document performs liveness determination (frame counter 179 initialization). 181 MLE messages are sent using UDP. 183 A node maintains two boolean values for each neighbor: 185 Receive State True if the node will accept incoming non-MLE messages 186 from that neighbor. 188 Transmit State A local cache of the neighbor's Receive State 189 corresponding to this node. 191 Both values default to false. The Receive State is set to true when 192 the node accepts an incoming link request from the neighbor, and set 193 to false when the link configuration information is discarded for any 194 reason (link failure or timeout, for example). The Transmit State is 195 set to true when a link accept message is received from the neighbor. 196 When an advertisement message is received from the neighbor the 197 Transmit State is set to the neighbor's Receive State as reported, 198 either implicitly or explicitly, in that message. 200 These states are advisory only; a node may send a message to a 201 neighbor regardless of the Transmit State of that neighbor. 202 Similarly, a node may unilaterally change its Receive State (and 203 discard any link configuration data) without first informing the 204 neighbor of its intention. The change in Receive State will be 205 reflected in the next advertisement sent by the node. 207 4. Security Formats 209 One of the main functions of MLE is to initialize link-layer 210 security. This means that MLE itself cannot rely on link-layer 211 security. To avoid the cost and complexity of adding a second 212 security suite, MLE reuses that of the link layer. This document 213 describes two security suites, one with no security and the other 214 using Advanced Encryption Standard 128 [AES] in Counter with CBC-MAC 215 Mode [CCM] as described in [IEEE802154]. Later extensions may 216 include other security suites for use with other types of links. 218 An MLE message begins with single byte indicating the security suite 219 used in that message. If that initial byte is "255" no security is 220 used and the messages has no additional security data. An initial 221 byte of "0" indicates that the message is secured as described in 222 [IEEE802154] (all codes are to be confirmed by IANA; see Section 11). 223 MLE messages thus have one of the two following formats: 225 +-----+------------+---------+-----+ 226 | 0 | Aux Header | Command | MIC | 227 +-----+------------+---------+-----+ 228 +-----+---------+ 229 | 255 | Command | 230 +-----+---------+ 232 Aux Header Auxiliary Security Header as described in [IEEE802154]. 234 Command MLE command; see Section 5. 236 MIC Message Integrity Code as described in [IEEE802154]. 238 If MLE security is in use each device MUST maintain an outgoing MLE 239 frame counter for use in securing outgoing packets in compliance with 240 [CCM]. 242 MLE security MUST NOT use any key that is being used by the link (or 243 any other) layer. Other than the above requirements, the 244 distribution or derivation of the key(s) used for MLE security is 245 outside the scope of this document. 247 5. Command Format 249 MLE messages consist of a command type and a series of type-length- 250 value parameters. 252 +--------------+-----+-----+-----+ 253 | Command Type | TLV | ... | TLV | 254 +--------------+-----+-----+-----+ 256 Command Type An eight-bit unsigned integer identifying the type of 257 message. This document defines the following commands 258 (all codes are to be confirmed by IANA, see Section 11): 260 0 Link Request. A request to establish a link to a 261 neighbor. 263 1 Link Accept. Accept a requested link. 265 2 Link Accept and Request. Accept a requested link 266 and request a link with the sender of the original 267 request. 269 3 Link Reject. Reject a link request. 271 4 Advertisement. Inform neighbors of a device's link 272 state. 274 5 Update. Informs of changes to link parameters 275 shared by all nodes in a network. 277 The first four (Link Request, Link Accept, Link Accept 278 and Request, and Link Reject) are collectively referred 279 to as link configuration messages. 281 TLVs Zero or more TLV frames. These are described in 282 Section 6. 284 6. Values 286 Values are encoded using a type-length-value format, where the type 287 and length are one byte each and the length field contains the length 288 of the value in bytes. There are no alignment requirements and no 289 padding. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Value ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Type An eight-bit unsigned integer giving the type of 298 the value. 300 Length An eight-bit unsigned integer giving the length 301 of the Value field in bytes. 303 Value Length bytes of value, formatted as defined for 304 the Type. 306 6.1. Source Address 308 The Source Address TLV (TLV Type 0) has a Value containing a byte 309 string representing a link-layer address assigned to the source of 310 the message. A given radio interface may have multiple link-layer 311 addresses. This TLV is used to communicate any source address(es) 312 that is not included in the message by the link layer itself. 314 6.2. Mode 316 The Mode TLV (TLV Type 1) has a Value containing a byte string 317 representing the mode in which this link is used by the source of the 318 message. The format and interpretation of the mode value are 319 specific to the link layer in use. Mode information can include such 320 things as the sender's listening schedule, whether it will poll for 321 messages, and so forth. 323 6.3. Timeout 325 The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned 326 integer, most significant byte first. The value is the expected 327 maximum interval between transmissions by the sender, in seconds. 328 This allows the receiver to more accurately timeout a link to a 329 neighbor that polls for its incoming messages. 331 6.4. Challenge 333 The Challenge TLV (TLV Type 3) has a Value containing a randomly- 334 chosen byte string that is used to determine the freshness of any 335 reply to this message. The recommendations in [RFC4086] apply with 336 regard to generation of the challenge value. A new value MUST be 337 chose for each Challenge TLV transmitted. An important part of 338 replay protection is determining if a newly-heard neighbor is 339 actually present or is a set of recorded messages. This is done by 340 sending a random challenge value to the neighbor and then receiving 341 that same value in a Response TLV sent by the neighbor. 343 6.5. Response 345 The Response TLV (TLV Type 4) has a Value containing a byte string 346 copied from a Challenge TLV. 348 6.6. Link-layer Frame Counter 350 The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing 351 the sender's current outgoing link-layer Frame Counter, encoded as an 352 N-bit unsigned integer, most significant byte first. The size of the 353 Frame Counter is determined the link layer in use. 355 6.7. MLE Frame Counter 357 The MLE Frame Counter TLV (TLV Type 9) has a Value containing the 358 sender's current outgoing MLE Frame Counter, encoded as an N-bit 359 unsigned integer, most significant byte first. The size of the Frame 360 Counter is determined the security suite in use. 362 6.8. Link Quality 364 The Link Quality TLV (TLV Type 6) reports the sender's measured link 365 quality for messages received from its neighbors. The format of the 366 Link Quality value is as follows: 368 0 1 2 369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |C| Res | Size | Neighbor Data ... 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 C Complete: "1" if the message includes all 375 neighboring routers for which the source has link 376 quality data. Multicast Link Quality TLVs 377 normally contain complete information; a unicast 378 to a particular neighbor would normally contain 379 only that neighbor's link quality and would have 380 the C flag of "0". 382 Res Reserved. 384 Size The size in bytes of the included neighbor link- 385 layer addresses, minus 1. This supports 386 addresses of lengths 1 to 16. 388 Neighbor Data A sequence of neighbor records, each containing 389 receive and transmit state flags, the estimated 390 incoming link reliability (IDR), and the 391 neighbor's link-layer address. 393 An MLE message SHOULD NOT contain more than one Link Quality TLV. 395 The neighbor data in a Link Quality TLV is formatted as follows: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |I|O|P|reserved | Incoming IDR | Neighbor Address ... 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 I(ncoming) "1" if the sender's Receive State for this 404 neighbor is true, "0" if not. 406 O(utgoing) "1" if the sender's Transmit State for this 407 neighbor is true, "0" if not. 409 P(riority) "1" if the sender's expects to use this link for 410 sending messages, "0" if not. Given limited 411 resources, the P flag MAY be used in deciding 412 which links should be maintained. 414 Incoming IDR The estimated inverse delivery ratio of messages 415 sent by the neighbor to the source of this 416 message. This is an eight-bit unsigned integer. 417 To allow for fractional IDR, the value encoded is 418 multiplied by 32. A perfect link, with an actual 419 IDR of 1, would have an Incoming IDR of 0x20. A 420 value of 0xFF indicates that the link is 421 unusable. 423 Address A link-layer address of a neighbor. 425 The I and O flags are used to facilitate the two-way use of links 426 between neighboring routers. 428 A node that does not have a link configured to a neighbor but 429 receives a Link Quality TLV from that neighbor with the node's O flag 430 set to "1" SHOULD send an MLE message with a Link Quality TLV with 431 that neighbor's I bit set to "0". This message may either be a 432 regular multicast Advertisement or a unicast to that neighbor 433 containing only a single Neighbor Data record. 435 6.9. Network Parameter 437 The Parameter TLV (TLV Type 7) specifies the value of a link-layer 438 parameter shared across the network (as opposed to a parameter 439 specific to a particular link). The Value contains three fields: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Parameter ID | Delay 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Value ... 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Parameter ID The ID of the parameter to be changed. 451 Delay The delay before setting the parameter, in 452 milliseconds. This is a four-byte unsigned 453 integer, most significant byte first. Having a 454 delay gives time for the new value to propagate 455 throughout the network. It may also be used for 456 limiting the time a particular parameter setting 457 is in use, by including two different values for 458 a single parameter, with two different delays. 460 Value A byte string containing the new value of the 461 parameter. The format of this value is 462 determined by the particular parameter 464 Update messages SHOULD contain only Network Parameter TLVs. Update 465 messages with new parameter settings SHOULD be multicast to the 466 entire MLE domain. They MAY also be unicast to nodes that have just 467 joined the network or otherwise do not have up-to-data parameter 468 information. 470 The defined Network Parameters are: 472 0 Channel 474 1 PAN ID 476 2 Permit Joining 478 3 Beacon Payload 480 (values to be confirmed by IANA) 482 6.10. Network Parameter Request 484 The Parameter Request TLV (TLV Type 9) requests that the recipient 485 send the current network parameter values to the sender of the 486 request. This is sent by devices that have just joined a network or 487 are otherwise unaware of the current network parameter values. It 488 has no Value. 490 7. Message transmission 492 Messages SHOULD be sent using UDP port X (value to be assigned by 493 IANA). Link configuration and advertisement messages MUST be sent 494 with an IP Hop Limit of 255, either to a link-local unicast address 495 or to the link-local all-nodes (FF02::1) or all-routers (FF02::2) 496 multicast addresses. Update messages MAY be sent as above, or MAY be 497 sent to a site-local all-MLE-nodes multicast address (to be assigned 498 by IANA). 500 Outgoing messages SHOULD be secured using the procedure specified in 501 [AES] and [CCM] using the auxiliary security header as described in 502 [IEEE802154]. Key choice is outside the scope of this document. The 503 authenticated data consists of the following three values 504 concatenated together: 506 IP source address 507 IP destination address 508 auxiliary security header 510 The secured data consists of the messages body following the 511 auxiliary security header (the command ID and TLVs). The security 512 suite identifier is not included in either the authenticated data or 513 the secured data. 515 A message sent in response to a multicast request, such as a 516 multicast Link Request, MUST be delayed by a random time between 0 517 and MAX_RESPONSE_DELAY_TIME seconds. 519 MAX_RESPONSE_DELAY_TIME 1 second 521 If no response is received to a request, the request MAY be 522 retransmitted. Because MLE messages do not require complex 523 processing and are not relayed, a simple timeout scheme is used for 524 retransmitting. This is based on the retransmission mechanism used 525 in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed 526 timeout. 528 Parameter Default Description 529 ------------------------------------------------------- 530 URT 1 sec Unicast Retransmission timeout. 531 MRT 5 sec Multicast Retransmission timeout. 532 MRC 3 Maximum retransmission count. 534 For each transmission the appropriate URT or MRT value is multiplied 535 by a random number chosen with a uniform distribution between 0.9 and 536 1.1. The randomization factor is included to minimize 537 synchronization of messages transmitted. 539 8. Processing of incoming messages 541 Any incoming link configuration or advertisement message, or an 542 incoming update sent to a link-local address, whose IP Hop Limit is 543 not 255 may have been forwarded by a router and MUST be discarded. 545 Incoming update messages that contain TLVs other than Network 546 Parameter TLVs SHOULD be ignored. 548 Unsecured incoming messages SHOULD be ignored. Secured incoming 549 messages are decrypted and authenticated using the procedures 550 specified in [AES] and [CCM], with security material obtained from 551 the auxiliary security header as described in [IEEE802154]. The key 552 source may be obtained either from the link layer source address or 553 from the auxiliary security header. 555 A device SHOULD maintain a separate incoming MLE frame counter for 556 each neighbor. Any MLE message received with a frame counter the 557 same or lower than that of a previously received and authenticated 558 message from the same source MUST be discarded. Messages for which 559 no previous frame counter are available are not discarded and the 560 counter value SHOULD be saved for comparison with later messages. 562 9. Application to 802.15.4 564 This section describes how MLE could be used in an 802.15.4-based 565 LoWPAN. This section is not normative. The values that may need to 566 be communicated to configure an 802.15.4 include: 568 o Long (64-bit) and short (16-bit) addresses. 570 o Capability data byte, especially the Device Type and Receiver On 571 When Idle fields. 573 o Initialization of AES-CCM frame counters. 575 A device wishing to establish a link to a neighbor would send a Link 576 Request message containing the following: 578 o Source Address TLV, containing the sender's short (16-bit) MAC 579 address. It is assumed that the sender's long (64-bit) MAC 580 address is used as the MAC source address of the message. 582 o Mode TLV, containing the sender's Capability data byte. 584 o Timeout TLV, if the sender is an rxOffWhenIdle device. 586 o Challenge TLV, whose size is determined by the network 587 configuration. 589 If the neighbor has sufficient resources to maintain an additional 590 link, it would respond with a Link Accept message containing the same 591 TLVs (with its own values), but with a Response TLV in place of the 592 Challenge TLV and with an added Link-layer Frame Counter TLV. If the 593 neighbor also required a liveness check, it would include its own 594 challenge, and use the Link Accept And Request message type. 596 If a node receives a secured 802.15.4 unicast from a neighbor for 597 whom it does not have link configuration data, the receiving node 598 should respond with a Link Reject message to inform the neighbor that 599 the link is not configured. 601 Nodes could also send out periodic advertisements containing the 602 incoming IDR values for their neighbors. These would be used to 603 choose likely candidates for link establishment and to determine if 604 existing links continued to provide sufficient two-way reliability. 606 Because link configuration and advertisement messages are used to 607 establish 802.15.4 security they should not be secured at the 608 802.15.4 layer. 610 Update messages may be sent to change the channel, PAN ID, and/or 611 permit joining flags on all nodes. 613 10. Acknowledgements 615 TODO. 617 11. IANA Considerations 619 TODO: UDP port 621 IANA is requested to establish a new top-level registry, called "MLE: 622 Mesh Link Establishment", to contain all MLE objects, codepoints, and 623 sub-registries. 625 The allocation policy for each new registry is by IETF review: new 626 values are assigned through the IETF review process . 628 11.1. Security Suites 630 IANA is requested to create a subregistry, called "Security Suites". 631 Values range from 0 to 255. 633 Value Meaning Reference 634 0 802.15.4 Security This document 635 255 No Security This document 637 Values 1-254 are currently unassigned. 639 11.2. Command Types 641 IANA is requested to create a subregistry, called "Command Types". 642 Values range from 0 to 255. 644 Value Meaning Reference 645 0 Link Request This document 646 1 Link Accept This document 647 2 Link Accept and Request This document 648 3 Link Reject This document 649 4 Advertisement This document 650 5 Update This document 652 Values 6-255 are currently unassigned. 654 11.3. TLV Types 656 IANA is requested to create a subregistry, called "TLV Types". 657 Values range from 0 to 255. 659 Value Meaning Reference 660 0 Source Address This document 661 1 Mode This document 662 2 Timeout This document 663 3 Challenge This document 664 4 Response This document 665 5 Link-layer Frame Counter This document 666 6 Link Quality This document 667 7 Network Parameter This document 668 8 Network Parameter Request This document 669 9 MLE Frame Counter This document 671 Values 8-255 are currently unassigned. 673 11.4. Network Parameters 675 IANA is requested to create a subregistry, called "Network 676 Parameters". Values range from 0 to 255. 678 Value Meaning Reference 679 0 Channel This document 680 1 PAN ID This document 681 2 Permit Joining This document 682 3 Beacon Payload This document 684 Values 4-255 are currently unassigned. 686 12. Security Considerations 688 In general MLE has the strengths and weaknesses of the link layer 689 security that it inherits. The one exception is that MLE's operation 690 requires accepting and acting on incoming Advertisements and Link 691 Requests messages for which the receiver has no prior knowledge of 692 the sender's MLE frame counter. Because of this, implementers must 693 be careful in how they use information obtained from these possibly- 694 replayed messages. For example, information from unsecured messages 695 should not be used to modify any stored information obtained from 696 secured messages. 698 The Hop Limit field of all received packets is verified to contain 699 255, the maximum legal value. Because routers decrement the Hop 700 Limit on all packets they forward, received packets containing a Hop 701 Limit of 255 must have originated from a neighbor. This technique is 702 borrowed from IPv6 ND [RFC4861]. 704 13. References 706 13.1. Normative References 708 [AES] National Institute of Standards and Technology, 709 "Specification for the Advanced Encryption Standard 710 (AES)", FIPS 197, November 2001. 712 [CCM] National Institute of Standards and Technology, 713 "Recommendation for Block Cipher Modes of Operation: The 714 CCM Mode for Authentication and Confidentiality", SP 800- 715 38C, May 2004. 717 [IEEE802154] 718 Institute of Electrical and Electronics Engineers, 719 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 720 2006, 2006. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 726 Requirements for Security", BCP 106, RFC 4086, June 2005. 728 13.2. Informative References 730 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 731 and M. Carney, "Dynamic Host Configuration Protocol for 732 IPv6 (DHCPv6)", RFC 3315, July 2003. 734 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 735 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 736 September 2007. 738 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 739 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 740 RFC 6130, April 2011. 742 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 743 Barthel, "Routing Metrics Used for Path Calculation in 744 Low-Power and Lossy Networks", RFC 6551, March 2012. 746 Author's Address 748 Richard Kelsey 749 Ember Corporation 750 25 Thomson Place 751 Boston, Massachusetts 02210 752 USA 754 Phone: +1 617 951 1225 755 Email: richard.kelsey@ember.com