idnits 2.17.1 draft-kelsey-intarea-mesh-link-establishment-02.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 (March 7, 2012) is 4426 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 March 7, 2012 5 Expires: September 8, 2012 7 Mesh Link Establishment 8 draft-kelsey-intarea-mesh-link-establishment-02 10 Abstract 12 This document defines the mesh link establishment (MLE) protocol for 13 establishing and configuring links in an ad hoc mesh radio network. 14 Effective mesh networking using radio links requires identifying, 15 configuring, and securing usable links to neighboring devices. In an 16 ad hoc mesh network a device's neighbors may come and go as the 17 network's membership and physical environment change. Newly usable 18 links need to be identified and configured automatically, where 19 configuration values can include link-layer addresses, transmit and 20 receive modes, security parameters, and so forth. MLE includes the 21 option of securing the configuration messages themselves, as link- 22 layer security may not be available prior to configuration. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 8, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.6. Replay Counter . . . . . . . . . . . . . . . . . . . . . . 10 70 5.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.8. Param . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Message transmission . . . . . . . . . . . . . . . . . . . . . 13 73 7. Processing of incoming messages . . . . . . . . . . . . . . . 15 74 8. Application to 802.15.4 . . . . . . . . . . . . . . . . . . . 16 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Introduction 85 The configuration of individual links in an ad hoc mesh network can 86 fall into a gap between standards. Link layer standards typically 87 deal with individual links and networking standards assume that the 88 links are up and running. In an ad hoc mesh network a device's 89 neighbors may come and go as the network's membership and physical 90 environment change, requiring that new links be configured 91 automatically. The required configuration information can include 92 link layer addressing, transmit and receive modes, wake/sleep cycles, 93 and so on. Security configuration is particularly important, as the 94 link layer may not be able to secure packets until after the link 95 itself has been configured. 97 MLE can be used to configure individual links and to distribute 98 configuration values that are shared across a network. MLE messages 99 are sent using UDP. Per-link configuration uses one-hop messages 100 with link-local addresses. Network-wide configuration uses 101 multicasts and requires some form of multi-hop multicast forwarding. 103 Link parameters can be unicast between two neighboring nodes, as when 104 configuring a particular link, or multicast to all neighbors, in 105 order to advertise to new neighbors or to efficiently transmit 106 updated values. 108 One of the most important properties of a radio link, how well the 109 two neighbors hear each other, often cannot be determined 110 unilaterally by either node. Many radio links are asymmetric, where 111 messages traveling one way across the link are received more or less 112 reliably than messages traveling in the opposite direction. There is 113 a chicken and egg problem here. It is a waste of effort to configure 114 a link that does not have sufficient two-way reliability to be 115 useful, but the two-way reliability cannot be determined without 116 exchanging messages over the link. MLE resolves this by allowing a 117 node to periodically multicast an estimate of the quality of its 118 links. This allows a node to determine if it has a usable radio link 119 to a neighbor without first configuring that link. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Terminology 129 ETX Expected Transmission Count; the number of 130 transmission attempts required to send a packet 131 over a particular link. Defined to be the 132 product of the IDR values for both directions. A 133 perfect link has an ETX of 1, less than perfect 134 links have higher ETX values. 136 Frame counter A value that is incremented with each new secured 137 message. Used with [CCM] to ensure that no two 138 messages are secured using the same key and nonce 139 pair. In 802.15.4 the same counter is used as 140 both a frame counter and a replay counter. 142 IDR Inverse Delivery Ration; the number of 143 transmission attempts divided by the number of 144 successful transmissions in a given direction 145 over a link. 147 Replay counter A message value that is incremented with each new 148 transmission. Incoming messages whose counter 149 value is the same or lower as that in an earlier 150 message are discarded. 152 3. Overview 154 MLE is a means of transmitting link configuration values. An MLE 155 message is one of: 157 Link configuration A one-hop unicast sent as part of establishing a 158 link with one particular neighbor. 160 Advertisement A one-hop multicast that advertise a node's link 161 quality estimates to its neighbors. 163 Update A multicast that updates a shared configuration 164 value. 166 If negotiation is required, establishment of a link may require an 167 exchange of two or more unicast messages. The only multiple-message 168 exchange in the MLE protocol performs liveness determination (replay 169 counter initialization). 171 4. Message Formats 173 MLE messages consist of a command and a series of type-length-value 174 parameters. MLE messages can be secured using Advanced Encryption 175 Standard 128 [AES] in Counter with CBC-MAC Mode [CCM] for data 176 authentication and encryption. 178 The security data is formatted as an auxiliary security header as 179 specified in [IEEE802154]. There are two exceptions to this: a 180 security header with security level of 0 does not contain a frame 181 counter, and when frame counters are included they are in big-endian 182 form. This first exception avoids the need to include a frame 183 counter when security is being provided by the link layer. The 184 second is to conform with normal IETF practice. Otherwise, the 185 presence and length of the frame counter, key identifier, and MIC 186 follow [IEEE802154]. 188 If MLE security is in use each device MUST maintain an outgoing 189 frame/replay counter for use in securing outgoing packets in 190 compliance with [CCM]. MLE does not include a method for configuring 191 its own frame counters and so does not provide complete protection 192 against replayed MLE packets. 194 MLE security MUST NOT use any key that is being used by the link (or 195 any other) layer MLE security MAY use a key derived using a 196 cryptographic hash from a key being used at the link layer. Other 197 than the above requirements, the distribution or derivation of the 198 key(s) used for MLE security is outside the scope of this document. 200 := 201 202 203 * 204 ? 206 := 207 ? 208 ? 210 The version field is one byte in length and has the value 0. 212 The defined command IDs are: 214 0 Link Request. A request to establish a link to a neighbor. 216 1 Link Accept. Accept a requested link. 218 2 Link Accept and Request. Accept a requested link and request 219 initialization in the other direction. 221 3 Link Reject. Reject a link request. 223 4 Advertisement. Inform neighbors of a device's link state. 225 5 Update. Informs of changes to link parameters shared by all 226 nodes in a network. 228 (values to be confirmed by IANA) The first four (Link Request, Link 229 Accept, Link Accept and Request, and Link Reject) are collectively 230 referred to as link configuration messages. 232 5. Values 234 Values are encoded using a type-length-value format, where the type 235 and length are one byte each and the length field contains the length 236 of the value in bytes. There are no alignment requirements and no 237 padding. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | Value ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 5.1. Source Address 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0 | Length | Source Address ... 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Length Length of the Address field in octets. 255 Source Address A link-layer address assigned to the source of 256 the message. 258 A given radio interface may have multiple link-layer addresses. This 259 TLV is used to communicate any source address(es) that is not 260 included in the message by the link layer itself. 262 5.2. Mode 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type = 1 | Length | Mode ... 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Length Length of the Mode field in octets. 272 Mode Mode configuration of this link. The possible 273 values are specific to the link layer in use. 275 Mode information can include such things as the senders listening 276 schedule, whether it will poll for messages, and so forth. 278 5.3. Timeout 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type = 2 | Length | Timeout 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Length 4 290 Timeout The expected maximum interval between 291 transmissions by the sender in seconds. 293 This allows the receiver to more accurately timeout a link to a 294 neighbor that polls for its incoming messages. 296 5.4. Challenge 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type = 3 | Length | Challenge ... 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Length Length of the Challenge field in octets. 306 Challenge A random value used to determine the freshness of 307 any reply to this message. 309 An important part of replay protection is determining if a newly- 310 heard neighbor is actually present or is a set of recorded messages. 311 This is done by sending a random challenge value to the neighbor and 312 then receiving that same value in a Response TLV sent by the 313 neighbor. 315 5.5. Response 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type = 4 | Length | Response ... 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Length Length of the Response field in octets. 325 Response The challenge value echoed back to the original 326 sender (in network order). 328 5.6. Replay Counter 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type = 5 | Length | Replay Counter ... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Length Length of the Replay Counter field in octets. 338 Response The sender's current outgoing link-layer Replay 339 Counter. 341 5.7. Link Quality 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type = 6 | Length |C| Res | Size | Neighbor Data ... 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Length Length of following values in octets (1 + (size + 350 3) * number-of-neighbors). 352 C Complete: 1 if the message includes all 353 neighboring routers for which the source has link 354 quality data. Multicast Link Quality TLVs 355 normally contain complete information; a unicast 356 to a particular neighbor would normally contain 357 only that neighbor's link quality and would not 358 have the C flag set. 360 Res Reserved. 362 Size The size in octets of the included neighbor 363 addresses, minus 1. This supports addresses of 364 lengths 1 to 16. 366 Neighbor Data A sequence of neighbor records, each containing 367 an "established" flag, the estimated incoming 368 link reliability (IDR), and the neighbor's link- 369 layer address. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |I|O| reserved | Incoming IDR | Neighbor Address ... 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 I(ncoming) Set if the sender has configured its link with 378 this neighbor and will accept incoming messages 379 from them. 381 O(utgoing) Set if the sender believes that the neighbor has 382 configured its link with the sender and will 383 accept incoming messages from the sender. This 384 flag is set if the sender has sent a Link Accept 385 message to the neighbor and cleared if the sender 386 has subsequently received a Link Quality TLV from 387 the neighbor with the sender's I flag cleared. 389 Incoming IDR The estimated inverse delivery ratio of messages 390 sent by the neighbor to the source of this 391 message. To allow for fractional IDR, the value 392 encoded is multiplied by 32. A perfect link, 393 with an actual IDR of 1, would have an Incoming 394 IDR of 0x20. A value of 0xFF indicates that the 395 link is unusable. 397 Address A link-layer address of a neighbor. 399 The I and O flags are used to facilitate the two-way use of links 400 between neighboring routers. They are advisory only; a node may send 401 a message to a neighbor regardless of the state of the most recently 402 seen corresponding I bit from that neighbor. Similarly, a node may 403 unilaterally discard a configured link without informing the neighbor 404 of its intention. 406 A node that does not have a link configured to a neighbor but 407 receives a Link Quality TLV from that neighbor with the node's O flag 408 set SHOULD send an MLE message with a Link Quality TLV with that 409 neighbor's I bit cleared. This message may either be a regular 410 multicast Advertisement or a unicast to that neighbor containing only 411 a single Neighbor Data record. 413 5.8. Param 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type = 7 | Length | Parameter ID | Delay 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Value ... 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Length Length of the Value field in octets plus 5. 425 Parameter ID The ID of the parameter to be changed. 427 Delay The delay before setting the parameter, in 428 milliseconds. This gives time for the Update 429 message carrying the Param TLV to propagate 430 throughout the network. 432 Value The new value of the parameter. 434 Update messages SHOULD contain only Param TLVs. 436 The defined Parameter IDs are: 438 0 Channel 440 1 PAN ID 442 2 Permit Joining 444 (values to be confirmed by IANA) 446 6. Message transmission 448 Messages SHOULD be sent using UDP port XXXX (value to be assigned by 449 IANA). Link configuration and advertisement messages MUST be sent 450 with an IP Hop Limit of 255, either to a link-local unicast address 451 or to the link-local all-nodes (FF02::2) or all-routers (FF02::1) 452 multicast addresses. Update messages MAY be sent as are link 453 configuration or advertisement messages, or MAY be sent to a site- 454 local all-MLE-nodes multicast address (to be assigned by IANA). 456 Outgoing messages SHOULD be secured using the procedure specified in 457 [AES] and [CCM] using the auxiliary security header as described in 458 [IEEE802154]. Key choice is outside the scope of this document. The 459 authenticated data consists of the following three values 460 concatenated together: 462 IP source address 463 IP destination address 464 auxiliary security header 466 The secured data consists of the messages body following the 467 auxiliary security header (the command ID and TLVs). 469 A message sent in response to a multicast request, such as a 470 multicast Link Request, MUST be delayed by a random time between 0 471 and MAX_RESPONSE_DELAY_TIME seconds. 473 MAX_RESPONSE_DELAY_TIME 1 second 475 If no response is received to a request, the request MAY be 476 retransmitted. Because MLE messages do not require complex 477 processing and are not relayed, a simple timeout scheme is used for 478 retransmitting. This is based on the retransmission mechanism used 479 in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed 480 timeout. 482 Parameter Default Description 483 ------------------------------------------------------- 484 URT 1 sec Unicast Retransmission timeout. 485 MRT 5 sec Multicast Retransmission timeout. 486 MRC 3 Maximum retransmission count. 488 For each transmission the appropriate URT or MRT value is multiplied 489 by a random number chosen with a uniform distribution between 0.9 and 490 1.1. The randomization factor is included to minimize 491 synchronization of messages transmitted. 493 7. Processing of incoming messages 495 Any incoming link configuration or advertisement message, or an 496 incoming update sent to a link-local address, whose IP Hop Limit is 497 not 255 may have been forwarded by a router and MUST be discarded. 499 Incoming update messages that contain TLVs other than Param TLVs 500 SHOULD be ignored. 502 Unsecured incoming messages SHOULD be ignored. Secured incoming 503 messages are decrypted and authenticated using the procedures 504 specified in [AES] and [CCM], with security material obtained from 505 the auxiliary security header as described in [IEEE802154]. The key 506 source may be obtained either from the link layer source address or 507 from the auxiliary security header. 509 A device SHOULD maintain a separate incoming frame/replay counter for 510 each neighbor. Any message received with a frame/replay counter the 511 same or lower than that of a previously received and authenticated 512 message from the same source MUST be discarded. Messages for which 513 no previous frame/replay counter are available are not discarded and 514 the counter value SHOULD be saved for comparison with later messages. 516 8. Application to 802.15.4 518 This section describes how MLE could be used in an 802.15.4-based 519 LoWPAN. This section is not normative. The values that may need to 520 be communicated to configure an 802.15.4 include: 522 o Long (64-bit) and short (16-bit) addresses. 524 o Capability data byte, especially the Device Type and Receiver On 525 When Idle fields. 527 o Initialization of AES-CCM frame counters (which are also used as 528 replay counters). 530 A device wishing to establish a link to a neighbor would send a Link 531 Request message containing the following: 533 o Source Address TLV, containing the sender's short (16-bit) MAC 534 address. It is assumed that the sender's long (64-bit) MAC 535 address is used as the MAC source address of the message. 537 o Mode TLV, containing the sender's Capability data byte. 539 o Timeout TLV, if the sender is an rxOffWhenIdle device. 541 o Challenge TLV, whose size is determined by the network 542 configuration. 544 If the neighbor has sufficient resources to maintain an additional 545 link, it would respond with a Link Accept message containing the same 546 TLVs (with its own values), but with a Response TLV in place of the 547 Challenge TLV and with an added Replay Counter TLV. If the neighbor 548 also required a liveness check, it would include its own challenge, 549 and use the Link Accept And Request message type. 551 If a node receives a secured 802.15.4 unicast from a neighbor for 552 whom it does not have link configuration data, the receiving node 553 should respond with a Link Reject message to inform the neighbor that 554 the link is not configured. 556 Nodes could also send out periodic advertisements containing the 557 incoming and outgoing ETX values for their neighbors. These would be 558 used to choose likely candidates for link establishment and to 559 determine if existing links continued to provide sufficient two-way 560 reliability. 562 Because link configuration and advertisement messages are used to 563 establish 802.15.4 security they should not be secured at the 564 802.15.4 layer. 566 Update messages may be sent to change the channel, PAN ID, and/or 567 permit joining flags on all nodes. The permit joining flag normally 568 defaults to false; to avoid permanently enabling joining, the value 569 of permit joining parameter should be the number of seconds for which 570 the permit joining flag should be turned on, and not just true or 571 false. 573 9. Acknowledgements 575 TODO. 577 10. IANA Considerations 579 TODO: UDP port and registries for the command, TLV, and Parameter ID 580 identifiers. 582 11. Security Considerations 584 IN PROGRESS 586 Some MLE messages are necessarily sent unsecured. Implementations 587 must take care to use information data from unsecured messages 588 appropriately. In particular, information from unsecured messages 589 should not be used to modify any stored information obtained from 590 secured messages. 592 12. References 594 12.1. Normative References 596 [AES] National Institute of Standards and Technology, 597 "Specification for the Advanced Encryption Standard 598 (AES)", FIPS 197, November 2001. 600 [CCM] National Institute of Standards and Technology, 601 "Recommendation for Block Cipher Modes of Operation: The 602 CCM Mode for Authentication and Confidentiality", SP 800- 603 38C, May 2004. 605 [IEEE802154] 606 Institute of Electrical and Electronics Engineers, 607 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 608 2006, 2006. 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 12.2. Informative References 615 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 616 and M. Carney, "Dynamic Host Configuration Protocol for 617 IPv6 (DHCPv6)", RFC 3315, July 2003. 619 Author's Address 621 Richard Kelsey 622 Ember Corporation 623 25 Thomson Place 624 Boston, Massachusetts 02210 625 USA 627 Phone: +1 617 951 1225 628 Email: richard.kelsey@ember.com