idnits 2.17.1 draft-ietf-roll-unaware-leaves-16.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 (8 June 2020) is 1389 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 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-38 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 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 Systems 4 Updates: 6550, 8505 (if approved) M. Richardson 5 Intended status: Standards Track Sandelman 6 Expires: 10 December 2020 8 June 2020 8 Routing for RPL Leaves 9 draft-ietf-roll-unaware-leaves-16 11 Abstract 13 This specification extends RFC6550 and RFC8505 to provide routing 14 services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND 15 but do not participate to RPL. This specification also enables the 16 RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 10 December 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 7 57 3.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 7 58 3.2. RFC 8505 Extended Address Registration . . . . . . . . . 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 3.3.1. RFC 7400 Capability Indication Option . . . . . . . . 9 64 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 11 66 6. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11 67 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11 68 6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 12 69 6.2.1. Support of IPv6 Encapsulation . . . . . . . . . . . . 13 70 6.2.2. Support of the HbH Header . . . . . . . . . . . . . . 13 71 6.2.3. Support of the Routing Header . . . . . . . . . . . . 13 72 7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13 73 8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14 74 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15 75 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15 76 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 19 77 9.2.1. Perspective of the RUL Acting as 6LN . . . . . . . . 19 78 9.2.2. Perspective of the RPL Border Router Acting as 6LR . 20 79 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 22 80 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 23 81 10. Protocol Operations for Multicast Addresses . . . . . . . . . 24 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 12.1. Resizing the ARO Status values . . . . . . . . . . . . . 27 85 12.1.1. RPL Target Option Flags . . . . . . . . . . . . . . 27 86 12.1.2. Address Registration Option Flags . . . . . . . . . 27 87 12.2. New DODAG Configuration Option Flag . . . . . . . . . . 27 88 12.3. New Subregistry for the RPL Non-Rejection Status 89 values . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 12.4. New Subregistry for the RPL Rejection Status values . . 28 91 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 92 14. Normative References . . . . . . . . . . . . . . . . . . . . 28 93 15. Informative References . . . . . . . . . . . . . . . . . . . 31 94 Appendix A. Example Compression . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Introduction 99 The design of Low Power and Lossy Networks (LLNs) is generally 100 focused on saving energy, which is the most constrained resource of 101 all. Other design constraints, such as a limited memory capacity, 102 duty cycling of the LLN devices and low-power lossy transmissions, 103 derive from that primary concern. 105 The IETF produced the "Routing Protocol for Low Power and Lossy 106 Networks" [RFC6550] (RPL) to provide IPv6 [RFC8200] routing services 107 within such constraints. RPL belongs to the class of Distance-Vector 108 protocols, which, compared to link-state protocols, limit the amount 109 of topological knowledge that needs to be installed and maintained in 110 each node. 112 To save signaling and routing state in constrained networks, RPL 113 allows a routing stretch (see [RFC6687]), whereby routing is only 114 performed along an acyclic graph optimized to reach a Root node, as 115 opposed to straight along a shortest path between 2 peers, whatever 116 that would mean in a given LLN. This trades the quality of peer-to- 117 peer (P2P) paths for a vastly reduced amount of control traffic and 118 routing state that would be required to operate a any-to-any shortest 119 path protocol. Finally, broken routes may be fixed lazily and on- 120 demand, based on dataplane inconsistency discovery, which avoids 121 wasting energy in the proactive repair of unused paths. 123 To provide alternate paths in lossy networks, RPL forms Direction- 124 Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information 125 Solicitation (DIS) and DODAG Information Object (DIO) messages. For 126 many of the nodes, though not all, a DODAG provides multiple 127 forwarding solutions towards the Root of the topology via so-called 128 parents. RPL is designed to adapt to fuzzy connectivity, whereby the 129 physical topology cannot be expected to reach a stable state, with a 130 lazy control that creates the routes proactively, but may only fix 131 them reactively, upon actual traffic. The result is that RPL 132 provides reachability for most of the LLN nodes, most of the time, 133 but may not converge in the classical sense. 135 [RFC6550] provides unicast and multicast routing services to RPL- 136 Aware nodes (RANs), either as a collection tree or with routing back. 137 In the latter case, an RAN injects routes to itself using Destination 138 Advertisement Object (DAO) messages sent either to parent-nodes, in 139 the RPL Storing Mode, or to the Root indicating their parent, in the 140 Non-Storing Mode. This process effectively forms a DODAG back to the 141 device that is a subset of the DODAG to the Root with all links 142 reversed. 144 RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND) 145 [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain 146 reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In 147 that mode, some nodes may act as Routers and participate to the 148 forwarding operations whereas others will only terminate packets, 149 acting as Hosts in the data-plane. In [RFC6550] terms, a Host that 150 is reachable over the RPL network is called a Leaf. 152 "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo] 153 introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects 154 routes in RPL to manage the reachability of its own IPv6 addresses. 155 In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that 156 does not participate to RPL at all. A RUL is an IPv6 Host [RFC8504] 157 that needs a RPL-Aware Router to obtain routing services over the RPL 158 network. 160 This specification leverages the Address Registration mechanism 161 defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to 162 interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to 163 request that the 6LR injects the relevant routing information for the 164 Registered Address in the RPL domain on its behalf. A RUL may be 165 unable to participate because it is very energy-constrained, or 166 because it is unsafe to let it inject routes in RPL, in which case 167 using 6LowPAN ND as the interface for the RUL limits the surface of 168 the possible attacks and optionally protects the address ownership. 170 The Non-Storing Mode mechanisms are used to extend the routing state 171 with connectivity to RULs even when the DODAG is operated in Storing 172 Mode DODAGs. The unicast packet forwarding operation by the 6LR 173 serving a 6LN that is a RPL Leaf is described in [USEofRPLinfo]. 175 Examples of routing-agnostic 6LNs include lightly-powered sensors 176 such as window smash sensor (alarm system), and kinetically powered 177 light switches. Other applications of this specification may include 178 a smart grid network that controls appliances - such as washing 179 machines or the heating system - in the home. Appliances may not 180 participate to the RPL protocol operated in the Smartgrid network but 181 can still interact with the Smartgrid for control and/or metering. 183 2. Terminology 185 2.1. BCP 14 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119][RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 2.2. References 195 The Terminology used in this document is consistent with and 196 incorporates that described in "Terms Used in Routing for Low-Power 197 and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical 198 6LoWPAN acronyms is given in Section 2.3. Other terms in use in LLNs 199 are found in "Terminology for Constrained-Node Networks" [RFC7228]. 201 "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by 202 a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for 203 Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract 204 information that RPL defines to be placed in data packets, e.g., as 205 the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By 206 extension the term "RPI" is often used to refer to the RPL Option 207 itself. The DODAG Information Solicitation (DIS), Destination 208 Advertisement Object (DAO) and DODAG Information Object (DIO) 209 messages are also specified in [RFC6550]. The Destination Cleanup 210 Object (DCO) message is defined in [EFFICIENT-NPDAO]. 212 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 213 Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node 214 (RAN) is introduced to refer to a node that is either an RAL or a RPL 215 Router. As opposed to a RUL, an RAN manages the reachability of its 216 addresses and prefixes by injecting them in RPL by itself. 218 In this document, readers will encounter terms and concepts that are 219 discussed in the following documents: 221 Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861] 222 and "IPv6 Stateless Address Autoconfiguration" [RFC4862], 224 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power 225 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and 226 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 227 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 228 and 230 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 231 Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor 232 Discovery" [RFC8505], and "Address Protected Neighbor Discovery 233 for Low-power and Lossy Networks" [AP-ND] . 235 2.3. Glossary 237 This document often uses the following acronyms: 239 AR: Address Resolution (aka Address Lookup) 240 6CIO: 6LoWPAN Capability Indication Option 242 6LN: 6LoWPAN Node (a Low Power Host or Router) 244 6LR: 6LoWPAN Router 246 (E)ARO: (Extended) Address Registration Option 248 (E)DAR: (Extended) Duplicate Address Request 250 (E)DAC: (Extended) Duplicate Address Confirmation 252 DAD: Duplicate Address Detection 254 DAO: Destination Advertisement Object (a RPL message) 256 DCO: Destination Cleanup Object (a RPL message) 258 DIS: DODAG Information Solicitation (a RPL message) 260 DIO: DODAG Information Object (a RPL message) 262 DODAG: Destination-Oriented Directed Acyclic Graph 264 LLN: Low-Power and Lossy Network 266 NA: Neighbor Advertisement 268 NCE: Neighbor Cache Entry 270 ND: Neighbor Discovery 272 NS: Neighbor Solicitation 274 RA: Router Advertisement 276 ROVR: Registration Ownership Verifier 278 RPI: RPL Packet Information 280 RAL: RPL-Aware Leaf 282 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) 284 RUL: RPL-Unaware Leaf 286 TID: Transaction ID (a sequence counter in the EARO) 288 3. 6LoWPAN Neighbor Discovery 290 3.1. RFC 6775 Address Registration 292 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 293 [RFC4862] was defined for transit media such a Ethernet. It is a 294 reactive protocol that relies heavily on multicast operations for 295 address discovery (aka lookup) and duplicate address detection (DAD). 297 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 298 adapts IPv6 ND for operations over energy-constrained LLNs. The main 299 functions of [RFC6775] are to proactively establish the Neighbor 300 Cache Entry (NCE) in the 6LR and to prevent address duplication. To 301 that effect, [RFC6775] introduces a new unicast Address Registration 302 mechanism that contributes to reducing the use of multicast messages 303 compared to the classical IPv6 ND protocol. 305 [RFC6775] defines a new Address Registration Option (ARO) that is 306 carried in the unicast Neighbor Solicitation (NS) and Neighbor 307 Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 308 6LoWPAN Router (6LR). It also defines the Duplicate Address Request 309 (DAR) and Duplicate Address Confirmation (DAC) messages between the 310 6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the 311 central repository of all the Registered Addresses in its domain and 312 the source of truth for uniqueness and ownership. 314 3.2. RFC 8505 Extended Address Registration 316 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 317 updates the behavior of RFC 6775 to enable a generic Address 318 Registration to services such as routing and ND proxy, and defines 319 the Extended Address Registration Option (EARO) as shown in Figure 1: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | Status | Opaque | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Rsvd | I |R|T| TID | Registration Lifetime | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 ... Registration Ownership Verifier ... 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 1: EARO Option Format 335 3.2.1. R Flag 337 [RFC8505] introduces the "R" flag in the EARO. The Registering Node 338 sets the "R" flag to indicate whether the 6LR should ensure 339 reachability for the Registered Address. If the "R" flag is not set, 340 then the Registering Node handles the reachability of the Registered 341 Address by other means, which means in a RPL network that it is an 342 RAN or that it uses another RPL Router for reachability services. 344 This document specifies how the "R" flag is used in the context of 345 RPL. A 6LN is a RUL that requires reachability services for an IPv6 346 address if and only if it sets the "R" flag in the NS(EARO) used to 347 register the address to a RPL border router acting as 6LR. Upon 348 receiving the NS(EARO), the RPL router generates a DAO message for 349 the Registered Address if and only if the "R" flag is set. 351 3.2.2. TID, I Field and Opaque Fields 353 The EARO also includes a sequence counter called Transaction ID 354 (TID), which maps to the Path Sequence Field found in Transit Options 355 in RPL DAO messages. This is the reason why the support of [RFC8505] 356 by the RUL as opposed to only [RFC6775] is a prerequisite for this 357 specification (more in Section 6.1). The EARO also transports an 358 Opaque field and an "I" field that describes what the Opaque field 359 transports and how to use it. Section 9.2.1 specifies the use of the 360 "I" field and of the Opaque field by a RUL. 362 3.2.3. ROVR 364 Section 5.3 of [RFC8505] introduces the Registration Ownership 365 Verifier (ROVR) field of variable length from 64 to 256 bits. The 366 ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was 367 used to identify uniquely an Address Registration with the Link-Layer 368 address of the owner, but provided no protection against spoofing. 370 "Address Protected Neighbor Discovery for Low-power and Lossy 371 Networks" [AP-ND] leverages the ROVR field as a cryptographic proof 372 of ownership to prevent a rogue third party from misusing the 373 address. [AP-ND] adds a challenge/response exchange to the [RFC8505] 374 Address Registration and enables Source Address Validation by a 6LR 375 that will drop packets with a spoofed address. 377 This specification does not address how the protection by [AP-ND] 378 could be extended to RPL. On the other hand, it adds the ROVR to the 379 DAO to build the proxied EDAR at the Root (see Section 8), which 380 means that nodes that are aware of the Host route to the 6LN are made 381 aware of the associated ROVR as well. 383 3.3. RFC 8505 Extended DAR/DAC 385 [RFC8505] updates the periodic DAR/DAC exchange that takes place 386 between the 6LR and the 6LBR using Extended DAR/DAC messages which 387 can carry a ROVR field of variable size. The exchange is triggered 388 by an NS(EARO) message and is intended to create, refresh and delete 389 the corresponding state in the 6LBR for a lifetime that is indicated 390 by the 6LN. It is protected by the ARQ mechanism specified in 8.2.6 391 of [RFC6775], though in an LLN, a duration longer than the 392 RETRANS_TIMER [RFC4861] of 1 second may be necessary to cover the 393 Turn Around Trip delay from the 6LR to the 6LBR. 395 RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to 396 the Root that maintains the routing state in the RPL network for the 397 lifetime indicated by the source of the DAO. This means that for 398 each address, there are two keep-alive messages that traverse the 399 whole network, one to the Root and one to the 6LBR. 401 This specification removes the extraneous keep-alive across the LLN. 402 The 6LR turns the periodic Address Registration from the RUL into a 403 DAO message to the Root on every refresh, but it only generates the 404 EDAR upon the first registration, for the purpose of DAD. Upon a 405 refresher DAO, the Root proxies the EDAR exchange to refresh the 406 state at the 6LBR on behalf of the 6LR, as illustrated in Figure 7. 408 3.3.1. RFC 7400 Capability Indication Option 410 "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power 411 Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the 412 6LoWPAN Capability Indication Option (6CIO) that enables a node to 413 expose its capabilities in Router Advertisement (RA) messages. 414 [RFC8505] defines a number of bits in the 6CIO, in particular: 416 L: Node is a 6LR. 417 E: Node is an IPv6 ND Registrar -- i.e., it supports registrations 418 based on EARO. 419 P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that 420 also provides reachability services for the Registered Address. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Type | Length = 1 | Reserved |D|L|B|P|E|G| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Reserved | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 2: 6CIO flags 432 A 6LR that can provide reachability services for a RUL in a RPL 433 network as specified in this document SHOULD include a 6CIO in its RA 434 messages and set the L, P and E flags as prescribed by [RFC8505], see 435 Section 6.1 for the behavior of the RUL. 437 4. Updating RFC 6550 439 This document specifies a new behavior whereby a 6LR injects DAO 440 messages for unicast addresses (see Section 9) and multicast 441 addresses (see Section 10) on behalf of leaves that are not aware of 442 RPL. The addresses are exposed as external targets [RFC6550]. Per 443 [USEofRPLinfo], an IP-in-IP encapsulation that terminates at the RPL 444 Root is used to remove RPL artifacts and compression techniques that 445 may not be processed correctly outside of the RPL domain. 447 This document also synchronizes the liveness monitoring at the Root 448 and the 6LBR. A same value of lifetime is used for both, and a 449 single keep-alive message, the RPL DAO, traverses the RPL network. A 450 new behavior is introduced whereby the RPL Root proxies the EDAR 451 message to the 6LBR on behalf of the 6LR (more in Section 5), for any 452 6LN, RUL or RAN. 454 Section 6.7.6 of [RFC6550] defines the DODAG Configuration option 455 with reserved flags. This specification defines the new "Root 456 Proxies EDAR/EDAC" (P) flag and consumes one of the reserved flags to 457 encode it. The "P" flag is set to indicate that the Root performs 458 the proxy operation and that all nodes in the RPL network must 459 refrain from renewing the 6LBR state directly. It also indicates 460 that the Root supports the Updated RPL Target Option (see Section 8). 461 The position of the "P" flag is indicated in Section 12.2. 463 Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in 464 the DIO Base Object. The new "P" flag is defined only for MOP value 465 between 0 to 6. For a MOP value of 7 or above, the flag MAY be 466 redefined and MUST NOT be interpreted as "Root Proxies EDAR/EDAC" 467 unless the specification of the MOP indicates to do so. 469 The RPL Status defined in section 6.5.1 of [RFC6550] for use in the 470 DAO-Ack message is extended to be used in the DCO messages 471 [EFFICIENT-NPDAO] as well. Furthermore, this specification enables 472 to use a RPL Status to embed the IPv6 ND Status defined for use in 473 the EARO, more in Section 7. 475 Section 6.7 of [RFC6550] introduces the RPL Control message Options 476 such as the RPL Target Option that can be included in a RPL Control 477 message such as the DAO. Section 8 updates the RPL Target Option to 478 optionally transport the ROVR used in the IPv6 Registration (see 479 Section 3.2.3) so the RPL Root can generate a full EDAR message. 481 5. Updating RFC 8505 483 This document updates [RFC8505] to introduce the anonymous EDAR and 484 NS(EARO) messages. The anonymous messages are used for backward 485 compatibility. The anonymous messages are recognizable by a zero 486 ROVR field and can only be used as a refresher for a pre-existing 487 state associated to the Registered Address. More specifically, an 488 anonymous message can only increase the lifetime and/or increment the 489 TID of an existing state at the 6LBR. 491 Upon the renewal of a 6LoWPAN ND Address Registration, this 492 specification changes the behavior of a RPL Router acting as 6LR for 493 the registration. If the Root indicates the capability to proxy the 494 EDAR/EDAC exchange to the 6LBR by setting the "P" flag, the 6LR 495 refrains from sending an EDAR message; if the Root is separated from 496 the 6LBR, the Root regenerates the EDAR message to the 6LBR upon a 497 DAO message that signals the liveliness of the Address. The 498 regenerated message is anonymous if and only if the DAO is a legacy 499 message that does not carry a ROVR as specified in Section 8. 501 6. Requirements on the RPL-Unware Leaf 503 This document provides RPL routing for a RUL, that is a 6LN acting as 504 an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent 505 functionality is required from the RUL to obtain routing services. 507 6.1. Support of 6LoWPAN ND 509 In order to obtain routing services from a 6LR, a RUL MUST implement 510 [RFC8505] and set the "R" flag in the EARO. The RUL SHOULD support 511 [AP-ND] and use it to protect the ownership of its addresses. The 512 RUL MUST NOT request routing services from a 6LR that does not 513 originate RA messages with a CIO that has the L, P, and E flags all 514 set as discussed in Section 3.3.1. 516 A RUL that has multiple potential routers MUST prefer those that 517 provide routing services. The RUL MUST register to all the 6LRs from 518 which it desires routing services. If there are no available 519 routers, the connection of the RUL fails. The Address Registrations 520 SHOULD be performed in an RApid sequence, using the exact same EARO 521 for a same Address. Gaps between the Address Registrations will 522 invalidate some of the routes till the Address Registration finally 523 shows on those routes as well. 525 [RFC8505] introduces error Status values in the NA(EARO) which can be 526 received synchronously upon an NS(EARO) or asynchronously. The RUL 527 MUST support both cases and MUST refrain from using the address when 528 the Status value indicates a rejection. 530 6.2. External Routes and RPL Artifacts 532 Section 4.1 of [USEofRPLinfo] provides a set of rules that MUST be 533 followed for the routing operations to a RUL. 535 A 6LR that is upgraded to act as a border router for external routes 536 advertises them using Non-Storing Mode DAO messages that are unicast 537 directly to the Root, even if the DODAG is operated in Storing Mode. 538 Non-Storing Mode routes are not visible inside the RPL domain and all 539 packets are routed via the Root. An upgraded Root tunnels the 540 packets directly to the 6LR that advertised the external route which 541 decapsulates and forwards the original (inner) packet. 543 The RPL Non-Storing Mode signaling and the associated IP-in-IP 544 encapsulated packets are normal traffic for the intermediate Routers. 545 The support of external routes only impacts the Root and the 6LR. It 546 can be operated with legacy intermediate routers and does not add to 547 the amount of state that must be maintained in those routers. A RUL 548 is an example of a destination that is reachable via an external 549 route which happens to be a Host route. 551 The RPL data packets always carry a Hop-by-Hop Header to transport a 552 RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates 553 its packets with an RPI, the 6LR needs to tunnel them to the Root to 554 add the RPI. As a rule of a thumb and except for the very special 555 case above, the packets from and to a RUL are always encapsulated 556 using an IP-in-IP tunnel between the Root and the 6LR that serves the 557 RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 558 8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details). 560 In Non-Storing Mode, packets going down carry a Source Routing Header 561 (SRH). The IP-in-IP encapsulation, the RPI and the SRH are 562 collectively called the "RPL artifacts" and can be compressed using 563 [RFC8138]. Figure 11 presents an example compressed format for a 564 packet forwarded by the Root to a RUL in a Storing Mode DODAG. 566 The inner packet that is forwarded to the RUL may carry some RPL 567 artifacts, e.g., an RPI if the original packet was generated with it 568 and possibly an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] 569 expects the RUL to support the basic "IPv6 Node Requirements" 570 [RFC8504]. In particular the RUL is expected to ignore the RPL 571 artifacts that are either consumed or not applicable to a Host. 573 A RUL is not expected to support the compression method defined in 574 [RFC8138]. Unless configured otherwise, the border router MUST 575 uncompress the outgoing packet before forwarding over an external 576 route, even if it is not the destination of the incoming packet, and 577 even when delivering to a RUL. 579 6.2.1. Support of IPv6 Encapsulation 581 Section 2.1 of [USEofRPLinfo] sets the rules for forwarding IP-in-IP 582 either to the final 6LN or to a parent 6LR. In order to enable IP- 583 in-IP to the 6LN in Non-Storing Mode, the 6LN must be able to 584 decapsulate the tunneled packet and either drop the inner packet if 585 it is not the final destination, or pass it to the upper layer for 586 further processing. Unless it is aware that the RUL can handle IP- 587 in-IP properly, the Root that encapsulates a packet to a RUL 588 terminates the IP-in-IP tunnel at the parent 6LR . For that reason, 589 it is beneficial but not necessary for a RUL to support IP-in-IP. 591 6.2.2. Support of the HbH Header 593 A RUL is expected to process an unknown Option Type in a Hop-by-Hop 594 Header as prescribed by section 4.2 of [RFC8200]. This means in 595 particular that an RPI with an Option Type of 0x23 [USEofRPLinfo] is 596 ignored when not understood. 598 6.2.3. Support of the Routing Header 600 A RUL is expected to process an unknown Routing Header Type as 601 prescribed by section 4.4 of [RFC8200]. This means in particular 602 that Routing Header with a Routing Type of 3 [RFC6554] is ignored 603 when the Segments Left is zero, and the packet is dropped otherwise. 605 7. Updated RPL Status 607 The RPL Status is defined in section 6.5.1 of [RFC6550] for use in 608 the DAO-Ack message and values are assigned as follows: 610 +---------+--------------------------------+ 611 | Range | Meaning | 612 +=========+================================+ 613 | 0 | Success/Unqualified acceptance | 614 +---------+--------------------------------+ 615 | 1-127 | Not an outright rejection | 616 +---------+--------------------------------+ 617 | 128-255 | Rejection | 618 +---------+--------------------------------+ 620 Table 1: RPL Status per RFC 6550 622 This specification extends the scope of the RPL Status to be used in 623 RPL DCO messages. Furthermore, this specification enables to carry 624 the IPv6 ND Status values defined for use in the EARO and initially 625 listed in table 1 of [RFC8505] in a RPL Status. 627 Section 12.1 reduces the range of EARO Status values to 0-63 ensure 628 that they fit within a RPL Status as shown in Figure 3. 630 0 631 0 1 2 3 4 5 6 7 632 +-+-+-+-+-+-+-+-+ 633 |E|A| Value | 634 +-+-+-+-+-+-+-+-+ 636 Figure 3: RPL Status Format 638 RPL Status subfields: 640 E: 1-bit flag. Set to indicate a rejection. When not set, a value 641 of 0 indicates Success/Unqualified acceptance and other values 642 indicate "not an outright rejection" as per RFC 6550. 644 A: 1-bit flag. Indicates the type of the Status value. 646 Status Value: 6-bit unsigned integer. If the 'A' flag is set this 647 field transports a Status value defined for IPv6 ND EARO. When 648 the 'A' flag is not set, the Status value is defined in a RPL 649 extension. 651 When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC 652 message, the RPL Root MUST copy the ND Status unchanged in a RPL 653 Status with the 'A' bit set. The RPL Root MUST set the 'E' flag for 654 all values in range 1-10 which are all considered rejections. 656 Conversely, the 6LR MUST copy the value of the RPL Status unchanged 657 in the EARO of an NA message that is built upon a RPL Status with the 658 'A' bit set in a DCO or a DAO-ACK message. 660 8. Updated RPL Target option 662 This specification updates the RPL Target option to transport the 663 ROVR. This enables the RPL Root to generate a full EDAR message as 664 opposed to an anonymous EDAR that has restricted properties. 666 The Target Prefix field MUST be aligned to the next 4-byte boundary 667 after the size indicated by the Prefix Length. If necessary the 668 transported prefix MUST be padded with zeros. 670 With this specification the ROVR is the remainder of the RPL Target 671 Option. The size of the ROVR is indicated in a new ROVR Size field 672 that is encoded to map one-to-one with the Code Suffix in the EDAR 673 message (see table 4 of [RFC8505]). 675 The modified format is illustrated in Figure 4. It is backward 676 compatible with the Target Option in [RFC6550] and SHOULD be used as 677 a replacement. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type = 0x05 | Option Length |ROVRsz | Flags | Prefix Length | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | | 685 + + 686 | Target Prefix (Variable Length) | 687 . Aligned to 4-byte boundary . 688 . . 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | | 691 ... Registration Ownership Verifier (ROVR) ... 692 | | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Figure 4: Updated Target Option 697 New fields: 699 ROVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, 700 denoting a ROVR size of 64, 128, 192, or 256 bits, respectively. 702 Registration Ownership Verifier (ROVR): This is the same field as in 703 the EARO, see [RFC8505] 705 9. Protocol Operations for Unicast Addresses 707 The description below assumes that the Root sets the "P" flag in the 708 DODAG Configuration Option and performs the EDAR proxy operation. 710 9.1. General Flow 712 This specification eliminates the need to exchange keep-alive 713 Extended Duplicate Address messages, EDAR and EDAC, all the way from 714 a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange 715 with the 6LBR is proxied by the RPL Root upon a DAO message that 716 refreshes the RPL routing state. Any combination of the logical 717 functions of 6LR, Root and 6LBR might be collapsed in a single node. 719 To achieve this, the lifetimes and sequence counters in 6LoWPAN ND 720 and RPL are aligned. In other words, the Path Sequence and the Path 721 Lifetime in the DAO message are taken from the Transaction ID and the 722 Address Registration lifetime in the NS(EARO) message from the 6LN. 724 In a RPL network where the function is enabled, refreshing the state 725 in the 6LBR is the responsibility of the Root. Consequently, only 726 addresses that are injected in RPL will be kept alive by the RPL 727 Root. In a same fashion, if an additional routing protocol is 728 deployed on a same network, that additional routing protocol may need 729 to handle the keep alive procedure for the addresses that it serves. 731 On the first Address Registration, illustrated in Figure 5 for RPL 732 Non-Storing Mode, the Extended Duplicate Address exchange takes place 733 as prescribed by [RFC8505]. If the exchange fails, the 6LR returns 734 an NA message with a negative status to the 6LN, the NCE is not 735 created and the address is not injected in RPL. If it is successful, 736 the 6LR creates an NCE and injects the Registered Address in RPL 737 using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root. 739 The 6LN signals the termination of a registration with a 6LR using an 740 NS(EARO) with a Registration Lifetime set to 0. Upon this, the 6LR 741 ensures that an EDAR/EDAC exchange happens to clean up the state at 742 the 6LBR, either directly as shown in Figure 8, or, if the Root sets 743 the "P" flag, by setting the ROVR in the RPL Target Option. 745 Since RULs are advertised using Non-Storing Mode, the DAO message 746 flow can be nested within the Address Registration flow as 747 illustrated in Figure 5. 749 6LN/RUL 6LR Root 6LBR 750 | | | | 751 | NS(EARO) | | | 752 |--------------->| | 753 | | Extended DAR | 754 | |--------------------------------->| 755 | | | 756 | | Extended DAC | 757 | |<---------------------------------| 758 | | DAO | | 759 | |------------->| | 760 | | | (anonymous) EDAR | 761 | | |------------------>| 762 | | | EDAC | 763 | | |<------------------| 764 | | DAO-ACK | | 765 | |<-------------| | 766 | NA(EARO) | | | 767 |<---------------| | | 768 | | | | 770 Figure 5: First RUL Registration Flow 772 An issue may be detected later, e.g., the address moves within the 773 LLN or to a different Root on a backbone [6BBR]. In that case the 774 value of the status that indicates the issue can be passed from 775 6LoWPAN ND to RPL and back as illustrated in Figure 6. 777 6LN/RUL 6LR Root 6LBR 778 | | | | 779 | | | NA(EARO, Status) | 780 | | |<-----------------| 781 | | DCO(Status) | | 782 | |<------------| | 783 | NA(EARO, Status) | | | 784 |<-----------------| | | 785 | | | | 787 Figure 6: Asynchronous Issue 789 An Address re-Registration is performed by the 6LN to maintain the 790 NCE in the 6LR alive before lifetime expires. Upon an Address re- 791 Registration, as illustrated in Figure 7, the 6LR redistributes the 792 Registered Address NS(EARO) in RPL. 794 6LN/RUL 6LR Root 6LBR 795 | | | | 796 | NS(EARO) | | | 797 |--------------->| | 798 | | DAO | | 799 | |------------->| | 800 | | | (anonymous) EDAR | 801 | | |------------------>| 802 | | | EDAC | 803 | | |<------------------| 804 | | DAO-ACK | | 805 | |<-------------| | 806 | NA(EARO) | | | 807 |<---------------| | | 809 Figure 7: Next RUL Registration Flow 811 This causes the RPL DODAG Root to refresh the state in the 6LBR with 812 an EDAC message or an anonymous EDAC if the ROVR is not indicated in 813 the Target Option. In both cases, the EDAC message sent in response 814 by the 6LBR contains the actual value of the ROVR field for that 815 Address Registration. In case of an error on the proxied EDAR flow, 816 the error MUST be returned in the DAO-ACK - if one was requested - 817 using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status 818 value as discussed in Section 7. 820 If the Root could not return the negative Status in a DAO-ACK then it 821 sends an asynchronous Destination Cleanup Object (DCO) message 822 [EFFICIENT-NPDAO] to the 6LR by placing the negative Status in the 823 RPL Status with the 'A' flag set. Note that if both are used in a 824 short interval of time, the DAO-ACK and DCO messages are not 825 guaranteed to arrive in the same order at the 6LR. 827 The 6LR may receive a requested DAO-ACK even after it received a DCO, 828 but the negative Status in the DCO supercedes a positive Status in 829 the DAO-ACK regardless of the order in which they are received. Upon 830 the DAO-ACK - or the DCO if it arrives first - the 6LR responds to 831 the RUL with an NA(EARO). If the RPL Status has the 'A' flag set, 832 then the ND Status is extracted and passed in the EARO; else, if the 833 'E' flag is set, indicating a rejection, then the status 4 "Removed" 834 is used; else, the ND Status of 0 indicating "Success" is used. 836 The RUL may terminate the registration at anytime by using a 837 Registration Lifetime of 0. This specification expects that the RPL 838 Target option transports a ROVR. If that is the case, the normal 839 heartbeat flow is sufficient to inform the 6LBR using the Root as 840 proxy as illustrated in Figure 7. If the 6LR could not add the ROVR 841 to the DAO message, then it MUST inform the 6LBR separately using as 842 illustrated in Figure 8. 844 6LN/RUL 6LR Root 6LBR 845 | | | | 846 |NS(EARO,Lifet=0)| | | 847 |--------------->| | 848 | | Extended DAR | 849 | |------------------------------------->| 850 | | | 851 | | Extended DAC | 852 | |<-------------------------------------| 853 | | DAO (Lifetime=0) | | 854 | |----------------->| | 855 | | | anonymous EDAR | 856 | | |------------------>| 857 | | | EDAC | 858 | | |<------------------| 859 | | DAO-ACK | | 860 | |<-----------------| | 861 | NA(EARO) | | | 862 |<---------------| | | 863 | | | | 864 | | | 865 | | | | 867 Figure 8: Last RUL Registration Flow, No ROVR 869 9.2. Detailed Operation 871 9.2.1. Perspective of the RUL Acting as 6LN 873 This specification does not alter the operation of a 6LoWPAN ND- 874 compliant 6LN, and a RUL is expected to operate as follows: 876 1. The 6LN obtains an IPv6 global address, either using Stateless 877 Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix 878 Information Option (PIO) [RFC4861] found in an RA message, or 879 some other means such as DHCPv6 [RFC3315]. 881 2. Once it has formed an address, the 6LN (re)registers its address 882 periodically, within the Lifetime of the previous Address 883 Registration, as prescribed by [RFC6775] and [RFC8505], to 884 refresh the NCE before the lifetime indicated in the EARO 885 expires. The TID is incremented each time and wraps in a 886 lollipop fashion (see section 5.2.1 of [RFC8505] which is fully 887 compatible with section 7.2 of [RFC6550]). 889 3. As stated in section 5.2 of [RFC8505], the 6LN can register to 890 more than one 6LR at the same time. In that case, it MUST use 891 the same value of TID for all of the parallel Address 892 Registrations. The 6LN should send the registration(s) with a 893 non-zero Registration Lifetime and ensure that one succeeds 894 before it terminates other registrations to maintain the state in 895 the network and at the 6LBR and minimize the churn. 897 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets 898 the "R" flag in the EARO of at least one registration, whereas 899 acting as an RAN it never does. If the "R" flag is not echoed in 900 the NA, the RUL SHOULD attempt to use another 6LR. The 6LN 901 should send the registration(s) with the "R" flag set and ensure 902 that one succeeds before it sends the registrations with the flag 903 reset. In case of a conflict with the preceeding rule on 904 lifetime, the rule on lifetime has precedence. 906 5. The 6LN may use any of the 6LRs to which it registered as default 907 gateway. Using a 6LR to which the 6LN is not registered may 908 result in packets dropped at the 6LR by a Source Address 909 Validation function (SAVI) so it is not recommended. 911 Even without support for RPL, a RUL may be aware of opaque values to 912 be provided to the routing protocol. If the RUL has a knowledge of 913 the RPL Instance the packet should be injected into, then it SHOULD 914 set the Opaque field in the EARO to the RPLInstanceID, else it MUST 915 leave the Opaque field to zero. 917 Regardless of the setting of the Opaque field, the 6LN MUST set the 918 "I" field to zero to signal "topological information to be passed to 919 a routing process" as specified in section 5.1 of [RFC8505]. 921 A RUL is not expected to produce RPL artifacts in the data packets, 922 but it MAY do so. For instance, if the RUL has a minimal awareness 923 of the RPL Instance then it can build an RPI. A RUL that places an 924 RPI in a data packet MUST indicate the RPLInstanceID of the RPL 925 Instance where the packet should be forwarded. All the flags and the 926 Rank field are set to zero as specified by section 11.2 of [RFC6550]. 928 9.2.2. Perspective of the RPL Border Router Acting as 6LR 930 Also as prescribed by [RFC8505], the 6LR generates an EDAR message 931 upon reception of a valid NS(EARO) message for the registration of a 932 new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange 933 succeeds, then the 6LR installs an NCE for the Registration Lifetime. 934 For the refreshes of the registration, if the RPL Root has indicated 935 that it proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see 936 Section 4), the 6LR MUST refrain from sending the keep-alive EDAR 937 itself. 939 If the "R" flag is set in the NS(EARO), the 6LR SHOULD attempt to 940 inject the host route in RPL, unless this is barred for other 941 reasons, like a saturation of the network or if its RPL parent. The 942 6LR MUST use a RPL Non-Storing Mode signaling. 944 The 6LR SHOULD request a DAO-ACK, failure to do so may incur an 945 asynchronous error flow that will tear down a state just installed 946 with the RUL. The 6LR MUST set "R" flag in the NA(EARO) back if and 947 only if it injected the Registered Address in the RPL routing. If a 948 DAO-ACK was requested, this is done upon receiving the DAO-ACK from 949 the Root with a positive status. 951 The 6LR may at any time send a unicast asynchronous NA(EARO) with the 952 "R" flag reset to signal that it stops providing routing services, 953 and/or with the EARO Status 2 "Neighbor Cache full" to signal that it 954 removes the NCE. It may also send a final RA, unicast or multicast, 955 with a Router Lifetime field of zero, to signal that it stops serving 956 as router, as specified in section 6.2.5 of [RFC4861]. 958 The Opaque field in the EARO hints the 6LR on the RPL Instance that 959 SHOULD be used for the DAO advertisements, and for the forwarding of 960 packets sourced at the registered address when there is no RPI in the 961 packet, in which case the 6LR MUST encapsulate the packet to the Root 962 adding an RPI in the outer header. If the Opaque field is zero, the 963 6LR is free to use the default RPL Instance (zero) for the registered 964 address or to select an Instance of its choice. 966 if the "I" field is not zero, then the 6LR MUST consider that the 967 Opaque field is zero. If the Opaque field is not zero, then it is 968 expected to carry a RPLInstanceID for the RPL Instance suggested by 969 the 6LN. If the 6LR does not participate to the associated Instance, 970 then the 6LR MUST consider that the Opaque field is zero; else, that 971 is if the 6LR participates to the suggested Instance, then the 6LR 972 SHOULD use that Instance for the registered address. 974 The DAO message advertising the Registered Address MUST be 975 constructed as follows: 977 1. The Registered Address is signaled as Target Prefix in the RPL 978 Target Option in the DAO message; the Prefix Length is set to 128 980 2. RPL Non-Storing Mode is to be used. The 6LR indicates one of its 981 global or unique-local IPv6 unicast addresses as the Parent 982 Address in the associated RPL Transit Information Option (TIO) 984 3. the External 'E' flag in the TIO is set to indicate that the 6LR 985 redistributes an external target into the RPL network 987 4. the Path Lifetime in the TIO is computed from the Lifetime in the 988 EARO Option. This adapts it to the Lifetime Units used in the 989 RPL operation; note that if the lifetime is 0, then the 6LR 990 generates a No-Path DAO message that cleans up the routes down to 991 the Address of the 6LN; this also causes the Root as a proxy to 992 send an EDAR message to the 6LBR with a Lifetime of 0. 994 5. the Path Sequence in the TIO is set to the TID value found in the 995 EARO option. 997 The NCE is removed if the 6LR tries to inject the route is RPL and 998 fails for reasons related to ND, which is recognized by both the 'E' 999 and the 'A' flags set in the RPL Status of the DAO-ACK or the DCO, as 1000 detailed below. 1002 Otherwise, success injecting the route is assumed if a DAO-ACK was 1003 not requested or if it is received with a RPL Status that is not a 1004 rejection (i.e., the 'E' flag not set). 1006 In case of success, if the 'A' flag is set in the RPL Status of the 1007 DAO-ACK, then the 6LR MUST use the Status Value in the RPL Status for 1008 the Status in the NA(EARO), else a Status of 0 (Success) is returned. 1010 The status of 0 MUST also be used if the 6LR could not even try to 1011 inject the route - note that the "R" flag is reset in that case. 1013 In a network where Address Protected Neighbor Discovery (AP-ND) is 1014 enabled, in case of a DAO-ACK or a DCO indicating transporting an 1015 EARO Status Value of 5 (Validation Requested), the 6LR MUST challenge 1016 the 6LN for ownership of the address, as described in section 6.1 of 1017 [AP-ND], before the Registration is complete. This ensures that the 1018 address validated before it is injected in RPL. 1020 If the challenge succeeds then the operations continue as normal. In 1021 particular a DAO message is generated upon the NS(EARO) that proves 1022 the ownership of the address. If the challenge failed, the 6LR 1023 rejects the registration as prescribed by AP-ND and may take actions 1024 to protect itself against DoS attacks by a rogue 6LN, see Section 11. 1026 The other rejection codes indicate that the 6LR failed to inject the 1027 address into the RPL network. If an EARO Status is transported, the 1028 6LR MUST send a NA(EARO) to the RUL with that Status value, and the 1029 "R" flag not set. Similarly, upon receiving a DCO message indicating 1030 that the address of a RUL should be removed from the routing table, 1031 the 6LR issues an asynchronous NA(EARO) to the RUL with the embedded 1032 ND Status value if there was one, and the "R" flag not set. 1034 If a 6LR receives a valid NS(EARO) message with the "R" flag reset 1035 and a Registration Lifetime that is not 0, and the 6LR was 1036 redistributing the Registered Address due to previous NS(EARO) 1037 messages with the flag set, then it MUST stop injecting the address. 1038 It is up to the Registering 6LN to maintain the corresponding route 1039 from then on, either keeping it active via a different 6LR or by 1040 acting as an RAN and managing its own reachability. 1042 9.2.3. Perspective of the RPL Root 1044 A RPL Root SHOULD set the "P" flag in the RPL configuration option of 1045 the DIO messages that it generates (see Section 4) to signal that it 1046 proxies the keep-alive EDAR/EDAC exchange and supports the Updated 1047 RPL Target option. The remainder of this section assumes that it 1048 does. 1050 Upon reception of a DAO message, for each RPL Target option that 1051 creates or updates an existing RPL state, the Root MUST notify the 1052 6LBR. This can be done using an internal API if they are co-located, 1053 or using a proxied EDAR/EDAC exchange if they are separated. 1055 Upon receiving an EDAC message from the 6LBR, if a DAO is pending, 1056 then the Root MUST send a DAO-ACK back to the 6LR. Else, if the 1057 Status in the EDAC message is not "Success", then it MUST send an 1058 asynchronous DCO to the 6LR. In either case, the EDAC Status is 1059 embedded in the RPL Status with the 'A' flag set. 1061 The EDAR message MUST be constructed as follows: 1063 1. The Target IPv6 address from the RPL Target Option is placed in 1064 the Registered Address field of the EDAR message; 1066 2. the Registration Lifetime is adapted from the Path Lifetime in 1067 the TIO by converting the Lifetime Units used in RPL into units 1068 of 60 seconds used in the 6LoWPAN ND messages; 1070 3. the TID value is set to the Path Sequence in the TIO and 1071 indicated with an ICMP code of 1 in the EDAR message; 1073 4. If the ROVR is present in the RPL Target option, it is copied as 1074 is in the EDAR and the ICMP Code Suffix is set to the appropriate 1075 value as shown in Table 4 of [RFC8505] depending on the size of 1076 the ROVR field; else, the ROVR field in the EDAR is set to zero 1077 indicating an anonymous EDAR. 1079 9.2.4. Perspective of the 6LBR 1081 Upon reception of an EDAR message with the ROVR field set to a non- 1082 zero value, the 6LBR acts as prescribed by [RFC8505] and returns an 1083 EDAC message to the sender. 1085 If the ROVR is set to 0, indicating an anonymous EDAR, the 6LBR MUST 1086 act as below: 1088 1. The 6LBR checks whether an entry exists for the address. If the 1089 entry does not exist, the 6LBR MUST NOT create the entry, and it 1090 MUST answer with a Status "Removed" in the EDAC message. If the 1091 entry exists, the 6LBR computes whether the TID in the EDAR 1092 message is fresher than the one in the entry as prescribed in 1093 section 4.2.1 of [RFC8505], and continues as follows: 1095 2. If the anonymous EDAR message is fresher, the 6LBR updates the 1096 TID in the entry, restarts the heartbeat timer for the entry, and 1097 answers with a Status "Success" in the EDAC message. If the 1098 value of the Registration Lifetime is smaller than the value in 1099 the entry, then the latter value MUST be used for the heartbeat; 1100 this means in particular that the Registration Lifetime of 0 is 1101 ignored. Conversely, if the duration of the Lifetime is extended 1102 by the Registration Lifetime in the EDAR message, it is used for 1103 the hearbeat and to the value in the entry is updated. 1105 3. If the TID in the entry is the same or fresher, the 6LBR does not 1106 update the entry, and answers with a Status "Success" and "Moved" 1107 in the EDAC message, respectively. 1109 The EDAC that is constructed is the same as if the anonymous EDAR was 1110 a full EDAR, but for the ROVR that is set to zero. 1112 10. Protocol Operations for Multicast Addresses 1114 Section 12 of [RFC6550] details the RPL support for multicast flows. 1115 This support is not source-specific and only operates as an extension 1116 to the Storing Mode of Operation for unicast packets. Note that it 1117 is the RPL model that the multicast packet is passed as a Layer-2 1118 unicast to each of the interested children. This remains true when 1119 forwarding between the 6LR and the listener 6LN. 1121 "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its 1122 updated version "Multicast Listener Discovery Version 2 (MLDv2) for 1123 IPv6" [RFC3810] provide an interface for a listener to register to 1124 multicast flows. MLDv2 is backwards compatible with MLD, and adds in 1125 particular the capability to filter the sources via black lists and 1126 white lists. In the MLD model, the Router is a "querier" and the 1127 Host is a multicast listener that registers to the querier to obtain 1128 copies of the particular flows it is interested in. 1130 On the first Address Registration, as illustrated in Figure 9, the 1131 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 1132 order to start receiving the flow immediately. 1134 6LN/RUL 6LR Root 6LBR 1135 | | | | 1136 | unsolicited Report | | | 1137 |------------------->| | | 1138 | | | | 1139 | | DAO | | 1140 | |-------------->| | 1141 | | DAO-ACK | | 1142 | |<--------------| | 1143 | | | | 1144 | | | unsolicited Report | 1145 | | |------------------->| 1146 | | | | 1148 Figure 9: First Multicast Registration Flow 1150 Since multicast Layer-2 messages are avoided, it is important that 1151 the asynchronous messages for unsolicited Report and Done are sent 1152 reliably, for instance using a Layer-2 acknowledgment, or attempted 1153 multiple times. 1155 The 6LR acts as a generic MLD querier and generates a DAO for the 1156 multicast target. The lifetime of the DAO is set to be in the order 1157 of the Query Interval, yet larger to account for variable propagation 1158 delays. 1160 The Root proxies the MLD exchange as a listener with the 6LBR acting 1161 as the querier, so as to get packets from a source external to the 1162 RPL domain. Upon a DAO with a multicast target, the RPL Root checks 1163 if it is already registered as a listener for that address, and if 1164 not, it performs its own unsolicited Report for the multicast target. 1166 An Address re-Registration is pulled periodically by 6LR acting as 1167 querier. Note that the message may be sent unicast to all the known 1168 individual listeners. Upon a time out of the Query Interval, the 6LR 1169 sends a Query to each of its listeners, and gets a Report back that 1170 is mapped into a DAO, as illustrated in Figure 10: 1172 6LN/RUL 6LR Root 6LBR 1173 | | | | 1174 | Query | | | 1175 |<-------------------| | | 1176 | Report | | | 1177 |------------------->| | | 1178 | | | | 1179 | | DAO | | 1180 | |-------------->| | 1181 | | DAO-ACK | | 1182 | |<--------------| | 1183 | | | | 1184 | | | Query | 1185 | | |<-------------------| 1186 | | | Report | 1187 | | |------------------->| 1188 | | | | 1189 | | | | 1191 Figure 10: Next Registration Flow 1193 Note that any of the functions 6LR, Root and 6LBR might be collapsed 1194 in a single node, in which case the flow above happens internally, 1195 and possibly through internal API calls as opposed to messaging. 1197 11. Security Considerations 1199 First of all, it is worth noting that with [RFC6550], every node in 1200 the LLN is RPL-aware and can inject any RPL-based attack in the 1201 network. This specification isolates edge nodes that can only 1202 interact with the RPL routers using 6LoWPAN ND, meaning that they 1203 cannot perform RPL insider attacks. 1205 6LoWPAN ND can optionally provide SAVI features with [AP-ND], which 1206 reduces even more the attack perimeter that is available to the edge 1207 nodes. 1209 The LLN nodes depend on the 6LBR and the RPL participants for their 1210 operation. A trust model must be put in place to ensure that the 1211 right devices are acting in these roles, so as to avoid threats such 1212 as black-holing, (see [RFC7416] section 7) or bombing attack whereby 1213 an impersonated 6LBR would destroy state in the network by using the 1214 "Removed" Status code. 1216 This trust model could be at a minimum based on a Layer-2 Secure 1217 joining and the Link-Layer security. This is a generic 6LoWPAN 1218 requirement, see Req5.1 in Appendix of [RFC8505]. 1220 Additionally, the trust model could include a role validation to 1221 ensure that the node that claims to be a 6LBR or a RPL Root is 1222 entitled to do so. 1224 The anonymous EDAR message does not carry a valid Registration Unique 1225 ID [RFC8505] in the form of a ROVR and may be played by any node on 1226 the network without the need to know the ROVR. The 6LBR MUST NOT 1227 create an entry based on a anonymous EDAR and it MUST NOT decrease 1228 the value of the lifetime. All it can do is refresh the lifetime and 1229 the TID of an existing entry. So the message cannot be used to 1230 create a binding state in the 6LBR but it can be used to maintain one 1231 active longer than expected. 1233 Note that a full EDAR message with a lifetime of 0 will destroy that 1234 state and the anonymous message will not recreate it. Note also that 1235 a rogue that has access to the network can attack the 6LBR with other 1236 (forged) addresses and ROVR, and that this is a much easier DoS 1237 attack than trying to keep existing state alive longer. 1239 At the time of this writing RPL does not have a zerotrust model 1240 whereby it is possible to validate the origin of an address that is 1241 injected in a DAO. This specification makes a first step in that 1242 direction by allowing the Root to challenge the RUL by the 6LR that 1243 serves it. 1245 12. IANA Considerations 1247 12.1. Resizing the ARO Status values 1249 Section 12 of [RFC6775] creates the Address Registration Option 1250 Status Values Registry with a range 0-255. This specification 1251 reduces that range to 0-63. 1253 IANA is requested to reduce the unassigned values range from 11-255 1254 to 11-63. 1256 12.1.1. RPL Target Option Flags 1258 Section 20.15 of [RFC6550] creates a Registry for the 8-bit RPL 1259 Target Option Flags field. 1261 IANA is requested to reduce the size of the field in the Registry to 1262 4 bits. 1264 12.1.2. Address Registration Option Flags 1266 Section 9.1 of [RFC8505] creates a Registry for the 8-bit Address 1267 Registration Option Flags field. 1269 IANA is requested to rename the first column of the table from "ARO 1270 Status" to "Bit number". 1272 12.2. New DODAG Configuration Option Flag 1274 This specification updates the Registry for the "DODAG Configuration 1275 Option Flags" that was created for [RFC6550] as follows: 1277 +------------+----------------------------+-----------+ 1278 | Bit Number | Capability Description | Reference | 1279 +============+============================+===========+ 1280 | 1 | Root Proxies EDAR/EDAC (P) | THIS RFC | 1281 +------------+----------------------------+-----------+ 1283 Table 2: New DODAG Configuration Option Flag 1285 12.3. New Subregistry for the RPL Non-Rejection Status values 1287 This specification creates a new Subregistry for the RPL Non- 1288 Rejection Status values for use in RPL DAO-ACK and DCO messages with 1289 the 'A' flag reset, under the ICMPv6 parameters registry. 1291 * Possible values are 6-bit unsigned integers (0..63). 1293 * Registration procedure is "Standards Action" [RFC8126]. 1295 * Initial allocation is as indicated in Table 3: 1297 +-------+------------------------+-----------+ 1298 | Value | Meaning | Reference | 1299 +=======+========================+===========+ 1300 | 0 | Unqualified acceptance | RFC 6550 | 1301 +-------+------------------------+-----------+ 1303 Table 3: Acceptance values of the RPL Status 1305 12.4. New Subregistry for the RPL Rejection Status values 1307 This specification creates a new Subregistry for the RPL Rejection 1308 Status values for use in RPL DAO-ACK and RCO messages with the 'A' 1309 flag reset, under the ICMPv6 parameters registry. 1311 * Possible values are 6-bit unsigned integers (0..63). 1313 * Registration procedure is "Standards Action" [RFC8126]. 1315 * Initial allocation is as indicated in Table 4: 1317 +-------+-----------------------+---------------+ 1318 | Value | Meaning | Reference | 1319 +=======+=======================+===============+ 1320 | 0 | Unqualified rejection | This document | 1321 +-------+-----------------------+---------------+ 1323 Table 4: Rejection values of the RPL Status 1325 13. Acknowledgments 1327 The authors wish to thank Ines Robles, Georgios Papadopoulos and 1328 Rahul Jadhav for their reviews and contributions to this document. 1330 14. Normative References 1332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1333 Requirement Levels", BCP 14, RFC 2119, 1334 DOI 10.17487/RFC2119, March 1997, 1335 . 1337 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1338 Listener Discovery (MLD) for IPv6", RFC 2710, 1339 DOI 10.17487/RFC2710, October 1999, 1340 . 1342 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1343 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1344 DOI 10.17487/RFC3810, June 2004, 1345 . 1347 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1348 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1349 Overview, Assumptions, Problem Statement, and Goals", 1350 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1351 . 1353 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1354 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1355 DOI 10.17487/RFC4861, September 2007, 1356 . 1358 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1359 Address Autoconfiguration", RFC 4862, 1360 DOI 10.17487/RFC4862, September 2007, 1361 . 1363 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1364 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1365 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1366 Low-Power and Lossy Networks", RFC 6550, 1367 DOI 10.17487/RFC6550, March 2012, 1368 . 1370 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1371 Power and Lossy Networks (RPL) Option for Carrying RPL 1372 Information in Data-Plane Datagrams", RFC 6553, 1373 DOI 10.17487/RFC6553, March 2012, 1374 . 1376 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1377 Routing Header for Source Routes with the Routing Protocol 1378 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1379 DOI 10.17487/RFC6554, March 2012, 1380 . 1382 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1383 Bormann, "Neighbor Discovery Optimization for IPv6 over 1384 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1385 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1386 . 1388 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1389 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1390 2014, . 1392 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1393 Constrained-Node Networks", RFC 7228, 1394 DOI 10.17487/RFC7228, May 2014, 1395 . 1397 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1398 IPv6 over Low-Power Wireless Personal Area Networks 1399 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1400 2014, . 1402 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1403 Writing an IANA Considerations Section in RFCs", BCP 26, 1404 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1405 . 1407 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1408 "IPv6 over Low-Power Wireless Personal Area Network 1409 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1410 April 2017, . 1412 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1413 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1414 May 2017, . 1416 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1417 (IPv6) Specification", STD 86, RFC 8200, 1418 DOI 10.17487/RFC8200, July 2017, 1419 . 1421 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1422 Perkins, "Registration Extensions for IPv6 over Low-Power 1423 Wireless Personal Area Network (6LoWPAN) Neighbor 1424 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1425 . 1427 [AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 1428 "Address Protected Neighbor Discovery for Low-power and 1429 Lossy Networks", Work in Progress, Internet-Draft, draft- 1430 ietf-6lo-ap-nd-23, 30 April 2020, 1431 . 1433 [USEofRPLinfo] 1434 Robles, I., Richardson, M., and P. Thubert, "Using RPI 1435 Option Type, Routing Header for Source Routes and IPv6-in- 1436 IPv6 encapsulation in the RPL Data Plane", Work in 1437 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-38, 1438 23 March 2020, . 1441 [EFFICIENT-NPDAO] 1442 Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient 1443 Route Invalidation", Work in Progress, Internet-Draft, 1444 draft-ietf-roll-efficient-npdao-18, 15 April 2020, 1445 . 1448 15. Informative References 1450 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1451 Statement and Requirements for IPv6 over Low-Power 1452 Wireless Personal Area Network (6LoWPAN) Routing", 1453 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1454 . 1456 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1457 C., and M. Carney, "Dynamic Host Configuration Protocol 1458 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1459 2003, . 1461 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1462 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1463 DOI 10.17487/RFC6282, September 2011, 1464 . 1466 [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, 1467 Ed., "Performance Evaluation of the Routing Protocol for 1468 Low-Power and Lossy Networks (RPL)", RFC 6687, 1469 DOI 10.17487/RFC6687, October 2012, 1470 . 1472 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1473 and M. Richardson, Ed., "A Security Threat Analysis for 1474 the Routing Protocol for Low-Power and Lossy Networks 1475 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1476 . 1478 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1479 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1480 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1481 . 1483 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1484 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1485 January 2019, . 1487 [6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1488 Backbone Router", Work in Progress, Internet-Draft, draft- 1489 ietf-6lo-backbone-router-20, 23 March 2020, 1490 . 1493 Appendix A. Example Compression 1495 Figure 11 illustrates the case in Storing Mode where the packet is 1496 received from the Internet, then the Root encapsulates the packet to 1497 insert the RPI and deliver to the 6LR that is the parent and last hop 1498 to the final destination, which is not known to support [RFC8138]. 1500 +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... 1501 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 1502 |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 1503 +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... 1504 <-4 bytes-> <- RFC 6282 -> 1505 <- No RPL artifact ... 1507 Figure 11: Encapsulation to Parent 6LR in Storing Mode 1509 The difference with the example presented in Figure 19 of [RFC8138] 1510 is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the 1511 compressed address of the 6LR as the destination address of the outer 1512 IPv6 header. In the original example the destination IP of the outer 1513 header was elided and was implicitly the same address as the 1514 destination of the inner header. Type 1 was arbitrarily chosen, and 1515 the size of 0 denotes a single address in the SRH. 1517 In Figure 11, the source of the IP-in-IP encapsulation is the Root, 1518 so it is elided in the IP-in-IP 6LoRH. The destination is the parent 1519 6LR of the destination of the inner packet so it cannot be elided. 1520 If the DODAG is operated in Storing Mode, it is the single entry in 1521 the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The SRH-6LoRH 1522 is the first 6LoRH in the chain. In this particular example, the 6LR 1523 address can be compressed to 2 bytes so a Type of 1 is used. It 1524 results that the total length of the SRH-6LoRH is 4 bytes. 1526 In Non-Storing Mode, the encapsulation from the Root would be similar 1527 to that represented in Figure 11 with possibly more hops in the SRH- 1528 6LoRH and possibly multiple SRH-6LoRHs if the various addresses in 1529 the routing header are not compressed to the same format. Note that 1530 on the last hop to the parent 6LR, the RH3 is consumed and removed 1531 from the compressed form, so the use of Non-Storing Mode vs. Storing 1532 Mode is indistinguishable from the packet format. 1534 The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH. 1535 When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that 1536 precede it are also removed. The Paging Dispatch [RFC8025] may also 1537 be removed if there was no previous Page change to a Page other than 1538 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the 1539 default Page 0 and in Page 1. The resulting packet to the 1540 destination is the inner packet compressed with [RFC6282]. 1542 Authors' Addresses 1544 Pascal Thubert (editor) 1545 Cisco Systems, Inc 1546 Building D 1547 45 Allee des Ormes - BP1200 1548 06254 Mougins - Sophia Antipolis 1549 France 1551 Phone: +33 497 23 26 34 1552 Email: pthubert@cisco.com 1554 Michael C. Richardson 1555 Sandelman Software Works 1557 Email: mcr+ietf@sandelman.ca 1558 URI: http://www.sandelman.ca/