idnits 2.17.1 draft-thubert-roll-unaware-leaves-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 (March 18, 2018) is 2230 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) == Unused Reference: 'RFC8200' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6lo-ap-nd' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'IEEEstd802154' is defined on line 568, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lo-rfc6775-update-15 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-06 == Outdated reference: A later version (-18) exists of draft-ietf-roll-efficient-npdao-01 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-22 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 6550, 6775 (if approved) March 18, 2018 5 Intended status: Standards Track 6 Expires: September 19, 2018 8 Routing for RPL Leaves 9 draft-thubert-roll-unaware-leaves-04 11 Abstract 13 This specification updates RFC 6550 and RFC 6775 unicast routing 14 service in a RPL domain to 6LoWPAN ND nodes that do not participate 15 to the routing protocol. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 19, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Updating RFC 6775 Update . . . . . . . . . . . . . . . . . . 5 55 5. Dependencies on 6LN . . . . . . . . . . . . . . . . . . . . . 5 56 6. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 6 57 6.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 6 58 6.2. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 8 59 6.3. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 9 60 6.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 10 61 6.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 11 62 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 11.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The design of Low Power and Lossy Networks (LLNs) is generally 75 focused on saving energy, which is the most constrained resource of 76 all. Other design constraints, such as a limited memory capacity, 77 duty cycling of the LLN devices and low-power lossy transmissions, 78 derive from that primary concern. 80 The IETF produced the "Routing Protocol for Low Power and Lossy 81 Networks" [RFC6550] (RPL) to provide routing services within such 82 constraints. RPL is a Distance-Vector protocol, which, compared to 83 link-state protocols, limits the amount of topological knowledge that 84 needs to be installed and maintained in each node. In order to 85 operate in constrained networks, RPL allows a Routing Stretch (see 86 [RFC6687]), whereby routing is only performed along a DODAG as 87 opposed to straight along a shortest path between 2 peers, whatever 88 that would mean in a given LLN. This trades the quality of peer-to- 89 peer (P2P) paths for a vastly reduced amount of control traffic and 90 routing state that would be required to operate a any-to-any shortest 91 path protocol. Finally, broken routes may be fixed lazily and on- 92 demand, based on dataplane inconsistency discovery, which avoids 93 wasting energy in the proactive repair of unused paths. 95 In order to cope with lossy transmissions, RPL forms Direction- 96 Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information 97 Solicitation (DIS) and DODAG Information Object (DIO) messages. For 98 most of the nodes, though not all, a DODAG provides multiple 99 forwarding solutions towards the Root of the topology via so-called 100 parents. RPL is designed to adapt to fuzzy connectivity, whereby the 101 physical topology cannot be expected to reach a stable state, with a 102 lazy control that creates routes proactively but only fixes them when 103 they are used by actual traffic. It results that RPL provides 104 reachability for most of the LLN nodes, most of the time, but does 105 not really converge in the classical sense. RPL provides unicast and 106 multicast routing services back to RPL-Aware nodes. A RPL-Aware Node 107 will inject routes to self using Destination Advertisement Object 108 (DAO) messages sent to either their parents in Storing Mode or to the 109 Root indicating their parent in Non-Storing mode. This process 110 effectively forms a DODAG back to the device that is a subset of the 111 DODAG to the Root with all links reversed. 113 The IPv6 [RFC8200]Neighbor Discovery (IPv6 ND) Protocol (NDP) suite 114 [RFC4861] [RFC4862] defined for fast media such a Ethernet, relies 115 heavily on multicast operations for address discovery and duplicate 116 address detection (DAD). 118 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 119 (6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained 120 LLNs. In particular, 6LoWPAN ND introduces a unicast host address 121 registration mechanism that contributes to reduce the use of 122 multicast messages that are present in the classical IPv6 ND 123 protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) 124 that is carried in the unicast Neighbor Solicitation (NS) and 125 Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) 126 and the 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate 127 Address Request (DAR) and Duplicate Address Confirmation (DAC) 128 messages between the 6LR and the 6LoWPAN Border Router (6LBR). In an 129 LLN, the 6LBR is the central repository of all the Registered 130 Addresses in its domain. 132 When a routing protocol such as RPL is used to maintain reachability 133 within a Non-Broadcast Multi-Access (NBMA) subnet, some nodes may act 134 as routers and participate to the routing operations whereas others 135 may be plain hosts. In RPL terms, a plain host that does not 136 participate to the routing protocol is called a Leaf. It must be 137 noted that a 6LN could participate to RPL and inject DAO routes to 138 self, but refrain from advertising DIO and get children. In that 139 case, the 6LN is still a host but not a Leaf. 141 "Registration Extensions for 6LoWPAN Neighbor Discovery" 142 [I-D.ietf-6lo-rfc6775-update] defines an Extended ARO (EARO) with a 143 'R' flag that is set if the Registering Node expects that the 6LR 144 ensures reachability for the Registered Address, e.g., by means of 145 routing or proxying ND. The EARO also includes a sequence counter 146 called Transaction ID (TID), which maps to the Path Sequence Field 147 found in Transit Options in RPL DAO messages. It is a prerequisite 148 for this specification. The DAR and DAC messages are also extended 149 as EDAR and EDAC messages respectively. 151 A RPL-Unaware Leaf (RUL) sets the 'R' flag in the EARO to declare 152 itself as a host with the expectation that the 6LR that accepts the 153 registration injects routing information for the Registered Address 154 in the RPL domain. The packet forwarding operation by the 6LR 155 serving a Leaf 6LN is described in "When to use RFC 6553, 6554 and 156 IPv6-in-IPv6" [I-D.ietf-roll-useofrplinfo]. This document adds the 157 capability by a 6LR to advertise the IPv6 address(es) of the 6LN in 158 the RPL protocol. Examples of routing-agnostic 6LN may include 159 lightly-powered sensors such as window smash sensor (alarm system), 160 or the kinetically powered light switch. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in 167 [RFC2119]. 169 The Terminology used in this document is consistent with and 170 incorporates that described in Terms Used in Routing for Low-Power 171 and Lossy Networks (LLNs). [RFC7102]. 173 Other terms in use in LLNs are found in Terminology for Constrained- 174 Node Networks [RFC7228]. 176 A glossary of classical 6LoWPAN acronyms is given in Appendix A. 178 The term "byte" is used in its now customary sense as a synonym for 179 "octet". 181 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 182 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 183 Low-Power and Lossy Networks" [RFC6550] specification. 185 This document introduces the term RPL Unaware Leaf (RUL) to refer to 186 a node that uses a RPL router (without necessarily knowing it) as 6LR 187 and depends on that router to obtain reachability for its addresses 188 inside the RPL domain. 190 3. Updating RFC 6550 192 This document specifies a new behavior whereby a 6LR injects DAO 193 messages for unicast addresses registered through the updated 6LoWPAN 194 ND [I-D.ietf-6lo-rfc6775-update] on behalf of 6LN nodes that are not 195 RPL-aware. 197 Upon the renewal of a 6lowPAN ND registration, this specification 198 changes the behavior of the 6LR as follows. If the 'R' flag is set, 199 the 6LR injects a DAO targeting the Registered Address, and refrains 200 from sending a DAR message. the DAR/DAC exchange that refreshes the 201 state in the 6LBR happens instead between the RPL Root and the 6LBR. 202 In that flow, the RPL Root acts as a proxy on behalf of the 6LR upon 203 the reception of the DAO propagation initiated at the 6LR. 205 4. Updating RFC 6775 Update 207 The behavior defined in this specification whereby the 6LR that 208 processes the registration advertises the Registered Address in DAO 209 messages and bypasses the DAR/DAC process for the renewal of a 210 registration, is only triggered by an NS(EARO) that has the 'R' flag 211 set. If the 'R' flag is not set, then the Registering Node is 212 expected to be a RPL router that handles the reachability of the 213 Registered Address by itself. 215 This document also specifies a keep-alive EDAR message that the RPL 216 Root may use to maintain an existing state in the 6LBR upon receiving 217 DAO messages. The keep-alive EDAR message may only act as a 218 refresher and can only update the Lifetime and the TID of the state 219 in the 6LBR. 221 This document similarly specifies a keep-alive NS(EARO) message that 222 the RPL Root may use to maintain an existing state in a 6BBR upon 223 receiving DAO messages. The keep-alive NS(EARO) message may only act 224 as a refresher and can only update the Lifetime and the TID of the 225 state in the 6BBR. 227 As prescribed by [I-D.ietf-6lo-rfc6775-update], a RPL router SHOULD 228 NOT set the 'R' flag. 230 5. Dependencies on the 6LN 232 This document provides RPL routing for a 6LN acting as a plain host 233 and not aware of RPL. Still, a minimal RPL-independent functionality 234 is expected from the 6LN in order to operate properly as a RLU; in 235 particular: 237 o the 6LN MUST implement [I-D.ietf-6lo-rfc6775-update] and set the 238 'R' flag in the EARO option. The 'R' flag is used to determine 239 whether the Registering Node is a RUL, not aware of the RPL 240 operation in the network, and thus does not participate to it. A 241 6LN is considered to be a RUL if and only if it sets the 'R' flag 242 in the EARO. 243 o RPL data packets typically carry a Hop-by-Hop Header to transport 244 a RPL Packet Information (RPI) [RFC6550]. The 6LN MUST ignore the 245 RPI and skip the HbH header. 246 o RPL data packets are often encapsulated using IP in IP. The 6LN 247 MUST be able to decapsulate a packet when it is the destination of 248 the outer header and process correctly the inner header. 250 6. Protocol Operations 252 6.1. General Flow 254 This specification enables to save the exchange of Extended Duplicate 255 Address messages, EDAR and EDAC, from a 6LN all the way to the 6LBR 256 across a RPL mesh, for the sole purpose of refreshing an existing 257 state in the 6LBR. Instead, the EDAR/EDAC exchange is proxied by the 258 RPL Root upon a DAO message that refreshes the RPL routing state. To 259 achieve this, the lifetimes and sequence counters in 6LoWPAN ND and 260 RPL are aligned. In other words, the Path Sequence and the Path 261 Lifetime in the DAO message are derived from the Transaction ID and 262 the registration lifetime in the NS(EARO) message from the 6LN. 264 From the perspective of the 6LN, the registration flow happens 265 transparently; it is not delayed by the proxy RPL operation, so the 266 device does not need to wait more whether RPL proxy operation happens 267 or not. The flows below are RPL Non-Storing Mode examples. In 268 Storing Mode, the DAO ACK may not be present, and the DAO messages 269 cascade from child to parent all the way to the DODAG Root. 271 On the first registration, illustrated in Figure 1, from the 272 perspective of the 6LR, the Extended Duplicate Address message takes 273 place as prescribed by [I-D.ietf-6lo-rfc6775-update]. When 274 successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR, 275 and the 6LR injects the Registered Address in RPL using DAO/DAO-ACK 276 exchanges all the way to the RPL DODAG Root. The protocol does not 277 carry a specific information that the Extended Duplicate Address 278 messages were already exchanged, so the Root proxies them anyway. 280 6LN 6LR Root 6LBR 281 | | | | 282 | NS(EARO) | | | 283 |--------------->| | 284 | | Extended DAR | 285 | |-------------------------------->| 286 | | | 287 | | Extended DAC | 288 | |<--------------------------------| 289 | NA(EARO) | | 290 |<---------------| | | 291 | | DAO | | 292 | |-------------->| | 293 | | DAO ACK | | 294 | |<--------------| | 295 | | | keep-alive EDAR | 296 | | |---------------->| 297 | | | EDAC | 298 | | |<----------------| 299 | | | | 301 Figure 1: First Registration Flow 303 A re-registration is performed by the 6LN to maintain the NCE in the 304 6LR alive before lifetime expires. Upon a re-registration, as 305 illustrated in Figure 1, the 6LR redistributes the Registered Address 306 NS(EARO) in RPL. This causes the RPL DODAG Root to refresh the state 307 in the 6LBR with a keep-alive EDAC message. The keep-alive EDAC 308 lacks the Registration Ownership Verifier (ROVR) information, since 309 it is not present in RPL DAO messages, but the EDAC message sent in 310 response by the 6LBR contains the actual value of the ROVR field for 311 that registration. This enables the RPL Root to perform the proxy- 312 registration for the Registered Address and attract traffic captured 313 over the backbone by the 6BBR and route it back to the device. 315 6LN 6LR Root 6LBR 6BBR 316 | | | | | 317 | NS(EARO) | | | | 318 |--------------->| | | | 319 | NA(EARO) | | | | 320 |<---------------| | | | 321 | | | | | 322 | | DAO | | | 323 | |-------------->| | | 324 | | DAO ACK | | | 325 | |<--------------| | | 326 | | | | | 327 | | | keep-alive EDAR | | 328 | | |---------------->| | 329 | | | EDAC(ROVR) | | 330 | | |<----------------| | 331 | | | | | 332 | | | proxy NS(EARO) | 333 | | |-------------------------------->| 334 | | | proxy NA(EARO) | 335 | | |<--------------------------------| 336 | | | | | 338 Figure 2: Next Registration Flow 340 Note that any of the functions 6LR, Root and 6LBR might be collapsed 341 in a single node, in which case the flow above happens internally, 342 and possibly through internal API calls as opposed to messaging. 344 6.2. 6LN Operation 346 This specification does not alter the operation of a 6LowpAN ND- 347 compliant 6LN, which is expected to operate as follows: 349 o The 6LN obtains an IPv6 global address, for instance using 350 autoconfiguration [RFC4862] based on a Prefix Information Option 351 (PIO) [RFC4861] found in a Router Advertisement message or by some 352 other means such as DHCPv6 [RFC3315]. 353 o Once it has formed an address, the 6LN (re)registers its address 354 periodically, within the Lifetime of the previous registration, as 355 prescribed by [I-D.ietf-6lo-rfc6775-update]. 356 o Upon each consecutive registration, the 6LN increases the TID 357 field. 358 o The 6LN MAY register to more than one 6LR at the same time. In 359 that case, a same value of TID is used for each registration. 360 o The 6LN MAY use any of the 6LRs to which it register to forward 361 its packets. 363 6.3. 6LR Operation 365 Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR 366 generates a DAR message upon reception of a valid NS(EARO) message 367 for the registration of a new IPv6 Address by a 6LN. If the 368 Duplicate Address exchange succeeds, then the 6LR installs a Neighbor 369 Cache Entry (NCE). If the 'R' flag was set in the EARO of the NS 370 message, and this 6LR can manage the reachability of Registered 371 Address, then the 6LR sets the 'R' flag in the ARO of the response NA 372 message. 374 From then on, the 6LN periodically sends a new NS(EARO) to refresh 375 the NCE state before the lifetime indicated in the EARO expires, with 376 TID that is incremented each time till it wraps in a lollipop 377 fashion. As long as the 'R' flag is set and this router can still 378 manage the reachability of Registered Address, the 6LR keeps setting 379 the 'R' flag in the EARO of the response NA message, but the exchange 380 of Extended Duplicate Address messages is skipped. 382 Upon a successful NS/NA(EARO) exchange: if the 'R' flag was set in 383 the EARO of the NS message, then the 6LR SHOULD inject the Registered 384 Address in RPL by sending a DAO message on behalf of the 6LN; else 385 the 6LR MUST NOT inject the Registered Address into RPL. 387 The DAO message advertising the Registered Address MUST be 388 constructed as follows: 390 o The Registered Address is placed in a RPL Target Option in the DAO 391 message as the Target Prefix, and the Prefix Length is set to 128 392 o the External 'E' flag in the Transit Information Option (TIO) 393 associated to the Target Option is set to indicate that the 6LR 394 redistributes an external target into the RPL network 395 o the Path Lifetime in the TIO is computed from the Lifetime in the 396 EARO Option to adapt it to the Lifetime Units used in the RPL 397 operation. Note that if the lifetime is 0, then the 6LR generates 398 a No-Path DAO message that cleans up the routes down to the 399 Address of the 6LN. 400 o the Path Sequence in the TIO is set to the TID value found in the 401 EARO option. 402 o Additionally, in Non-Storing Mode the 6LR indicates one of its 403 global IPv6 unicast addresses as the Parent Address in the TIO. 405 If a 6LR receives a valid NS(EARO) message with the 'R' flag reset 406 and the 6LR was redistributing the Registered Address due to previous 407 NS(EARO) messages with the flag set, then it MUST stop injecting the 408 address. It is up to the Registering Node to maintain the 409 corresponding route from then on, either keeping it active by sending 410 further DAO messages, or destroying it using a No-Path DAO. 412 6.4. RPL Root Operation 414 In RPL Storing Mode of Operation (MOP), the DAO message is propagated 415 from child to parent all the way to the Root along the DODAG, 416 populating routing state as it goes. In Non-Storing Mode, The DAO 417 message is sent directly to the route. Upon reception of a DAO 418 message that creates or updates an existing RPL state: 420 o the Root notifies the 6LBR using an internal API if they are 421 collocated, or performs a keep-alive DAR/DAC exchange on behalf of 422 the registering node if they are separated. 423 o In an extended topology with a Backbone Link, the Root notifies 424 the 6LBR by proxying a keep-alive NS(EARO) on behalf of the 6LN 425 that owns the address indicated in the Target Option. 427 The keep-alive EDAR and the NS(EARO) messages MUST be constructed as 428 follows: 430 o The Target IPv6 address from in the RPL Target Option is placed in 431 the Registered Address field of the EDAR message and in the Target 432 field of the NS message, respectively 433 o the ROVR field in the keep-alive EDAR is set to 64-bits of all 434 ones to indicate that it is not provided and this is a keep-alive 435 EDAR. The actual value of the ROVR for that registration is 436 returned by the 6LBR in an EDAC, and used in the proxy NS(EARO). 437 o the Registration Lifetime is adapted from the Path Lifetime in the 438 TIO by converting the Lifetime Units used in RPL into units of 60 439 seconds used in the 6LoWPAN ND messages. 440 o The RPL Root indicates its own MAC Address as Source Link Layer 441 Address (SLLA) in the NS(EARO). 442 o the TID value is set to the Path Sequence in the TIO. The 'T' 443 flag and an ICMP code of 1 are used in the NS(EARO) and the DAR 444 message, respectively. 446 Upon a status in a DAC message that is not "Success", the Root MAY 447 destroy the formed paths using a No-Path DAO downwards as specified 448 in [I-D.ietf-roll-efficient-npdao]. 450 In Non-Storing Mode, the outer IPv6 header that is used by the Root 451 to transport the source routing information in data packets down the 452 DODAG has the 6LR that serves the 6LN as final destination. This 453 way, when the final 6LR decapsulates the outer header, it also 454 removes all the RPL artifacts from the packet. 456 6.5. 6LBR Operation 458 Upon reception of a DAR message with the Owner Unique ID field is set 459 to all ones, the 6LBR checks whether an entry exists for the and 460 computes whether the TID in the DAR message is fresher than that in 461 the entry as prescribed in section 4.2.1. of 462 [I-D.ietf-6lo-rfc6775-update]. 464 If the entry does not exist, the 6LBR does not create the entry, and 465 answers with a Status "Removed" in the DAC message. 467 If the entry exists but is not fresher, the 6LBR does not update the 468 entry, and answers with a Status "Success" in the DAC message. 470 If the entry exists and the TID in the DAR message is fresher, the 471 6LBR updates the TID in the entry, and if the lifetime of the entry 472 is extended by the Registration Lifetime in the DAR message, it also 473 updates the lifetime of the entry. In that case, the 6LBR replies 474 with a Status "Success" in the DAC message. 476 7. Implementation Status 478 8. Security Considerations 480 The LLN nodes depend on the 6LBR and the RPL participants for their 481 operation. A trust model must be put in place to ensure that the 482 right devices are acting in these roles, so as to avoid threats such 483 as black-holing, or bombing attack whereby an impersonated 6LBR would 484 destroy state in the network by using the "Removed" Status code. 485 This trust model could be at a minimum based on a Layer-2 access 486 control, or could provide role validation as well. This is a generic 487 6LoWPAN requirement, see Req5.1 in Appendix of 488 [I-D.ietf-6lo-rfc6775-update]. 490 The keep-alive EDAR message does not carry a valid Registration 491 Unique ID [I-D.ietf-6lo-rfc6775-update] and it cannot be used to 492 create a binding state in the 6LBR. The 6LBR MUST NOT create an 493 entry based on a keep-alive EDAR that does not match an existing 494 entry. All it can do is refresh the lifetime and the TID of an 495 existing entry. 497 9. IANA Considerations 499 This specification has no requirement on IANA. 501 10. Acknowledgments 503 The author wishes to thank Michael Richardson and Georgios 504 Papadopoulos for their early reviews of and contributions to this 505 document 507 11. References 509 11.1. Normative References 511 [I-D.ietf-6lo-rfc6775-update] 512 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 513 Perkins, "Registration Extensions for 6LoWPAN Neighbor 514 Discovery", draft-ietf-6lo-rfc6775-update-15 (work in 515 progress), March 2018. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 523 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 524 DOI 10.17487/RFC4861, September 2007, 525 . 527 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 528 Address Autoconfiguration", RFC 4862, 529 DOI 10.17487/RFC4862, September 2007, 530 . 532 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 533 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 534 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 535 Low-Power and Lossy Networks", RFC 6550, 536 DOI 10.17487/RFC6550, March 2012, 537 . 539 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 540 Bormann, "Neighbor Discovery Optimization for IPv6 over 541 Low-Power Wireless Personal Area Networks (6LoWPANs)", 542 RFC 6775, DOI 10.17487/RFC6775, November 2012, 543 . 545 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 546 (IPv6) Specification", STD 86, RFC 8200, 547 DOI 10.17487/RFC8200, July 2017, 548 . 550 11.2. Informative References 552 [I-D.ietf-6lo-ap-nd] 553 Thubert, P., Sarikaya, B., and M. Sethi, "Address 554 Protected Neighbor Discovery for Low-power and Lossy 555 Networks", draft-ietf-6lo-ap-nd-06 (work in progress), 556 February 2018. 558 [I-D.ietf-roll-efficient-npdao] 559 Jadhav, R., Sahoo, R., and Z. Cao, "No-Path DAO 560 modifications", draft-ietf-roll-efficient-npdao-01 (work 561 in progress), October 2017. 563 [I-D.ietf-roll-useofrplinfo] 564 Robles, I., Richardson, M., and P. Thubert, "When to use 565 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 566 useofrplinfo-22 (work in progress), March 2018. 568 [IEEEstd802154] 569 IEEE standard for Information Technology, "IEEE Standard 570 for Local and metropolitan area networks-- Part 15.4: Low- 571 Rate Wireless Personal Area Networks (LR-WPANs)". 573 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 574 C., and M. Carney, "Dynamic Host Configuration Protocol 575 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 576 2003, . 578 [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, 579 Ed., "Performance Evaluation of the Routing Protocol for 580 Low-Power and Lossy Networks (RPL)", RFC 6687, 581 DOI 10.17487/RFC6687, October 2012, 582 . 584 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 585 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 586 2014, . 588 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 589 Constrained-Node Networks", RFC 7228, 590 DOI 10.17487/RFC7228, May 2014, 591 . 593 Appendix A. Subset of a 6LoWPAN Glossary 595 This document often uses the followng acronyms: 597 6BBR: 6LoWPAN Backbone Router (proxy for the registration) 598 6LBR: 6LoWPAN Border Router (authoritative on DAD) 599 6LN: 6LoWPAN Node 600 6LR: 6LoWPAN Router (relay to the registration process) 601 6CIO: Capability Indication Option 602 (E)ARO: (Extended) Address Registration Option 603 DAD: Duplicate Address Detection 604 LLN: Low Power Lossy Network (a typical IoT network) 605 NA: Neighbor Advertisement 606 NCE: Neighbor Cache Entry 607 ND: Neighbor Discovery 608 NDP: Neighbor Discovery Protocol 609 NS: Neighbor Solicitation 610 RUID: Registration Unique ID 611 TSCH: TimeSlotted Channel Hopping 612 TID: Transaction ID (a sequence counter in the EARO) 614 Author's Address 616 Pascal Thubert (editor) 617 Cisco Systems, Inc 618 Building D 619 45 Allee des Ormes - BP1200 620 MOUGINS - Sophia Antipolis 06254 621 FRANCE 623 Phone: +33 497 23 26 34 624 Email: pthubert@cisco.com