idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to directly say this. It does mention RFC6550 though, so this could be OK. -- The draft header indicates that this document updates RFC8505, but the abstract doesn't seem to directly say this. It does mention RFC8505 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2019) is 1692 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) == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 == Outdated reference: A later version (-18) exists of draft-ietf-roll-efficient-npdao-16 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-31 ** Downref: Normative reference to an Informational RFC: RFC 4919 ** Downref: Normative reference to an Informational RFC: RFC 6606 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 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) M. Richardson 5 Intended status: Standards Track Sandelman 6 Expires: March 12, 2020 September 9, 2019 8 Routing for RPL Leaves 9 draft-ietf-roll-unaware-leaves-04 11 Abstract 13 This specification extends RFC6550 and RFC8505 to provide unicast and 14 multicast routing services in a RPL domain to 6LNs that are plain 15 hosts and do not 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 March 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 3.1. RFC 6775 . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. RFC 8505 Extended ARO . . . . . . . . . . . . . . . . . . 7 59 3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8 61 3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9 63 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 10 65 6. 6LN Requirements to be a RPL-Unware Leaf . . . . . . . . . . 10 66 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 10 67 6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 11 68 6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 11 69 6.2.2. Support of the Routing Header . . . . . . . . . . . . 11 70 6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 12 71 7. Updated RPL Target option . . . . . . . . . . . . . . . . . . 12 72 8. Protocol Operations for Unicast Addresses . . . . . . . . . . 13 73 8.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 14 75 8.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 16 76 8.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 17 78 8.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 18 79 8.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 20 80 8.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 21 81 9. Protocol Operations for Multicast Addresses . . . . . . . . . 21 82 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 12.1. RPL Target Option Flags . . . . . . . . . . . . . . . . 24 86 12.2. New Subsubregistry for the Status values of the RPL DAO- 87 ACK Message . . . . . . . . . . . . . . . . . . . . . . 24 88 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 91 14.2. Informative References . . . . . . . . . . . . . . . . . 28 92 Appendix A. Example Compression . . . . . . . . . . . . . . . . 29 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 95 1. Introduction 97 The design of Low Power and Lossy Networks (LLNs) is generally 98 focused on saving energy, which is the most constrained resource of 99 all. Other design constraints, such as a limited memory capacity, 100 duty cycling of the LLN devices and low-power lossy transmissions, 101 derive from that primary concern. 103 The IETF produced the "Routing Protocol for Low Power and Lossy 104 Networks" [RFC6550] (RPL) to provide IPv6 [RFC8200] routing services 105 within such constraints. RPL is a Distance-Vector protocol, which, 106 compared to link-state protocols, limits the amount of topological 107 knowledge that needs to be installed and maintained in each node. In 108 order to operate in constrained networks, RPL allows a Routing 109 Stretch (see [RFC6687]), whereby routing is only performed along a 110 DODAG as opposed to straight along a shortest path between 2 peers, 111 whatever that would mean in a given LLN. This trades the quality of 112 peer-to-peer (P2P) paths for a vastly reduced amount of control 113 traffic and routing state that would be required to operate a any-to- 114 any shortest path protocol. Finally, broken routes may be fixed 115 lazily and on-demand, based on dataplane inconsistency discovery, 116 which avoids wasting energy in the proactive repair of unused paths. 118 In order to cope with lossy transmissions, RPL forms Direction- 119 Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information 120 Solicitation (DIS) and DODAG Information Object (DIO) messages. For 121 most of the nodes, though not all, a DODAG provides multiple 122 forwarding solutions towards the Root of the topology via so-called 123 parents. RPL is designed to adapt to fuzzy connectivity, whereby the 124 physical topology cannot be expected to reach a stable state, with a 125 lazy control that creates routes proactively but only fixes them when 126 they are used by actual traffic. The result is that RPL provides 127 reachability for most of the LLN nodes, most of the time, but may not 128 really converge in the classical sense. RPL provides unicast and 129 multicast routing services back to RPL-Aware nodes (RANs). A RAN 130 will inject routes to itself using Destination Advertisement Object 131 (DAO) messages sent to either parent-nodes in Storing Mode or to the 132 Root indicating their parent in Non-Storing Mode. This process 133 effectively forms a DODAG back to the device that is a subset of the 134 DODAG to the Root with all links reversed. 136 When a routing protocol such as RPL is used to maintain reachability 137 within a Non-Broadcast Multi-Access (NBMA) subnet, some nodes may act 138 as routers and participate to the routing operations whereas others 139 may be plain hosts. In [RFC6550] terms, a host that is reachable 140 over the RPL network is called a Leaf. 142 "When to use RFC 6553, 6554 and IPv6-in-IPv6" 143 [I-D.ietf-roll-useofrplinfo] introduces the term RPL-Aware-Leaf (RAL) 144 for a leaf that injects routes in RPL to manage the reachability of 145 its own IPv6 addresses. In contrast, a RPL-Unaware Leaf (RUL) 146 designates a leaf does not participate to RPL at all. In that case, 147 the 6LN is a plain host that needs an interface to its RPL router to 148 obtain routing services over the LLN. This specification enables a 149 RPL-Unaware Leaf (RUL) to announce itself as a host and request that 150 6LRs that accept the registration also inject the relevant routing 151 information for the Registered Address in the RPL domain on its 152 behalf. The unicast packet forwarding operation by the 6LR serving a 153 Leaf 6LN is described in [I-D.ietf-roll-useofrplinfo]. 155 Examples of routing-agnostic 6LN may include lightly-powered sensors 156 such as window smash sensor (alarm system), or the kinetically 157 powered light switch. Other application of this specification may 158 include a smart grid network that controls appliances - such as 159 washing machines or the heating system - in the home. Applicances 160 may not participate to the RPL protocol operated in the smart grid 161 network but can still receive control packet from the smart grid. 163 2. Terminology 165 2.1. BCP 14 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119][RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 2.2. References 175 The Terminology used in this document is consistent with and 176 incorporates that described in Terms Used in Routing for Low-Power 177 and Lossy Networks (LLNs). [RFC7102]. 179 A glossary of classical 6LoWPAN acronyms is given in Section 2.3. 181 The term "byte" is used in its now customary sense as a synonym for 182 "octet". 184 "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by 185 a RPLInstanceID)are defined in "RPL: IPv6 Routing Protocol for Low- 186 Power and Lossy Networks" [RFC6550] . The DODAG Information 187 Solicitation (DIS), Destination Advertisement Object (DAO) and DODAG 188 Information Object (DIO) messages are also specified in [RFC6550]. 190 The Destination Cleanup Object (DCO) message is defined in 191 [I-D.ietf-roll-efficient-npdao]. 193 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 194 Leaf (RAL) consistently with [I-D.ietf-roll-useofrplinfo]. The term 195 RPL-Aware Node (RAN) is introduced to refer to a node that is either 196 a RAL or a RPL router. As opposed to a RUL, a RAN manages the 197 reachability of its addresses and prefixes by injecting them in RPL 198 by itself. 200 Other terms in use in LLNs are found in Terminology for Constrained- 201 Node Networks [RFC7228]. 203 Readers are expected to be familiar with all the terms and concepts 204 that are discussed in 206 o "Neighbor Discovery for IP version 6" [RFC4861], 208 o "IPv6 Stateless Address Autoconfiguration" [RFC4862], 210 o "Problem Statement and Requirements for IPv6 over Low-Power 211 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], 213 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 214 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 216 o "Neighbor Discovery Optimization for Low-power and Lossy Networks" 217 [RFC6775], and 219 o "Registration Extensions for IPv6 over Low-Power Wireless Personal 220 Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]. 222 2.3. Glossary 224 This document often uses the following acronyms: 226 AR: Address Resolution (aka Address Lookup) 228 6LBR: 6LoWPAN Border Router 230 6LN: 6LoWPAN Node (a Low Power host or router) 232 6LR: 6LoWPAN Router 234 6CIO: Capability Indication Option 236 (E)ARO: (Extended) Address Registration Option 237 (E)DAR: (Extended) Duplicate Address Request 239 (E)DAC: (Extended) Duplicate Address Confirmation 241 DAD: Duplicate Address Detection 243 DAO: Destination Advertisement Object 245 DCO: Destination Cleanup Object 247 DIS: DODAG Information Solicitation 249 DIO: DODAG Information Object 251 DODAG: Destination-Oriented Directed Acyclic Graph 253 LLN: Low-Power and Lossy Network 255 NA: Neighbor Advertisement 257 NCE: Neighbor Cache Entry 259 ND: Neighbor Discovery 261 NDP: Neighbor Discovery Protocol 263 NS: Neighbor Solicitation 265 RA: Router Advertisement 267 ROVR: Registration Ownership Verifier 269 RPI: RPL Packet Information (an Option in the Hop-By_Hop Header) 271 RAL: RPL-Aware Leaf 273 RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) 275 RUL: RPL-Unaware Leaf 277 TID: Transaction ID (a sequence counter in the EARO) 279 3. 6LoWPAN Neighbor Discovery 280 3.1. RFC 6775 282 The "IPv6 Neighbor Discovery (IPv6 ND) Protocol" (NDP) suite 283 [RFC4861] [RFC4862] was defined for transit media such a Ethernet, 284 and relies heavily on multicast operations for address discovery and 285 duplicate address detection (DAD). 287 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 288 (6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained 289 LLNs. In particular, 6LoWPAN ND introduces a unicast host address 290 registration mechanism that contributes to reducing the use of 291 multicast messages that are present in the classical IPv6 ND 292 protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) 293 that is carried in the unicast Neighbor Solicitation (NS) and 294 Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) 295 and the 6LoWPAN Router (6LR). 297 6LoWPAN ND also defines the Duplicate Address Request (DAR) and 298 Duplicate Address Confirmation (DAC) messages between the 6LR and the 299 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the central 300 repository of all the Registered Addresses in its domain. 302 The main functions of [RFC6775] are to proactively establish the 303 Neighbor Cache Entry in the 6LR and to avoid address duplication. 304 There is no concept of registering the address for an external 305 service such as RPL routing. That feature is introduced with 306 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]. 308 3.2. RFC 8505 Extended ARO 310 [RFC8505] updates the behavior of RFC 6775 to enable a generic 311 registration to services such as routing, and defines an Extended ARO 312 (EARO). The format of the EARO is shown in Figure 1: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | Status | Opaque | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Rsvd | I |R|T| TID | Registration Lifetime | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 ... Registration Ownership Verifier ... 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 1: EARO Option Format 328 3.2.1. R Flag 330 [RFC8505] introduces the R flag in the EARO. The Registering Node 331 sets the R flag to indicate whether the 6LR should ensure 332 reachability for the Registered Address, e.g., by means of routing or 333 proxying ND. If the R flag is not set, then the Registering Node is 334 expected to be a RAN that handles the reachability of the Registered 335 Address by itself. 337 This document specifies how the R flag is used in the context of RPL. 338 A 6LN operates as a RUL for an IPv6 address iff it sets the R flag in 339 the NS(EARO) used to register the address. The RPL router generates 340 a DAO message for the Registered Address upon an NS(EARO) iff the R 341 flag in the EARO is set. Conversely, this document specifies a 342 behavior of a RPL router acting as 6LR for the registration 6LR that 343 depends on the setting of the R flag in the NS(EARO). 345 3.2.2. TID, I Field and Opaque Fields 347 The EARO also includes a sequence counter called Transaction ID 348 (TID), which maps to the Path Sequence Field found in Transit Options 349 in RPL DAO messages. This is the reason why the support of [RFC8505] 350 by the RUL as opposed to only [RFC6775] is a prerequisite for this 351 specification (more in Section 6.1). The EARO also transports an 352 Opaque field and an "I" field that describes what the Opaque field 353 transports and how to use it. Section 8.2.1 specifies the use of the 354 "I" field and of the Opaque field by a RUL. 356 3.2.3. ROVR 358 Section 5.3. of [RFC8505] introduces the Registration Ownership 359 Verifier (ROVR) field of a variable length from 64 to 256 bits. The 360 ROVR is a replacement of the EUI-64 field in the ARO [RFC6775] that 361 was used to identify uniquely a registration based on the Link-Layer 362 address of the owner but provided no protection against spoofing. 364 "Address Protected Neighbor Discovery for Low-power and Lossy 365 Networks" [I-D.ietf-6lo-ap-nd] leverages the ROVR field as a 366 cryptographic proof of ownership to prevent a rogue third party from 367 misusing the address. [I-D.ietf-6lo-ap-nd] adds a challenge/response 368 exchange to the [RFC8505] registration and enables Source Address 369 Validation by a 6LR that will drop packets with a spoofed address. 371 This specification does not address how the protection by 372 [I-D.ietf-6lo-ap-nd] could be extended to RPL. On the other hand, it 373 adds the ROVR to the DAO to build the proxied EDAR at the Root, which 374 means that nodes that are aware of the host route to the 6LN are now 375 aware of the associated ROVR as well. 377 3.3. RFC 8505 Extended DAR/DAC 379 [RFC8505] updates the periodic DAR/DAC exchange that takes place 380 between the 6LR and the 6LBR using Extended DAR/DAC messages. The 381 Extended Duplicate Address messages can carry the ROVR field of 382 variable size. The periodic EDAR/EDAC exchange is triggered by a 383 NS(EARO) message and is intended to create and then refresh the 384 corresponding state in the 6LBR for a lifetime that is indicated by 385 the 6LN. Conversely, RPL [RFC6550] specifies a periodic DAO from the 386 6LN all the way to the Root that maintains the routing state in the 387 RPL network for a lifetime that is indicated by the source of the 388 DAO. This means that there are two periodic messages that traverse 389 the whole network to indicate that an address is still reachable, one 390 to the Root and one to the 6LBR. This represents a waste of 391 bandwidth and energy that can be undesirable in an LLN. 393 This specification saves the support of RPL in a 6LN called a RUL and 394 avoids an extraneous periodic flow across the LLN. The RUL only 395 needs to perform a [RFC8505] registration to the 6LR. The 6LR turns 396 it into a DAO message to the Root on behalf of the RUL. Upon the new 397 DAO, the Root proxies the EDAR exchange to the 6LBR on behalf of the 398 6LR. This is illustrated in Figure 4. 400 4. Updating RFC 6550 402 This document specifies a new behavior whereby a 6LR injects DAO 403 messages for unicast addresses (see Section 8) and multicast 404 addresses (see Section 9) on behalf of leaves that are not aware of 405 RPL. The Targets are exposed as External addresses. An IP-in-IP 406 encapsulation that terminates at the border 6LR is used to remove RPL 407 artifacts and compression techniques that may not be processed 408 correctly outside of the RPL domain. 410 This document synchronizes the liveness monitoring at the Root and 411 the 6LBR. A same value of lifetime is used for both, and a single 412 keep alive message, the RPL DAO, traverses the RPL network. A new 413 behavior is introduced whereby the RPL Root proxies the EDAR message 414 to the 6LBR on behalf of the 6LR (more in Section 5). [RFC6550] is 415 updated with new RPL Status values for use in DAO-ACK and DCO that 416 map the 6LoWPAN ND values defined in Table 1 of [RFC8505]. The 417 resulting set is shown in Table 1. 419 Section 6.7. of [RFC6550] introduces the RPL Control Message Options 420 such as the RPL Target Option that can be included in a RPL Control 421 Message such as the DAO. Section 7 updates the RPL Target Option to 422 optionally transport the ROVR used in the IPv6 Registration (see 423 Section 3.2.3) so the RPL Root can generate a full EDAR Message. 425 5. Updating RFC 8505 427 This document updates [RFC8505] to introduce a keep-alive EDAR 428 message and a keep-alive NS(EARO) message. The keep-alive messages 429 are used for backward compatibility, when the DAO does not transport 430 a ROVR as specified in Section 7. The keep-alive messages have a 431 zero ROVR field and can only be used to refresh a pre-existing state 432 associated to the Registered Address. More specifically, a keep- 433 alive message can only increase the lifetime and/or increment the TID 434 of the existing state in a 6LBR. 436 Upon the renewal of a 6LoWPAN ND registration, this specification 437 changes the behavior of a RPL router acting as 6LR for the 438 registration as follows. If the Root indicates the capability to 439 proxy the EDAR/EDAC exchange to the 6LBR then the 6LR refrains from 440 sending an EDAR message; if the Root is separated from the 6LBR, the 441 Root regenerates the EDAR message to the 6LBR upon a DAO message that 442 signals the liveliness of the Address. 444 6. 6LN Requirements to be a RPL-Unware Leaf 446 This document provides RPL routing for a RUL, that is a 6LN acting as 447 a plain host and not aware of RPL. Still, a minimal RPL-independent 448 functionality is expected from the 6LN in order to obtain routing 449 services from the 6LR. 451 6.1. Support of 6LoWPAN ND 453 A RUL MUST implement [RFC8505] and set the R flag in the EARO option. 454 A 6LN is considered to be a RUL if and only if it sets the R flag in 455 the EARO. 457 A RUL MUST register to all the 6LRs from which it expects to get 458 routing services. The registrations SHOULD be performed in a rapid 459 sequence, using the exact same EARO for a same Address. Gaps between 460 the registrations will invalidate some of the routes till the 461 registration finally shows on those routes as well. 463 [RFC8505] introduces error Status values in the NA(EARO) which can be 464 received synchronously upon an NS(EARO) or asynchronously. The RUL 465 MUST support both cases and refrain from using the Registered Address 466 as specified by [RFC8505] depending on the Status value. 468 A RUL SHOULD support [I-D.ietf-6lo-ap-nd] to protect the ownership of 469 its addresses. 471 6.2. External Routes and RPL Artifacts 473 Section 4.1. of [I-D.ietf-roll-useofrplinfo] provides a set of rules 474 that MUST be followed when forwarding packets over an external route: 476 RPL data packets are often encapsulated using IP-in-IP and in Non- 477 Storing Mode, packets going down will carry an SRH as well. RPL data 478 packets also typically carry a Hop-by-Hop Header to transport a RPL 479 Packet Information (RPI) [RFC6550]. These additional headers are 480 called RPL artifacts. When IP-in-IP is used and the outer headers 481 terminate at a 6LR down the path (see Figure 8 for the compressed 482 format in Storing Mode), then the 6LR decapsulates the IP-in-IP and 483 the packet that is forwarded to the external destination is free of 484 RPL artifacts - but possibly an RPI if packet was generated by a RAN 485 in the same RPL domain as the destination RUL. 487 An IP-in-IP tunnel to a 6LR that injected the route is used for 488 external routes unless the final destination is known to handle or 489 ignore the RPL artifacts properly [RFC8200]. Non-Storing Mode 490 signaling is used to signal external routes to the Root, which 491 enables to advertise the tunnel endpoint. A RUL is an example of 492 target that is reachable via an external host route and is expected 493 to ignore the RPI and the consumed SRH artifacts. In the case of a 494 RUL, tunneling may not be necessary. 496 A RUL may not support IP-in-IP tunneling [RFC8504], so if IP-in-IP is 497 used, and unless the Root as a better knowledge, the tunnel should 498 terminate at the 6LR that injected the external route to the RUL. 500 Additionally, the RUL cannot be expected to support the compression 501 method defined in [RFC8138]. The 6LR that injected the route 502 uncompresses the packet before forwarding over an external route, 503 even when delivering to a RUL, even when it is not the destination of 504 the incoming packet. 506 6.2.1. Support of the HbH Header 508 A RUL is expected to process an unknown Option Type in a Hop-by-Hop 509 Header as prescribed by section 4.2 of [RFC8200]. This means in 510 particular that an RPI with an Option Type of 0x23 511 [I-D.ietf-roll-useofrplinfo] is ignored when not understood. 513 6.2.2. Support of the Routing Header 515 A RUL is expected to process an unknown Routing Header Type as 516 prescribed by section 4.4 of [RFC8200]. This means in particular 517 that Routing Header with a Routing Type of 3 [RFC6553] is ignored 518 when the Segments Left is zero, and dropped otherwise. 520 6.2.3. Support of IPv6 Encapsulation 522 Section 2.1 of [I-D.ietf-roll-useofrplinfo] sets the rules for 523 forwarding IP-in-IP either to the final 6LN or to a parent 6LR. In 524 order to enable IP-in-IP to the 6LN in Non-Storing Mode, the 6LN must 525 be able to decapsulate the tunneled packet and either drop the inner 526 packet if it is not the final destination, or pass it to the upper 527 layer for further processing. Unless it is aware that the RUL can 528 handle IP-in-IP properly, the Root that encapsulates a packet to a 529 RUL terminates the IP-in-IP tunnel at the parent 6LR . For that 530 reason, it is beneficial but not necessary for a RUL to support IP- 531 in-IP. 533 7. Updated RPL Target option 535 This specification updates the RPL Target option to transport the 536 ROVR as illustrated in Figure 2. This enables the RPL Root to 537 generate a full EDAR Message as opposed to a keep-alive EDAR that has 538 restricted properties. The Target Prefix MUST be aligned to the next 539 4-byte boundary after the size indicated by the Prefix Length. if 540 necessary it is padded with zeros. The size of the ROVR is indicated 541 in a new ROVR Type field that is encoded to map the CodePfx in the 542 EDAR message (see section 4.2 of [RFC8505]). With this specification 543 the ROVR is the remainder of the RPL Target Option. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type = 0x05 | Option Length |ROVRsz | Flags | Prefix Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | | 551 + + 552 | Target Prefix (Variable Length) | 553 . Aligned to 4-byte boundary . 554 . . 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 ... Registration Ownership Verifier (ROVR) ... 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 2: Updated Target Option 563 New fields: 565 RVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, 566 or 4, denoting a ROVR size of 64, 128, 192, or 256 567 bits, respectively. 569 Registration Ownership Verifier (ROVR): This is the same field as in 570 the EARO, see [RFC8505] 572 8. Protocol Operations for Unicast Addresses 574 8.1. General Flow 576 This specification enables to save the exchange of Extended Duplicate 577 Address messages, EDAR and EDAC, from a 6LN all the way to the 6LBR 578 across a RPL mesh, for the sole purpose of refreshing an existing 579 state in the 6LBR. Instead, the EDAR/EDAC exchange is proxied by the 580 RPL Root upon a DAO message that refreshes the RPL routing state. To 581 achieve this, the lifetimes and sequence counters in 6LoWPAN ND and 582 RPL are aligned. In other words, the Path Sequence and the Path 583 Lifetime in the DAO message are taken from the Transaction ID and the 584 registration lifetime in the NS(EARO) message from the 6LN. 586 In that flow, the RPL Root acts as a proxy to refresh the state in 587 the 6LBR. The proxy operation applies to both RUL and RAN. This 588 means that in a RPL network where the function is enabled, refreshing 589 the state in the 6LBR is the responsibility of the Root. 590 Consequently, only addresses that are injected in RPL will be kept 591 alive by the RPL Root. If an additional routing protocol is deployed 592 on a same network, that additional routing protocol may need to 593 handle the keep alive procedure for the addresses that it serves. 595 From the perspective of the 6LN, the registration flow happens 596 transparently; it is not delayed by the proxy RPL operation, so the 597 device does not need to change the amount of time it waits based upon 598 whether RPL proxy operation happens or not. 600 On the first registration, illustrated in Figure 3, from the 601 perspective of the 6LR in Non-Storing Mode, the Extended Duplicate 602 Address message takes place as prescribed by [RFC8505]. When 603 successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR, 604 and the 6LR injects the Registered Address in RPL using DAO/DAO-ACK 605 exchanges all the way to the RPL DODAG Root. The protocol does not 606 carry a specific information that the Extended Duplicate Address 607 messages were already exchanged, so the Root proxies them anyway. 609 Note that any of the functions 6LR, Root and 6LBR might be collapsed 610 in a single node, in which case the flow above happens internally, 611 and possibly through internal API calls as opposed to messaging. 613 8.1.1. In RPL Non-Storing-Mode 615 In Non-Storing Mode, the flows can be nested as illustrated in 616 Figure 3 and it is possible to carry information such as an updated 617 lifetime from the 6LBR all the way to the 6LN. 619 6LN 6LR Root 6LBR 620 | | | | 621 | NS(EARO) | | | 622 |--------------->| | 623 | | Extended DAR | 624 | |-------------------------------->| 625 | | | 626 | | Extended DAC | 627 | |<--------------------------------| 628 | | DAO | | 629 | |-------------->| | 630 | | | keep-alive EDAR | 631 | | |---------------->| 632 | | | EDAC | 633 | | |<----------------| 634 | | DAO-ACK | | 635 | |<--------------| | 636 | NA(EARO) | | 637 |<---------------| | | 638 | | | | 639 (in case if an Error not reported in DAO-ACK) 640 | | | | 641 | | DCO | | 642 | |<--------------| | 643 | NA(EARO) | | | 644 |<---------------| | | 645 | | | | 647 Figure 3: First Registration Flow in Non-Storing Mode 649 A re-registration is performed by the 6LN to maintain the NCE in the 650 6LR alive before lifetime expires. Upon a re-registration, as 651 illustrated in Figure 4, the 6LR redistributes the Registered Address 652 NS(EARO) in RPL. 654 This causes the RPL DODAG Root to refresh the state in the 6LBR with 655 a keep-alive EDAC message. The keep-alive EDAC lacks the 656 Registration Ownership Verifier (ROVR) information, since it is not 657 present in RPL DAO messages, but the EDAC message sent in response by 658 the 6LBR contains the actual value of the ROVR field for that 659 registration. 661 6LN 6LR Root 6LBR 662 | | | | 663 | | | | 664 | NS(EARO) | | | 665 |--------------->| | | 666 | | DAO | | 667 | |-------------->| | 668 | | | keep-alive EDAR | 669 | | |---------------->| 670 | | | EDAC | 671 | | |<----------------| 672 | | DAO-ACK | | 673 | |<--------------| | 674 | NA(EARO) | | 675 |<---------------| | | 676 | | | | 677 | | | | 679 Figure 4: Next Registration Flow in Non-Storing Mode 681 In case of an error on the keep-alive EDAR flow, the error SHOULD be 682 returned in the DAO-ACK - if one was requested - using the mapping of 683 RPL Status and 6LoWPAN Status values discussed in Section 4. 685 If the Root could not return the negative Status in the DAO-ACK then 686 it sends an asynchronous Destination Cleanup Object (DCO) message 687 [I-D.ietf-roll-efficient-npdao] to the 6LR indicating the issue with 688 the mapped Status value. Note that if both are used in a short 689 interval of time, the DAO-ACK and DCO messages are not guaranteed to 690 arrive in the same order at the 6LR. So the 6LR must still expect a 691 DAO-ACK even if it received a DCO while it was waiting for an 692 acknowledgement for a short period of time, but the negative status 693 in the DCO supercedes a positive status in the DAO-ACK regardless of 694 the order in which they are received. 696 Upon the DAO-ACK - or the DCO if it arrives first - the 6LR responds 697 to the RUL with a NA(EARO) and the 6LoWPAN ND Status value that is 698 mapped from the RPL status in the RPL message. An asynchronous DCO 699 is also translated in an asynchronous NA(EARO) to the RUL with a 700 mapped Status value. The RPL Status values that are mapped with 701 6LoWPAN ND are in the range 128 to 192 and listed in the same order 702 (see Table 1). A RPL Status Value of 128 maps to 6LoWPAN ND Status 703 Code of 1 and so on. 705 8.1.2. In RPL Storing-Mode 707 In Storing Mode, the DAO-ACK is optional. When it is used, it is 708 generated by the RPL parent, which does not need to wait for the 709 grand-parent to send the acknowledgement. A successful DAO-ACK is 710 not a guarantee that the DAO has yet reached the Root or that the 711 keep-alive EDAR has succeeded. 713 If the keep alive fails, the path is cleaned up asynchronously using 714 a DCO message [I-D.ietf-roll-efficient-npdao] as illustrated in 715 Figure 5 and described in further details in Section 8.2.3. 717 6LN 6LR 6LR Root 6LBR 718 | | | | | 719 | NS(EARO) | | | | 720 |-------------->| | | | 721 | NA(EARO) | | | | 722 |<--------------| | | | 723 | | | | | 724 | | DAO | | | 725 | |-------------->| | | 726 | | DAO-ACK | | | 727 | |<--------------| | | 728 | | | | | 729 | | | DAO | | 730 | | |-------------->| | 731 | | | DAO-ACK | | 732 | | |<--------------| | 733 | | | | | 734 | | | | keep-alive EDAR | 735 | | | |---------------->| 736 | | | | EDAC(ROVR) | 737 | | | |<----------------| 738 | | | | | 739 (in case if an Error) 740 | | | | | 741 | | DCO | | 742 | |<------------------------------| | 743 | NA(EARO) | | | | 744 |<--------------| | | | 745 | | | | | 747 Figure 5: Next Registration Flow in Storing Mode 749 8.2. Operation 751 8.2.1. By the 6LN 753 This specification does not alter the operation of a 6LoWPAN ND- 754 compliant 6LN, and a RUL is expected to operate as follows: 756 o The 6LN obtains an IPv6 global address, for instance using 757 autoconfiguration [RFC4862] based on a Prefix Information Option 758 (PIO) [RFC4861] found in a Router Advertisement message or by some 759 other means such as DHCPv6 [RFC3315]. 761 o Once it has formed an address, the 6LN (re)registers its address 762 periodically, within the Lifetime of the previous registration, as 763 prescribed by [RFC6775]. 765 o A 6LN acting as a RUL sets the R flag in the EARO whereas a 6LN 766 acting as a RAN does not set the R flag as prescribed by [RFC8505] 767 section 5.1. 769 o Upon each consecutive registration, the 6LN increases the TID 770 field in the EARO, as prescribed by [RFC8505] section 5.2. 772 o The 6LN can register to more than one 6LR at the same time. In 773 that case, a same value of TID is used for each registration. 775 o The 6LN may use any of the 6LRs to which it register to forward 776 its packets. Using a 6LR to which the 6LN is not registered may 777 result in packets dropped by a Source Address Validation function. 779 Even without support for RPL, a RUL may be aware of opaque values to 780 be provided to the routing protocol. If the RUL has a knowledge of 781 the RPL Instance the packet should be injected into, then it SHOULD 782 set the Opaque field in the EARO to the RPLInstanceID, else it MUST 783 leave the Opaque field to zero. In any fashion the 6LN MUST set the 784 "I" field to zero to indicate that topological information to be 785 passed to a routing process as specified in [RFC8505] section 5.1. 787 A RUL is not expected to produce RPL artifacts in the data packets, 788 but it MAY do so. for instance, if the RUL has a minimal awareness of 789 the RPL Instance and can build an RPI. A RUL that places an RPI in a 790 data packet MUST indicate the RPLInstanceID that corresponds to the 791 RPL Instance the packet should be injected into. All the flags and 792 the Rank field are set to zero as specified by section 11.2 of 793 [RFC6550]. 795 8.2.2. By the 6LR 797 Also as prescribed by [RFC8505], the 6LR generates a DAR message upon 798 reception of a valid NS(EARO) message for the registration of a new 799 IPv6 Address by a 6LN. If the Duplicate Address exchange succeeds, 800 then the 6LR installs a Neighbor Cache Entry (NCE). If the R flag 801 was set in the EARO of the NS message, and this 6LR can manage the 802 reachability of Registered Address, then the 6LR sets the R flag in 803 the EARO of the NA message that is sent in response. 805 From then on, the 6LN periodically sends a new NS(EARO) to refresh 806 the NCE state before the lifetime indicated in the EARO expires, with 807 TID that is incremented each time till it wraps in a lollipop fashion 808 (see section 5.2.1 of [RFC8505] which is fully compatible with 809 section 7.2 of [RFC6550]). As long as the R flag is set and this 810 router can still manage the reachability of Registered Address, the 811 6LR keeps setting the R flag in the EARO of the response NA message, 812 but the exchange of Extended Duplicate Address messages is skipped. 814 The Opaque field in the EARO hints the 6LR on the RPL Instance that 815 should be used for the DAO advertisements, and for the forwarding of 816 packets sourced at the registered address when there is no RPL Packet 817 Information (RPI) in the packet, in which case the 6LR SHOULD add one 818 to the packet. if the "I" field is not zero, then the 6LR MUST 819 consider that the Opaque field is zero. If the Opaque field is not 820 set to zero, then it should carry a RPLInstanceID for the Instance 821 suggested by the 6LN. If the 6LR does not participate to the 822 associated Instance, then the 6LR MUST consider that the Opaque field 823 is empty. If the Opaque field is empty, the 6LR is free to use the 824 default Instance (zero) for the registered address or to select an 825 Instance of its choice; else, that is if the 6LR participates to the 826 suggested Instance, then the 6LR SHOULD use that Instance for the 827 registered address. 829 Upon a successful NS/NA(EARO) exchange: if the R flag was set in the 830 EARO of the NS message, then the 6LR SHOULD inject the Registered 831 Address in RPL by sending a DAO message on behalf of the 6LN; else 832 the 6LR MUST NOT inject the Registered Address into RPL. 834 The DAO message advertising the Registered Address MUST be 835 constructed as follows: 837 o The Registered Address is placed in a RPL Target Option in the DAO 838 message as the Target Prefix, and the Prefix Length is set to 128; 840 o the External 'E' flag in the Transit Information Option (TIO) 841 associated to the Target Option is set to indicate that the 6LR 842 redistributes an external target into the RPL network. When the 843 Root has to use an IP-in-IP [I-D.ietf-roll-useofrplinfo], then 844 this flag indicates the IP-in-IP should be addressed to this node; 846 o the Path Lifetime in the TIO is computed from the Lifetime in the 847 EARO Option to adapt it to the Lifetime Units used in the RPL 848 operation. Note that if the lifetime is 0, then the 6LR generates 849 a No-Path DAO message that cleans up the routes down to the 850 Address of the 6LN; 852 o the Path Sequence in the TIO is set to the TID value found in the 853 EARO option; 855 o Additionally, in Non-Storing Mode the 6LR indicates one of its 856 global IPv6 unicast addresses as the Parent Address in the TIO. 858 If a DAO-ACK is not requested, or has a Status that is less than 128, 859 indicating the DAO was accepted, respectively by a parent in Storing 860 Mode or by the Root in non-Storing Mode,, the 6LR replies with a 861 NA(EARO) to the RUL with a status of 0 (Success). 863 In case of a DAO-ACK or a DCO with a status of 132 (Validation 864 Requested) the 6LR challenges the 6LN for ownership of the address, 865 as described in section 6.1 of [RFC8505]. If the challenge succeeds 866 then the operations continue as normal. In particular a DAO message 867 is generated upon the NS(EARO) that proves the ownership of the 868 address. If the challenge failed the 6LR MUST refrain from injecting 869 the address in RPL and may take actions to protect itself against DoS 870 attacks by a rogue 6LN, see Section 11 872 Other status values above 128 indicate that the 6LR failed to inject 873 the address into the RPL network. In that case the the 6LR MUST send 874 a NA(EARO) to the RUL with the mapped Status value. If for any other 875 reason the 6LR fails to inject the address into the RPL network, the 876 6LR SHOULD send a NA(EARO) to the RUL with a status of 2 (Out of 877 Storage) which indicates a possibility to retry later. 879 If a 6LR receives a valid NS(EARO) message with the R flag reset and 880 the 6LR was redistributing the Registered Address due to previous 881 NS(EARO) messages with the flag set, then it MUST stop injecting the 882 address. It is up to the Registering Node to maintain the 883 corresponding route from then on, either keeping it active by sending 884 further DAO messages, or destroying it using a No-Path DAO. 886 Upon a DCO message indicating that the address of a RUL should be 887 removed from the routing table, the 6LR issues an asynchronous 888 NA(EARO) to the RUL with the mapped Status value. 890 8.2.3. By the RPL Root 892 In RPL Storing Mode of Operation (MOP), the DAO message is propagated 893 from child to parent all the way to the Root along the DODAG, 894 populating routing state as it goes. In Non-Storing Mode, The DAO 895 message is sent directly to the RPL Root. Upon reception of a DAO 896 message, for each RPL Target option that creates or updates an 897 existing RPL state: 899 o the Root notifies the 6LBR using an internal API if they are co- 900 located, or performs an EDAR/EDAC exchange on behalf of the 6LR if 901 they are separated. If the Target option transports a ROVR, then 902 the Root MUST use it to build a full EDAR message as the 6LR 903 would. Else, a keep-alive EDAR is used with the ROVR field set to 904 zero. 906 An EDAR message MUST be constructed as follows: 908 o The Target IPv6 address from in the RPL Target Option is placed in 909 the Registered Address field of the EDAR message and in the Target 910 field of the NS message, respectively; 912 o the Registration Lifetime is adapted from the Path Lifetime in the 913 TIO by converting the Lifetime Units used in RPL into units of 60 914 seconds used in the 6LoWPAN ND messages; 916 o the RPL Root indicates its own MAC Address as Source Link Layer 917 Address (SLLA) in the NS(EARO); 919 o the TID value is set to the Path Sequence in the TIO and indicated 920 with an ICMP code of 1 in the EDAR message; 922 o when present in the RPL Target option, the ROVR field is used as 923 is in the EDAR and the ICMP Code Suffix is set to the appropriate 924 value as shown in Table 4 of [RFC8505] depending on the length of 925 the ROVR field. If it is not present the ROVR field in the EDAR 926 is set to zero indicating that this is a keep-alive EDAR. The 927 actual value of the ROVR for that registration is expected from 928 the 6LBR in the response EDAC. 930 Upon a Status value in an EDAC message that is not "Success", the 931 Root SHOULD destroy the formed paths using either a DAO-ACK (in Non- 932 Storing Mode) or a DCO downwards as specified in 933 [I-D.ietf-roll-efficient-npdao]. Failure to destroy the former path 934 would result in Stale routing state and local black holes if the 935 address belongs to another party elsewhere in the network. The RPL 936 Status value that maps the 6LowpAN ND status value MUST be placed in 937 the DCO. 939 8.2.4. By the 6LBR 941 Upon reception of an EDAR message with the ROVR field is set to zero 942 indicating a keep-alive EDAR, the 6LBR checks whether an entry exists 943 for the and computes whether the TID in the DAR message is fresher 944 than that in the entry as prescribed in section 4.2.1. of [RFC8505]. 946 If the entry does not exist, the 6LBR does not create the entry, and 947 answers with a Status "Removed" in the EDAC message. 949 If the entry exists but is not fresher, the 6LBR does not update the 950 entry, and answers with a Status "Success" in the EDAC message. 952 If the entry exists and the TID in the DAR message is fresher, the 953 6LBR updates the TID in the entry, and if the lifetime of the entry 954 is extended by the Registration Lifetime in the DAR message, it also 955 updates the lifetime of the entry. In that case, the 6LBR replies 956 with a Status "Success" in the DAC message. 958 The EDAC that is constructed is the same as if the keep-alive EDAR 959 was a full EDAR, and includes the ROVR that is associated to the 960 registration. 962 9. Protocol Operations for Multicast Addresses 964 Section 12 of [RFC6550] details the RPL support for multicast flows. 965 This support is not source-specific and only operates as an extension 966 to the Storing Mode of Operation for unicast packets. Note that it 967 is the RPL model that the multicast packet is passed as a Layer-2 968 unicast to each if the interested children. This remains true when 969 forwarding between the 6LR and the listener 6LN. 971 "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its 972 updated version "Multicast Listener Discovery Version 2 (MLDv2) for 973 IPv6" [RFC3810] provide an interface for a listener to register to 974 multicast flows. MLDv2 is backwards compatible with MLD, and adds in 975 particular the capability to filter the sources via black lists and 976 white lists. In the MLD model, the router is a "querier" and the 977 host is a multicast listener that registers to the querier to obtain 978 copies of the particular flows it is interested in. 980 On the first registration, as illustrated in Figure 6, the 6LN, as an 981 MLD listener, sends an unsolicited Report to the 6LR in order to 982 start receiving the flow immediately. Since multicast Layer-2 983 messages are avoided, it is important that the asynchronous messages 984 for unsolicited Report and Done are sent reliably, for instance using 985 an Layer-2 acknoledgement, or attempted multiple times. 987 The 6LR acts as a generic MLD querier and generates a DAO for the 988 multicast target. The lifetime of the DAO is set to be in the order 989 of the Query Interval, yet larger to account for variable propagation 990 delays. 992 The Root proxies the MLD echange as listener with the 6LBR acting as 993 the querier, so as to get packets from a source external to the RPL 994 domain. Upon a DAO with a multicast target, the RPL Root checks if 995 it is already registered as a listener for that address, and if not, 996 it performs its own unsolicited Report for the multicast target. 998 6LN 6LR Root 6LBR 999 | | | | 1000 | unsolicited Report | | | 1001 |------------------->| | | 1002 | | | | 1003 | | DAO | | 1004 | |-------------->| | 1005 | | DAO-ACK | | 1006 | |<--------------| | 1007 | | | | 1008 | | | unsolicited Report | 1009 | | |------------------->| 1010 | | | | 1011 | | | | 1013 Figure 6: First Multicast Registration Flow 1015 A re-registration is pulled by 6LR acting as querier. Note that the 1016 message may sent unicast to all the known individual listeners. Upon 1017 a time out of the Query Interval, the 6LR sends a Query to each of 1018 its listeners, and gets a Report back that is mapped into a DAO, as 1019 illustrated in Figure 7, 1020 6LN 6LR Root 6LBR 1021 | | | | 1022 | Query | | | 1023 |<-------------------| | | 1024 | Report | | | 1025 |------------------->| | | 1026 | | DAO | | 1027 | |-------------->| | 1028 | | DAO-ACK | | 1029 | |<--------------| | 1030 | | | | 1031 | | | Query | 1032 | | |<-------------------| 1033 | | | Report | 1034 | | |------------------->| 1035 | | | | 1036 | | | | 1038 Figure 7: Next Registration Flow 1040 Note that any of the functions 6LR, Root and 6LBR might be collapsed 1041 in a single node, in which case the flow above happens internally, 1042 and possibly through internal API calls as opposed to messaging. 1044 10. Implementation Status 1046 11. Security Considerations 1048 The LLN nodes depend on the 6LBR and the RPL participants for their 1049 operation. A trust model must be put in place to ensure that the 1050 right devices are acting in these roles, so as to avoid threats such 1051 as black-holing, (see [RFC7416] section 7) or bombing attack whereby 1052 an impersonated 6LBR would destroy state in the network by using the 1053 "Removed" Status code. This trust model could be at a minimum based 1054 on a Layer-2 access control, or could provide role validation as 1055 well. This is a generic 6LoWPAN requirement, see Req5.1 in 1056 Appendix of [RFC8505]. 1058 The keep-alive EDAR message does not carry a valid Registration 1059 Unique ID [RFC8505] and it cannot be used to create a binding state 1060 in the 6LBR. The 6LBR MUST NOT create an entry based on a keep-alive 1061 EDAR that does not match an existing entry. All it can do is refresh 1062 the lifetime and the TID of an existing entry. 1064 At the time of this writing RPL does not have a zerotrust model 1065 whereby the it is possible to validate the origin of an address that 1066 is injected in a DAO. This specification makes a first step in that 1067 direction by allowing the Root to challenge the RUL by the 6LR that 1068 serves it. 1070 12. IANA Considerations 1072 12.1. RPL Target Option Flags 1074 Section 20.15 of [RFC6550] creates a registry for the 8-bit RPL 1075 Target Option Flags field. This specification reduces the field to 4 1076 bits. The IANA is requested to reduce the size of the registry 1077 accordingly. 1079 12.2. New Subsubregistry for the Status values of the RPL DAO-ACK 1080 Message 1082 This specification creates a new subsubregistry for the Status values 1083 of the RPL DAO-ACK Message, under the ICMPv6 parameters registry. 1085 o Possible values are 8-bit unsigned integers (0..255). 1087 o Registration procedure is "Standards Action" [RFC8126]. 1089 o Initial allocation is as indicated in Table 1: 1091 +---------+-----------------------+---------------------------------+ 1092 | Value | Meaning | Defining Spec | 1093 +---------+-----------------------+---------------------------------+ 1094 | 0 | Unqualified | [RFC6550] | 1095 | | acceptance | | 1096 | | | | 1097 | 1-127 | Reserved for Warning | [RFC6550] | 1098 | | Codes | | 1099 | | | | 1100 | 128 | Duplicate Address | This RFC | 1101 | | | | 1102 | 129 | Out of Storage | This RFC | 1103 | | | | 1104 | 130 | Moved | [I-D.ietf-roll-efficient-npdao] | 1105 | | | | 1106 | 131 | Removed | This RFC | 1107 | | | | 1108 | 132 | Validation Requested | This RFC | 1109 | | | | 1110 | 133 | Duplicate Source | This RFC | 1111 | | Address | | 1112 | | | | 1113 | 134 | Invalid Source | This RFC | 1114 | | Address | | 1115 | | | | 1116 | 135 | Address topologically | This RFC | 1117 | | incorrect | | 1118 | | | | 1119 | 136 | 6LBR Registry | This RFC | 1120 | | saturated | | 1121 | | | | 1122 | 137 | Validation Failed | This RFC | 1123 | | | | 1124 | 138-192 | Reserved for 6LoWPAN | This RFC | 1125 | | ND code mapping | | 1126 | | | | 1127 | 193-255 | Reserved for other | [RFC6550] | 1128 | | Rejection Codes | | 1129 +---------+-----------------------+---------------------------------+ 1131 Table 1: Status values of the RPL DAO-ACK Message 1133 13. Acknowledgments 1135 The authors wish to thank Georgios Papadopoulos for their early 1136 reviews of and contributions to this document 1138 14. References 1140 14.1. Normative References 1142 [I-D.ietf-6lo-ap-nd] 1143 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 1144 "Address Protected Neighbor Discovery for Low-power and 1145 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 1146 progress), April 2019. 1148 [I-D.ietf-roll-efficient-npdao] 1149 Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient 1150 Route Invalidation", draft-ietf-roll-efficient-npdao-16 1151 (work in progress), September 2019. 1153 [I-D.ietf-roll-useofrplinfo] 1154 Robles, I., Richardson, M., and P. Thubert, "Using RPL 1155 Option Type, Routing Header for Source Routes and IPv6-in- 1156 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 1157 roll-useofrplinfo-31 (work in progress), August 2019. 1159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1160 Requirement Levels", BCP 14, RFC 2119, 1161 DOI 10.17487/RFC2119, March 1997, 1162 . 1164 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1165 Listener Discovery (MLD) for IPv6", RFC 2710, 1166 DOI 10.17487/RFC2710, October 1999, 1167 . 1169 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1170 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1171 DOI 10.17487/RFC3810, June 2004, 1172 . 1174 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1175 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1176 DOI 10.17487/RFC4861, September 2007, 1177 . 1179 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1180 Address Autoconfiguration", RFC 4862, 1181 DOI 10.17487/RFC4862, September 2007, 1182 . 1184 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1185 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1186 Overview, Assumptions, Problem Statement, and Goals", 1187 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1188 . 1190 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1191 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1192 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1193 Low-Power and Lossy Networks", RFC 6550, 1194 DOI 10.17487/RFC6550, March 2012, 1195 . 1197 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1198 Power and Lossy Networks (RPL) Option for Carrying RPL 1199 Information in Data-Plane Datagrams", RFC 6553, 1200 DOI 10.17487/RFC6553, March 2012, 1201 . 1203 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1204 Statement and Requirements for IPv6 over Low-Power 1205 Wireless Personal Area Network (6LoWPAN) Routing", 1206 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1207 . 1209 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1210 Bormann, "Neighbor Discovery Optimization for IPv6 over 1211 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1212 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1213 . 1215 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1216 Writing an IANA Considerations Section in RFCs", BCP 26, 1217 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1218 . 1220 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1221 "IPv6 over Low-Power Wireless Personal Area Network 1222 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1223 April 2017, . 1225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1227 May 2017, . 1229 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1230 (IPv6) Specification", STD 86, RFC 8200, 1231 DOI 10.17487/RFC8200, July 2017, 1232 . 1234 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1235 Perkins, "Registration Extensions for IPv6 over Low-Power 1236 Wireless Personal Area Network (6LoWPAN) Neighbor 1237 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1238 . 1240 14.2. Informative References 1242 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1243 C., and M. Carney, "Dynamic Host Configuration Protocol 1244 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1245 2003, . 1247 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1248 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1249 DOI 10.17487/RFC6282, September 2011, 1250 . 1252 [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, 1253 Ed., "Performance Evaluation of the Routing Protocol for 1254 Low-Power and Lossy Networks (RPL)", RFC 6687, 1255 DOI 10.17487/RFC6687, October 2012, 1256 . 1258 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1259 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1260 2014, . 1262 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1263 Constrained-Node Networks", RFC 7228, 1264 DOI 10.17487/RFC7228, May 2014, 1265 . 1267 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1268 and M. Richardson, Ed., "A Security Threat Analysis for 1269 the Routing Protocol for Low-Power and Lossy Networks 1270 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1271 . 1273 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1274 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1275 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1276 . 1278 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1279 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1280 January 2019, . 1282 Appendix A. Example Compression 1284 Figure 8 illustrates the case in Storing mode where the packet is 1285 received from the Internet, then the Root encapsulates the packet to 1286 insert the RPI and deliver to the 6LR that is the parent and last hop 1287 to the final destination, which is not known to support [RFC8138]. 1288 The difference with the format presented in Figure 19 of [RFC8138] is 1289 the addition of a SRH-6LoRH before the RPI-6LoRH to transport the 1290 destination address of the outer IPv6 header. 1292 +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... 1293 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 1294 |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 1295 +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... 1296 <-4bytes-> <- RFC 6282 -> 1297 No RPL artifact 1299 Figure 8: Encapsulation to Parent 6LR in Storing Mode 1301 In Figure 8, the source of the IP-in-IP encapsulation is the Root, so 1302 it is elided in the IP-in-IP 6LoRH. The destination is the parent 1303 6LR of the destination of the inner packet so it cannot be elided. 1304 In Storing Mode, it is placed as the single entry in an SRH-6LoRH as 1305 the first 6LoRH. Since there is a single entry so the SRH-6LoRH Size 1306 is 0. In this particular example, the 6LR address can be compressed 1307 to 2 bytes so a Type of 1 is used. It results that the total length 1308 of the SRH-6LoRH is 4 bytes. 1310 In Non-Storing Mode, the encapsulation from the Root would be similar 1311 to that represented in Figure 8 with possibly more hops in the SRH- 1312 6LoRH and possibly multiple SRH-6LoRHs if the various addresses in 1313 the routing header are not compressed to the same format. Note that 1314 on the last hop to the parent 6LR, the RH3 is consumed and removed 1315 from the compressed form, so the use of Non-Storing Mode vs. Storing 1316 Mode is indistinguishable from the packet format. 1318 Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 1319 6LoRH is removed, all the router headers that precede it are also 1320 removed. 1322 The Paging Dispatch [RFC8025] may also be removed if there was no 1323 previous Page change to a Page other than 0 or 1, since the 1324 LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and 1325 in Page 1. The resulting packet to the destination is the inner 1326 packet compressed with [RFC6282]. 1328 Authors' Addresses 1330 Pascal Thubert (editor) 1331 Cisco Systems, Inc 1332 Building D 1333 45 Allee des Ormes - BP1200 1334 MOUGINS - Sophia Antipolis 06254 1335 FRANCE 1337 Phone: +33 497 23 26 34 1338 Email: pthubert@cisco.com 1340 Michael C. Richardson 1341 Sandelman Software Works 1343 Email: mcr+ietf@sandelman.ca 1344 URI: http://www.sandelman.ca/