idnits 2.17.1 draft-ietf-roll-unaware-leaves-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8505, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2019) is 1760 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) ** Downref: Normative reference to an Informational RFC: RFC 4919 ** Downref: Normative reference to an Informational RFC: RFC 6606 == Outdated reference: A later version (-18) exists of draft-ietf-roll-efficient-npdao-13 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-30 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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, 8505 (if approved) July 2, 2019 5 Intended status: Standards Track 6 Expires: January 3, 2020 8 Routing for RPL Leaves 9 draft-ietf-roll-unaware-leaves-01 11 Abstract 13 This specification leverages 6LoWPAN ND to provide a unicast and 14 multicast routing service in a RPL domain to 6LNs that do not 15 participate to RPL. 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 January 3, 2020. 34 Copyright Notice 36 Copyright (c) 2019 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 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6 57 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Dependencies on the 6LN . . . . . . . . . . . . . . . . . . . 8 60 7. Protocol Operations for Unicast Addresses . . . . . . . . . . 9 61 7.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 9 62 7.2. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 11 63 7.3. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 12 64 7.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 13 65 7.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 14 66 8. Protocol Operations for Multicast Addresses . . . . . . . . . 15 67 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 73 13.2. Informative References . . . . . . . . . . . . . . . . . 19 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 The design of Low Power and Lossy Networks (LLNs) is generally 79 focused on saving energy, which is the most constrained resource of 80 all. Other design constraints, such as a limited memory capacity, 81 duty cycling of the LLN devices and low-power lossy transmissions, 82 derive from that primary concern. 84 The IETF produced the "Routing Protocol for Low Power and Lossy 85 Networks" [RFC6550] (RPL) to provide routing services within such 86 constraints. RPL is a Distance-Vector protocol, which, compared to 87 link-state protocols, limits the amount of topological knowledge that 88 needs to be installed and maintained in each node. In order to 89 operate in constrained networks, RPL allows a Routing Stretch (see 90 [RFC6687]), whereby routing is only performed along a DODAG as 91 opposed to straight along a shortest path between 2 peers, whatever 92 that would mean in a given LLN. This trades the quality of peer-to- 93 peer (P2P) paths for a vastly reduced amount of control traffic and 94 routing state that would be required to operate a any-to-any shortest 95 path protocol. Finally, broken routes may be fixed lazily and on- 96 demand, based on dataplane inconsistency discovery, which avoids 97 wasting energy in the proactive repair of unused paths. 99 In order to cope with lossy transmissions, RPL forms Direction- 100 Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information 101 Solicitation (DIS) and DODAG Information Object (DIO) messages. For 102 most of the nodes, though not all, a DODAG provides multiple 103 forwarding solutions towards the Root of the topology via so-called 104 parents. RPL is designed to adapt to fuzzy connectivity, whereby the 105 physical topology cannot be expected to reach a stable state, with a 106 lazy control that creates routes proactively but only fixes them when 107 they are used by actual traffic. It results that RPL provides 108 reachability for most of the LLN nodes, most of the time, but does 109 not really converge in the classical sense. RPL provides unicast and 110 multicast routing services back to RPL-Aware nodes (RANs). A RAN 111 will inject routes to self using Destination Advertisement Object 112 (DAO) messages sent to either their parents in Storing Mode or to the 113 Root indicating their parent in Non-Storing Mode. This process 114 effectively forms a DODAG back to the device that is a subset of the 115 DODAG to the Root with all links reversed. 117 When a routing protocol such as RPL is used to maintain reachability 118 within a Non-Broadcast Multi-Access (NBMA) subnet, some nodes may act 119 as routers and participate to the routing operations whereas others 120 may be plain hosts. In RPL terms, a plain host that does not 121 participate to the routing protocol is called a Leaf. It must be 122 noted that a 6LN could participate to RPL and inject DAO routes to 123 self, but refrain from advertising DIO and get children. In that 124 case, the 6LN is still a host but not a Leaf. 126 This specification enables a RPL-Unaware Leaf (RUL) to announce 127 itself as a host and demand that the 6LR that accepts the 128 registration also inject the relevant routing information for the 129 Registered Address in the RPL domain on its behalf. The unicast 130 packet forwarding operation by the 6LR serving a Leaf 6LN is 131 described in "When to use RFC 6553, 6554 and IPv6-in-IPv6" 132 [I-D.ietf-roll-useofrplinfo]. This document adds the capability by a 133 6LR to advertise the Global, Unique-Local and Multicast IPv6 134 address(es) of the 6LN in the RPL protocol. 136 Examples of routing-agnostic 6LN may include lightly-powered sensors 137 such as window smash sensor (alarm system), or the kinetically 138 powered light switch. Other application of this specification may 139 include a smart grid network that controls appliances - such as 140 washing machines or the heating system - in the home. Applicances 141 may not participate to the RPL protocol operated in the smart grid 142 network but can still receive control packet from the smart grid. 144 2. Terminology 146 2.1. BCP 14 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119][RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2.2. References 156 The Terminology used in this document is consistent with and 157 incorporates that described in Terms Used in Routing for Low-Power 158 and Lossy Networks (LLNs). [RFC7102]. 160 Other terms in use in LLNs are found in Terminology for Constrained- 161 Node Networks [RFC7228]. 163 A glossary of classical 6LoWPAN acronyms is given in Section 2.3. 165 The term "byte" is used in its now customary sense as a synonym for 166 "octet". 168 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 169 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 170 Low-Power and Lossy Networks" [RFC6550] specification. 172 This document introduces the term RPL-Unaware Leaf (RUL) to refer to 173 a node that uses a RPL router (without necessarily knowing it) as 6LR 174 and depends on that router to obtain reachability for its addresses 175 inside the RPL domain. On the contrary, the term RPL-Aware Leaf 176 (RAL) is used to refer to a host or a router that participates to RPL 177 and advertises its addresses of prefixes by itself. 179 Other terms in use in LLNs are found in Terminology for Constrained- 180 Node Networks [RFC7228]. 182 Readers are expected to be familiar with all the terms and concepts 183 that are discussed in 185 o "Neighbor Discovery for IP version 6" [RFC4861], 187 o "IPv6 Stateless Address Autoconfiguration" [RFC4862], 189 o "Problem Statement and Requirements for IPv6 over Low-Power 190 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], 192 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 193 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 195 o "Neighbor Discovery Optimization for Low-power and Lossy Networks" 196 [RFC6775], and 198 o "Registration Extensions for IPv6 over Low-Power Wireless Personal 199 Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]. 201 2.3. Glossary 203 This document often uses the following acronyms: 205 AR: Address Resolution (aka Address Lookup) 207 6BBR: 6LoWPAN Backbone Router (proxy ND) 209 6LBR: 6LoWPAN Border Router (an Address Registrar that is 210 authoritative on DAD) 212 6LN: 6LoWPAN Node (a Low Power host or router) 214 6LR: 6LoWPAN Router 216 6CIO: Capability Indication Option 218 (E)ARO: (Extended) Address Registration Option 220 (E)DAR: (Extended) Duplicate Address Request 222 (E)DAC: (Extended) Duplicate Address Confirmation 224 DAD: Duplicate Address Detection 226 DODAG: Destination-Oriented Directed Acyclic Graph 228 LLN: Low-Power and Lossy Network 230 NA: Neighbor Advertisement 232 NCE: Neighbor Cache Entry 234 ND: Neighbor Discovery 236 NDP: Neighbor Discovery Protocol 238 NS: Neighbor Solicitation 239 RA: Router Advertisement 241 ROVR: Registration Ownership Verifier (pronounced rover) 243 RPI: RPL Packet Information (an Option in the Hop-By_Hop header) 245 RAL: RPL-Aware Leaf 247 RS: Router Solicitation 249 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) 251 RUL: RPL-Unaware Leaf 253 TID: Transaction ID (a sequence counter in the EARO) 255 3. 6LoWPAN Neighbor Discovery 257 The IPv6 [RFC8200]Neighbor Discovery (IPv6 ND) Protocol (NDP) suite 258 [RFC4861] [RFC4862] defined for fast media such a Ethernet, relies 259 heavily on multicast operations for address discovery and duplicate 260 address detection (DAD). 262 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 263 (6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained 264 LLNs. In particular, 6LoWPAN ND introduces a unicast host address 265 registration mechanism that contributes to reduce the use of 266 multicast messages that are present in the classical IPv6 ND 267 protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) 268 that is carried in the unicast Neighbor Solicitation (NS) and 269 Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) 270 and the 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate 271 Address Request (DAR) and Duplicate Address Confirmation (DAC) 272 messages between the 6LR and the 6LoWPAN Border Router (6LBR). In an 273 LLN, the 6LBR is the central repository of all the Registered 274 Addresses in its domain. 276 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 277 updates the behavior of RFC 6775 to enable a generic registration to 278 routing services and defines an Extended ARO (EARO). The format of 279 the EARO is shown in Figure 1: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | Status | Opaque | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Rsvd | I |R|T| TID | Registration Lifetime | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 ... Registration Ownership Verifier ... 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 1: EARO Option Format 295 The 'R' flag that is set if the Registering Node expects that the 6LR 296 ensures reachability for the Registered Address, e.g., by means of 297 routing or proxying ND. 299 The EARO also includes a sequence counter called Transaction ID 300 (TID), which maps to the Path Sequence Field found in Transit Options 301 in RPL DAO messages. It is a prerequisite for this specification. 303 Finally, the EARO transports an Opaque field and an 'I' field that 304 describes what the Opaque field transports and how to use it. This 305 specification requires that the I field is left to 0 and to use the 306 Opaque field to carry the RPL InstanceID if one is known, else to 307 leave the Opaque field to zero. 309 4. Updating RFC 6550 311 This document specifies a new behavior whereby a 6LR injects DAO 312 messages for unicast addresses registered through the updated 6LoWPAN 313 ND [RFC8505] on behalf of 6LN nodes that are not RPL-aware. 315 Upon the renewal of a 6LoWPAN ND registration, this specification 316 changes the behavior of the 6LR as follows. If the 'R' flag is set, 317 the 6LR injects a DAO targeting the Registered Address, and refrains 318 from sending a DAR message. the DAR/DAC exchange that refreshes the 319 state in the 6LBR happens instead between the RPL Root and the 6LBR. 320 In that flow, the RPL Root acts as a proxy on behalf of the 6LR upon 321 the reception of the DAO propagation initiated at the 6LR. 323 5. Updating RFC 8505 325 The behavior defined in this specification whereby the 6LR that 326 processes the registration advertises the Registered Address in DAO 327 messages and bypasses the DAR/DAC process for the renewal of a 328 registration, is only triggered by an NS(EARO) that has the 'R' flag 329 set. If the 'R' flag is not set, then the Registering Node is 330 expected to be a RAN router that handles the reachability of the 331 Registered Address by itself. 333 This document also specifies a keep-alive EDAR message that the RPL 334 Root may use to maintain an existing state in the 6LBR upon receiving 335 DAO messages. The keep-alive EDAR message may only act as a 336 refresher and can only update the Lifetime and the TID of the state 337 in the 6LBR. 339 This document similarly specifies a keep-alive NS(EARO) message that 340 the RPL Root may use to maintain an existing state in a 6BBR upon 341 receiving DAO messages. The keep-alive NS(EARO) message may only act 342 as a refresher and can only update the Lifetime and the TID of the 343 state in the 6BBR. 345 As prescribed by [RFC8505], a RPL router SHOULD NOT set the 'R' flag. 347 6. Dependencies on the 6LN 349 This document provides RPL routing for a 6LN acting as a plain host 350 and not aware of RPL. Still, a minimal RPL-independent functionality 351 is expected from the 6LN in order to operate properly as a RLU; in 352 particular: 354 o the 6LN MUST implement [RFC8505] and set the 'R' flag in the EARO 355 option. The 'R' flag is used to determine whether the Registering 356 Node is a RUL, not aware of the RPL operation in the network, and 357 thus does not participate to it. A 6LN is considered to be a RUL 358 if and only if it sets the 'R' flag in the EARO. 360 o RPL data packets are often encapsulated using IP in IP and in Non- 361 Storing Mode, packets going down will carry an SRH as well. RPL 362 data packets also typically carry a Hop-by-Hop Header to transport 363 a RPL Packet Information (RPI) [RFC6550]. These additional 364 headers are called RPL artifacts. 366 o An arbitrary 6LN is expected to support IPv6-in-IPv6 encapsulation 367 when it is the destination of the outer header. If the 6LN is a 368 host, it is expected to drop the inner packet if it is not the 369 destination of the inner header. 371 o An arbitrary 6LN is expected to process an unknown Option Type in 372 a Hop-by-Hop Header as prescribed by section 4.2 of [RFC8200]. 373 This means in particular that an RPI with an Option Type of 0x23 374 [I-D.ietf-roll-useofrplinfo] is ignored when not understood. 376 o An arbitrary 6LN is expected to process an unknown Routing Header 377 Type as prescribed by section 4.4 of [RFC8200]. This means in 378 particular that Routing Header with a Routing Type of 3 [RFC6553] 379 is ignored when the Segments Left is zero, and dropped otherwise. 381 o When IP-in-IP is used and the outer headers terminate at the 6LR 382 that generated the DAO, then the 6LR decapsulates the packet to 383 the 6LN. In that case the 6LN gets a packet that is free of RPL 384 artifacts. IP-in-IP to the 6LR MUST be used if the 6LN cannot 385 handle or ignore the RPL artifacts or the way they are compressed 386 [RFC8138]. It SHOULD be used it there is a particular bandwidth 387 or power constraint at the 6LN that justifies saving the 388 encapsulation at the last hop. 390 o In order to save the IP-in-IP encapsulation and to support Storing 391 Mode of operation, it is preferred that the 6LN can ignore an RPI 392 and consume a routing header in both the native and compressed 393 forms. In order to enable IP-in-IP to a 6LN in Non-Storing Mode, 394 it is also of interest that the 6LN supports decapsulating IP-in- 395 IP in both forms. But since the preferred behaviour when using 396 IP-in-IP is that the outter headers terminate at the 6LR, 397 supporting this capability is secondary. 399 7. Protocol Operations for Unicast Addresses 401 7.1. General Flow 403 This specification enables to save the exchange of Extended Duplicate 404 Address messages, EDAR and EDAC, from a 6LN all the way to the 6LBR 405 across a RPL mesh, for the sole purpose of refreshing an existing 406 state in the 6LBR. Instead, the EDAR/EDAC exchange is proxied by the 407 RPL Root upon a DAO message that refreshes the RPL routing state. To 408 achieve this, the lifetimes and sequence counters in 6LoWPAN ND and 409 RPL are aligned. In other words, the Path Sequence and the Path 410 Lifetime in the DAO message are derived from the Transaction ID and 411 the registration lifetime in the NS(EARO) message from the 6LN. 413 From the perspective of the 6LN, the registration flow happens 414 transparently; it is not delayed by the proxy RPL operation, so the 415 device does not need to wait more whether RPL proxy operation happens 416 or not. The flows below are RPL Non-Storing Mode examples. In 417 Storing Mode, the DAO ACK may not be present, and the DAO messages 418 cascade from child to parent all the way to the DODAG Root. 420 On the first registration, illustrated in Figure 2, from the 421 perspective of the 6LR in Non-Storing Mode, the Extended Duplicate 422 Address message takes place as prescribed by [RFC8505]. When 423 successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR, 424 and the 6LR injects the Registered Address in RPL using DAO/DAO-ACK 425 exchanges all the way to the RPL DODAG Root. The protocol does not 426 carry a specific information that the Extended Duplicate Address 427 messages were already exchanged, so the Root proxies them anyway. 428 Note that in Storing Mode the DAO ACK is generated from the parent 429 that does not necessary wait for the grand parent to acknowledge, so 430 the DAO-ACK is no guarantee that the keep-alive EDAR succeeded. On 431 the other hand, the flows can be nested in Non-Storing Mode, and it 432 is possible to carry information such as an updated lifetime from the 433 6LBR all the way to the 6LN. 435 6LN 6LR Root 6LBR 436 | | | | 437 | NS(EARO) | | | 438 |--------------->| | 439 | | Extended DAR | 440 | |-------------------------------->| 441 | | | 442 | | Extended DAC | 443 | |<--------------------------------| 444 | | DAO | | 445 | |-------------->| | 446 | | | keep-alive EDAR | 447 | | |---------------->| 448 | | | EDAC | 449 | | |<----------------| 450 | | DAO ACK | | 451 | |<--------------| | 452 | NA(EARO) | | 453 |<---------------| | | 454 | | | | 456 Figure 2: First Registration Flow 458 A re-registration is performed by the 6LN to maintain the NCE in the 459 6LR alive before lifetime expires. Upon a re-registration, as 460 illustrated in Figure 3, the 6LR redistributes the Registered Address 461 NS(EARO) in RPL. This causes the RPL DODAG Root to refresh the state 462 in the 6LBR with a keep-alive EDAC message. The keep-alive EDAC 463 lacks the Registration Ownership Verifier (ROVR) information, since 464 it is not present in RPL DAO messages, but the EDAC message sent in 465 response by the 6LBR contains the actual value of the ROVR field for 466 that registration. This enables the RPL Root to perform the proxy- 467 registration for the Registered Address and attract traffic captured 468 over the backbone by the 6BBR and route it back to the device. 470 6LN 6LR Root 6LBR 6BBR 471 | | | | | 472 | NS(EARO) | | | | 473 |-------------->| | | | 474 | NA(EARO) | | | | 475 |<--------------| | | | 476 | | | | | 477 | | DAO | | | 478 | |-------------->| | | 479 | | | | | 480 | | | keep-alive EDAR | | 481 | | |---------------->| | 482 | | | EDAC(ROVR) | | 483 | | |<----------------| | 484 | | | | | 485 | | | proxy NS(EARO) | 486 | | |------------------------------->| 487 | | | proxy NA(EARO) | 488 | | |<-------------------------------| 489 | | | | | 490 | | DAO ACK | | | 491 | |<--------------| | | 492 | | | | | 494 Figure 3: Next Registration Flow 496 Note that any of the functions 6LR, Root and 6LBR might be collapsed 497 in a single node, in which case the flow above happens internally, 498 and possibly through internal API calls as opposed to messaging. 500 7.2. 6LN Operation 502 This specification does not alter the operation of a 6LoWPAN ND- 503 compliant 6LN, which is expected to operate as follows: 505 o The 6LN obtains an IPv6 global address, for instance using 506 autoconfiguration [RFC4862] based on a Prefix Information Option 507 (PIO) [RFC4861] found in a Router Advertisement message or by some 508 other means such as DHCPv6 [RFC3315]. 510 o Once it has formed an address, the 6LN (re)registers its address 511 periodically, within the Lifetime of the previous registration, as 512 prescribed by [RFC8505]. 514 o Upon each consecutive registration, the 6LN MUST increase the TID 515 field. 517 o If the 6LN is aware of the RPL Instance the packet should be 518 injected into, then it SHOULD set the Opaque field to the 519 InstanceID, else it MUST leave the Opaque field to zero. In any 520 fashion the 6LN MUST set the 'I' field to zero. 522 o A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a 523 6LN acting as a RAN SHOULD NOT set the 'R' flag. 525 o The 6LN MAY register to more than one 6LR at the same time. In 526 that case, a same value of TID is used for each registration. 528 o The 6LN MAY use any of the 6LRs to which it register to forward 529 its packets. 531 o the 6LN is not expected to be aware of RPL so it is not expected 532 to produce RPL artifacts in the data packets. 534 7.3. 6LR Operation 536 Also as prescribed by [RFC8505], the 6LR generates a DAR message upon 537 reception of a valid NS(EARO) message for the registration of a new 538 IPv6 Address by a 6LN. If the Duplicate Address exchange succeeds, 539 then the 6LR installs a Neighbor Cache Entry (NCE). If the 'R' flag 540 was set in the EARO of the NS message, and this 6LR can manage the 541 reachability of Registered Address, then the 6LR sets the 'R' flag in 542 the ARO of the response NA message. 544 From then on, the 6LN periodically sends a new NS(EARO) to refresh 545 the NCE state before the lifetime indicated in the EARO expires, with 546 TID that is incremented each time till it wraps in a lollipop 547 fashion. As long as the 'R' flag is set and this router can still 548 manage the reachability of Registered Address, the 6LR keeps setting 549 the 'R' flag in the EARO of the response NA message, but the exchange 550 of Extended Duplicate Address messages is skipped. 552 The Opaque field in the EARO hints the 6LR on the RPL Instance that 553 should be used for the DAO advertisements, and for the forwarding of 554 packets sourced at the registered address when there is no RPL Packet 555 Information (RPI) in the packet, in which case the 6LR SHOULD add one 556 to the packet. if the 'I' field is not zero, then the 6LR MUST 557 consider that the Opaque field is left to zero. If the Opaque field 558 is not set to zero, then it should carry a RPL InstanceID for the 559 Instance suggested by the 6LN. If the 6LR does not participate to 560 the associated Instance, then the 6LR MUST consider that the Opaque 561 field is left to zero. If the Opaque field left to zero, the 6LR is 562 free to use the default Instance (zero) for the registered address or 563 to select an Instance of its choice; else, that is if the 6LR 564 participates to the suggested Instance, then the 6LR SHOULD use that 565 Instance for the registered address. 567 Upon a successful NS/NA(EARO) exchange: if the 'R' flag was set in 568 the EARO of the NS message, then the 6LR SHOULD inject the Registered 569 Address in RPL by sending a DAO message on behalf of the 6LN; else 570 the 6LR MUST NOT inject the Registered Address into RPL. 572 The DAO message advertising the Registered Address MUST be 573 constructed as follows: 575 o The Registered Address is placed in a RPL Target Option in the DAO 576 message as the Target Prefix, and the Prefix Length is set to 128 578 o the External 'E' flag in the Transit Information Option (TIO) 579 associated to the Target Option is set to indicate that the 6LR 580 redistributes an external target into the RPL network. This is 581 how the Root knows in Non-Storing Mode to use IP-in-IP and 582 terminate the outters headers at the 6LR that generated the DAO. 584 o the Path Lifetime in the TIO is computed from the Lifetime in the 585 EARO Option to adapt it to the Lifetime Units used in the RPL 586 operation. Note that if the lifetime is 0, then the 6LR generates 587 a No-Path DAO message that cleans up the routes down to the 588 Address of the 6LN. 590 o the Path Sequence in the TIO is set to the TID value found in the 591 EARO option. 593 o Additionally, in Non-Storing Mode the 6LR indicates one of its 594 global IPv6 unicast addresses as the Parent Address in the TIO. 596 If a 6LR receives a valid NS(EARO) message with the 'R' flag reset 597 and the 6LR was redistributing the Registered Address due to previous 598 NS(EARO) messages with the flag set, then it MUST stop injecting the 599 address. It is up to the Registering Node to maintain the 600 corresponding route from then on, either keeping it active by sending 601 further DAO messages, or destroying it using a No-Path DAO. 603 7.4. RPL Root Operation 605 In RPL Storing Mode of Operation (MOP), the DAO message is propagated 606 from child to parent all the way to the Root along the DODAG, 607 populating routing state as it goes. In Non-Storing Mode, The DAO 608 message is sent directly to the route. Upon reception of a DAO 609 message that creates or updates an existing RPL state: 611 o the Root notifies the 6LBR using an internal API if they are 612 collocated, or performs a keep-alive DAR/DAC exchange on behalf of 613 the registering node if they are separated. 615 o In an extended topology with a Backbone Link, the Root notifies 616 the 6LBR by proxying a keep-alive NS(EARO) on behalf of the 6LN 617 that owns the address indicated in the Target Option. 619 The keep-alive EDAR and the NS(EARO) messages MUST be constructed as 620 follows: 622 o The Target IPv6 address from in the RPL Target Option is placed in 623 the Registered Address field of the EDAR message and in the Target 624 field of the NS message, respectively 626 o the ROVR field in the keep-alive EDAR is set to 64-bits of all 627 ones to indicate that it is not provided and this is a keep-alive 628 EDAR. The actual value of the ROVR for that registration is 629 returned by the 6LBR in an EDAC, and used in the proxy NS(EARO). 631 o the Registration Lifetime is adapted from the Path Lifetime in the 632 TIO by converting the Lifetime Units used in RPL into units of 60 633 seconds used in the 6LoWPAN ND messages. 635 o The RPL Root indicates its own MAC Address as Source Link Layer 636 Address (SLLA) in the NS(EARO). 638 o the TID value is set to the Path Sequence in the TIO. The 'T' 639 flag and an ICMP code of 1 are used in the NS(EARO) and the DAR 640 message, respectively. 642 Upon a status in a DAC message that is not "Success", the Root MAY 643 destroy the formed paths using a No-Path DAO downwards as specified 644 in [I-D.ietf-roll-efficient-npdao]. 646 In Non-Storing Mode, the outer IPv6 header that is used by the Root 647 to transport the source routing information in data packets down the 648 DODAG has the 6LR that serves the 6LN as final destination. This 649 way, when the final 6LR decapsulates the outer header, it also 650 removes all the RPL artifacts from the packet. 652 7.5. 6LBR Operation 654 Upon reception of a DAR message with the Owner Unique ID field is set 655 to all ones, the 6LBR checks whether an entry exists for the and 656 computes whether the TID in the DAR message is fresher than that in 657 the entry as prescribed in section 4.2.1. of [RFC8505]. 659 If the entry does not exist, the 6LBR does not create the entry, and 660 answers with a Status "Removed" in the DAC message. 662 If the entry exists but is not fresher, the 6LBR does not update the 663 entry, and answers with a Status "Success" in the DAC message. 665 If the entry exists and the TID in the DAR message is fresher, the 666 6LBR updates the TID in the entry, and if the lifetime of the entry 667 is extended by the Registration Lifetime in the DAR message, it also 668 updates the lifetime of the entry. In that case, the 6LBR replies 669 with a Status "Success" in the DAC message. 671 8. Protocol Operations for Multicast Addresses 673 Section 12 of [RFC6550] details the RPL support for multicast flows. 674 This support is not source-specific and only operates as an extension 675 to the Storing Mode of Operation for unicast packets. Note that it 676 is the RPL model that the multicast packet is passed as a Layer-2 677 unicast to each if the interested children. This remains true when 678 forwarding between the 6LR and the listener 6LN. 680 "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its 681 updated version "Multicast Listener Discovery Version 2 (MLDv2) for 682 IPv6" [RFC3810] provide an interface for a listener to register to 683 multicast flows. MLDv2 is backwards compatible with MLD, and adds in 684 particular the capability to filter the sources via black lists and 685 white lists. In the MLD model, the router is a "querier" and the 686 host is a multicast listener that registers to the querier to obtain 687 copies of the particular flows it is interested in. 689 On the first registration, as illustrated in Figure 4, the 6LN, as an 690 MLD listener, sends an unsolicited Report to the 6LR in order to 691 start receiving the flow immediately. Since multicast Layer-2 692 messages are avoided, it is important that the asynchronous messages 693 for unsolicited Report and Done are sent reliably, for instance using 694 an Layer-2 acknoledgement, or attempted multiple times. 696 The 6LR acts as a generic MLD querier and generates a DAO for the 697 multicast target. The lifetime of the DAO is set to be in the order 698 of the Query Interval, yet larger to account for variable propagation 699 delays. 701 The Root proxies the MLD echange as listener with the 6BBR acting as 702 the querier, so as to get packets from a source external to the RPL 703 domain. Upon a DAO with a multicast target, the RPL Root checks if 704 it is already registered as a listener for that address, and if not, 705 it performs its own unsolicited Report for the multicast target. 707 6LN 6LR Root 6LBR 708 | | | | 709 | unsolicited Report | | | 710 |------------------->| | | 711 | | | | 712 | | DAO | | 713 | |-------------->| | 714 | | DAO ACK | | 715 | |<--------------| | 716 | | | | 717 | | | unsolicited Report | 718 | | |------------------->| 719 | | | | 720 | | | | 722 Figure 4: First Multicast Registration Flow 724 A re-registration is pulled by 6LR acting as querier. Note that the 725 message may sent unicast to all the known individual listeners. Upon 726 a time out of the Query Interval, the 6LR sends a Query to each of 727 its listeners, and gets a Report back that is mapped into a DAO, as 728 illustrated in Figure 5, 730 6LN 6LR Root 6LBR 731 | | | | 732 | Query | | | 733 |<-------------------| | | 734 | Report | | | 735 |------------------->| | | 736 | | DAO | | 737 | |-------------->| | 738 | | DAO ACK | | 739 | |<--------------| | 740 | | | | 741 | | | Query | 742 | | |<-------------------| 743 | | | Report | 744 | | |------------------->| 745 | | | | 746 | | | | 748 Figure 5: Next Registration Flow 750 Note that any of the functions 6LR, Root and 6LBR might be collapsed 751 in a single node, in which case the flow above happens internally, 752 and possibly through internal API calls as opposed to messaging. 754 9. Implementation Status 756 10. Security Considerations 758 The LLN nodes depend on the 6LBR and the RPL participants for their 759 operation. A trust model must be put in place to ensure that the 760 right devices are acting in these roles, so as to avoid threats such 761 as black-holing, or bombing attack whereby an impersonated 6LBR would 762 destroy state in the network by using the "Removed" Status code. 763 This trust model could be at a minimum based on a Layer-2 access 764 control, or could provide role validation as well. This is a generic 765 6LoWPAN requirement, see Req5.1 in Appendix of [RFC8505]. 767 The keep-alive EDAR message does not carry a valid Registration 768 Unique ID [RFC8505] and it cannot be used to create a binding state 769 in the 6LBR. The 6LBR MUST NOT create an entry based on a keep-alive 770 EDAR that does not match an existing entry. All it can do is refresh 771 the lifetime and the TID of an existing entry. 773 11. IANA Considerations 775 This specification has no requirement on IANA. 777 12. Acknowledgments 779 The author wishes to thank Michael Richardson and Georgios 780 Papadopoulos for their early reviews of and contributions to this 781 document 783 13. References 785 13.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 793 Listener Discovery (MLD) for IPv6", RFC 2710, 794 DOI 10.17487/RFC2710, October 1999, 795 . 797 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 798 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 799 DOI 10.17487/RFC3810, June 2004, 800 . 802 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 803 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 804 DOI 10.17487/RFC4861, September 2007, 805 . 807 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 808 Address Autoconfiguration", RFC 4862, 809 DOI 10.17487/RFC4862, September 2007, 810 . 812 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 813 over Low-Power Wireless Personal Area Networks (6LoWPANs): 814 Overview, Assumptions, Problem Statement, and Goals", 815 RFC 4919, DOI 10.17487/RFC4919, August 2007, 816 . 818 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 819 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 820 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 821 Low-Power and Lossy Networks", RFC 6550, 822 DOI 10.17487/RFC6550, March 2012, 823 . 825 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 826 Power and Lossy Networks (RPL) Option for Carrying RPL 827 Information in Data-Plane Datagrams", RFC 6553, 828 DOI 10.17487/RFC6553, March 2012, 829 . 831 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 832 Statement and Requirements for IPv6 over Low-Power 833 Wireless Personal Area Network (6LoWPAN) Routing", 834 RFC 6606, DOI 10.17487/RFC6606, May 2012, 835 . 837 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 838 Bormann, "Neighbor Discovery Optimization for IPv6 over 839 Low-Power Wireless Personal Area Networks (6LoWPANs)", 840 RFC 6775, DOI 10.17487/RFC6775, November 2012, 841 . 843 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 844 "IPv6 over Low-Power Wireless Personal Area Network 845 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 846 April 2017, . 848 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 849 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 850 May 2017, . 852 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 853 (IPv6) Specification", STD 86, RFC 8200, 854 DOI 10.17487/RFC8200, July 2017, 855 . 857 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 858 Perkins, "Registration Extensions for IPv6 over Low-Power 859 Wireless Personal Area Network (6LoWPAN) Neighbor 860 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 861 . 863 13.2. Informative References 865 [I-D.ietf-roll-efficient-npdao] 866 Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient 867 Route Invalidation", draft-ietf-roll-efficient-npdao-13 868 (work in progress), June 2019. 870 [I-D.ietf-roll-useofrplinfo] 871 Robles, I., Richardson, M., and P. Thubert, "Using RPL 872 Option Type, Routing Header for Source Routes and IPv6-in- 873 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 874 roll-useofrplinfo-30 (work in progress), June 2019. 876 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 877 C., and M. Carney, "Dynamic Host Configuration Protocol 878 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 879 2003, . 881 [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, 882 Ed., "Performance Evaluation of the Routing Protocol for 883 Low-Power and Lossy Networks (RPL)", RFC 6687, 884 DOI 10.17487/RFC6687, October 2012, 885 . 887 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 888 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 889 2014, . 891 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 892 Constrained-Node Networks", RFC 7228, 893 DOI 10.17487/RFC7228, May 2014, 894 . 896 Author's Address 898 Pascal Thubert (editor) 899 Cisco Systems, Inc 900 Building D 901 45 Allee des Ormes - BP1200 902 MOUGINS - Sophia Antipolis 06254 903 FRANCE 905 Phone: +33 497 23 26 34 906 Email: pthubert@cisco.com