idnits 2.17.1 draft-ietf-roll-unaware-leaves-21.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 (30 September 2020) is 1303 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-40 -- 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: 3 April 2021 30 September 2020 8 Routing for RPL Leaves 9 draft-ietf-roll-unaware-leaves-21 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 in 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 3 April 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 54 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 7 57 4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 8 58 4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 8 59 4.2. RFC 8505 Extended Address Registration . . . . . . . . . 8 60 4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 9 62 4.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 10 64 4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 10 65 5. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11 66 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11 67 5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 11 68 5.3. Support of the HbH Header . . . . . . . . . . . . . . . . 12 69 5.4. Support of the Routing Header . . . . . . . . . . . . . . 12 70 6. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 12 71 6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 13 72 6.2. Updated DODAG Configuration Option . . . . . . . . . . . 14 73 6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 15 74 7. Updating draft-ietf-roll-efficient-npdao . . . . . . . . . . 16 75 8. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 16 76 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 16 77 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 17 78 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 19 79 9.2.1. Perspective of the RUL Acting as 6LN . . . . . . . . 19 80 9.2.2. Perspective of the Border Router Acting as 6LR . . . 20 81 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 23 82 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 23 83 10. Protocol Operations for Multicast Addresses . . . . . . . . . 24 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 12.1. Fixing the Address Registration Option Flags . . . . . . 26 87 12.2. Resizing the ARO Status values . . . . . . . . . . . . . 26 88 12.3. New DODAG Configuration Option Flag . . . . . . . . . . 27 89 12.4. New RPL Target Option Flag . . . . . . . . . . . . . . . 27 90 12.5. New Subregistry for the RPL Non-Rejection Status 91 values . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 12.6. New Subregistry for the RPL Rejection Status values . . 28 93 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 94 14. Normative References . . . . . . . . . . . . . . . . . . . . 28 95 15. Informative References . . . . . . . . . . . . . . . . . . . 31 96 Appendix A. Example Compression . . . . . . . . . . . . . . . . 32 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 99 1. Introduction 101 The design of Low Power and Lossy Networks (LLNs) is generally 102 focused on saving energy, which is the most constrained resource of 103 all. Other design constraints, such as a limited memory capacity, 104 duty cycling of the LLN devices and low-power lossy transmissions, 105 derive from that primary concern. 107 The IETF produced the "Routing Protocol for Low Power and Lossy 108 Networks" [RFC6550] (RPL) to provide IPv6 [RFC8200] routing services 109 within such constraints. RPL belongs to the class of Distance-Vector 110 protocols, which, compared to link-state protocols, limit the amount 111 of topological knowledge that needs to be installed and maintained in 112 each node, and does not require convergence to avoid micro-loops. 114 To save signaling and routing state in constrained networks, RPL 115 allows a path stretch (see [RFC6687]), whereby routing is only 116 performed along a Destination-Oriented Directed Acyclic Graph (DODAG) 117 that is optimized to reach a Root node, as opposed to along the 118 shortest path between 2 peers, whatever that would mean in a given 119 LLN. This trades the quality of peer-to-peer (P2P) paths for a 120 vastly reduced amount of control traffic and routing state that would 121 be required to operate an any-to-any shortest path protocol. 122 Additionally, broken routes may be fixed lazily and on-demand, based 123 on dataplane inconsistency discovery, which avoids wasting energy in 124 the proactive repair of unused paths. 126 For many of the nodes, though not all, the 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 RPL can be deployed in conjunction with IPv6 Neighbor Discovery (ND) 136 [RFC4861] [RFC4862] and 6LoWPAN ND [RFC6775] [RFC8505] to maintain 137 reachability within a Non-Broadcast Multi-Access (NBMA) Multi-Link 138 subnet. 140 In that mode, IPv6 addresses are advertised individually as Host 141 routes. Some nodes may act as Routers and participate to the 142 forwarding operations whereas others will only terminate packets, 143 acting as Hosts in the data-plane. In [RFC6550] terms, an IPv6 Host 144 [RFC8504] that is reachable over the RPL network is called a Leaf. 146 [USEofRPLinfo] introduces the terms RPL-Aware-Leaf (RAL) and RPL- 147 Unaware Leaf (RUL). A RAL is a Leaf that injects Host routes in RPL 148 to manage the reachability of its IPv6 addresses. Conversely, a RUL 149 does not participate to RPL and cannot inject its Host routes in RPL. 150 The RUL therefore needs a Host-to-Router interface to advertise its 151 IPv6 addresses to its access Router so the Router can inject them the 152 RPL network on its behalf. Section 5 details the interface needed by 153 a router that implements this specification. 155 This specification leverages the Address Registration mechanism 156 defined in 6LoWPAN ND to enable a RUL acting as a 6LoWPAN Node (6LN) 157 to interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) and 158 request that the 6LR injects a Host route for the Registered Address 159 in the RPL routing on its behalf. A RUL may be unable to participate 160 because it is very energy-constrained, or because it is unsafe to let 161 it inject routes in RPL, in which case using 6LowPAN ND as the 162 interface for the RUL limits the surface of the possible attacks and 163 optionally protects the address ownership. 165 The RPL Non-Storing Mode mechanism is used to extend the routing 166 state with connectivity to the RULs even when the DODAG is operated 167 in Storing Mode. The unicast packet forwarding operation by the 6LR 168 serving a RUL is described in section 4.1 of [USEofRPLinfo]. 170 Examples of possible RULs include lightly powered sensors such as 171 window smash sensor (alarm system), and kinetically powered light 172 switches. Other applications of this specification may include a 173 smart grid network that controls appliances - such as washing 174 machines or the heating system - in the home. Appliances may not 175 participate to the RPL protocol operated in the Smartgrid network but 176 can still interact with the Smartgrid for control and/or metering. 178 This document is organized as follows: 180 * Section 3 and Section 4 present salient aspects of RPL and 6LoWPAN 181 ND, respectively, that are leveraged in this specification to 182 provide connectivity to a RUL across a RPL network. 184 * Section 5 lists the expectations that a RUL needs to match in 185 order to be served by a RPL router that complies with this 186 specification. 188 * Section 6, Section 7, and Section 8 present the additions made to 189 [RFC6550], [EFFICIENT-NPDAO], and [RFC8505]. 191 * Section 9 and Section 10 present the operation of this 192 specification for unicast and multicast flows, respectively, and 193 Section 11 presents associated security considerations. 195 2. Terminology 197 2.1. Requirements Language 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 2.2. Glossary 207 This document often uses the following acronyms: 209 AR: Address Resolution (aka Address Lookup) 210 ARQ: Automatic Repeat reQuest 211 6CIO: 6LoWPAN Capability Indication Option 212 6LN: 6LoWPAN Node (a Low Power Host or Router) 213 6LR: 6LoWPAN Router 214 (E)ARO: (Extended) Address Registration Option 215 (E)DAR: (Extended) Duplicate Address Request 216 (E)DAC: (Extended) Duplicate Address Confirmation 217 DAD: Duplicate Address Detection 218 DAO: Destination Advertisement Object (a RPL message) 219 DCO: Destination Cleanup Object (a RPL message) 220 DIS: DODAG Information solicitation (a RPL message) 221 DIO: DODAG Information Object (a RPL message) 222 DODAG: Destination-Oriented Directed Acyclic Graph 223 LLN: Low-Power and Lossy Network 224 NA: Neighbor Advertisement 225 NCE: Neighbor Cache Entry 226 ND: Neighbor Discovery 227 NS: Neighbor solicitation 228 RA: Router Advertisement 229 ROVR: Registration Ownership Verifier 230 RPI: RPL Packet Information 231 RAL: RPL-Aware Leaf 232 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) 233 RUL: RPL-Unaware Leaf 234 TID: Transaction ID (a sequence counter in the EARO) 236 2.3. References 238 The Terminology used in this document is consistent with and 239 incorporates that described in "Terms Used in Routing for Low-Power 240 and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical 241 6LoWPAN acronyms is given in Section 2.2. Other terms in use in LLNs 242 are found in "Terminology for Constrained-Node Networks" [RFC7228]. 243 This specification uses the terms 6LN and 6LR to refer specifically 244 to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does 245 not expect other functionality such as 6LoWPAN Header Compression 246 [RFC6282] from those nodes. 248 "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by 249 a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for 250 Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract 251 information that RPL defines to be placed in data packets, e.g., as 252 the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By 253 extension, the term "RPI" is often used to refer to the RPL Option 254 itself. The DODAG Information solicitation (DIS), Destination 255 Advertisement Object (DAO) and DODAG Information Object (DIO) 256 messages are also specified in [RFC6550]. The Destination Cleanup 257 Object (DCO) message is defined in [EFFICIENT-NPDAO]. 259 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 260 Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node 261 (RAN) is introduced to refer to a node that is either an RAL or a RPL 262 Router. As opposed to a RUL, a RAN manages the reachability of its 263 addresses and prefixes by injecting them in RPL by itself. 265 In this document, readers will encounter terms and concepts that are 266 discussed in the following documents: 268 Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861] 269 and "IPv6 Stateless Address Autoconfiguration" [RFC4862], 271 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power 272 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and 273 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 274 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 275 and 277 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 278 Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor 279 Discovery" [RFC8505], and "Address Protected Neighbor Discovery 280 for Low-power and Lossy Networks" [AP-ND]. 282 3. RPL External Routes and Dataplane Artifacts 284 Section 4.1 of [USEofRPLinfo] provides a set of rules detailed below 285 that MUST be followed for routing packets from and to a RUL. 287 A 6LR that acts as a border Router for external routes advertises 288 them using Non-Storing Mode DAO messages that are unicast directly to 289 the Root, even if the DODAG is operated in Storing Mode. Non-Storing 290 Mode routes are not visible inside the RPL domain and all packets are 291 routed via the Root. The RPL Root tunnels the packets directly to 292 the 6LR that advertised the external route, which decapsulates and 293 forwards the original (inner) packet. 295 The RPL Non-Storing MOP signaling and the associated IP-in-IP 296 encapsulated packets appear as normal traffic to the intermediate 297 Routers. The support of external routes only impacts the Root and 298 the 6LR. It can be operated with legacy intermediate Routers and 299 does not add to the amount of state that must be maintained in those 300 Routers. A RUL is an example of a destination that is reachable via 301 an external route that happens to be also a Host route. 303 The RPL data packets always carry a Hop-by-Hop Header to transport a 304 RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates 305 its packets with an RPI, the 6LR needs to tunnel them to the Root to 306 add the RPI. As a rule of a thumb and except for the very special 307 case above, the packets from and to a RUL are always encapsulated 308 using an IP-in-IP tunnel between the Root and the 6LR that serves the 309 RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 310 8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details). 312 In Non-Storing Mode, packets going down carry a Source Routing Header 313 (SRH). The IP-in-IP encapsulation, the RPI and the SRH are 314 collectively called the "RPL artifacts" and can be compressed using 315 [RFC8138]. Figure 11 presents an example compressed format for a 316 packet forwarded by the Root to a RUL in a Storing Mode DODAG. 318 The inner packet that is forwarded to the RUL may carry some RPL 319 artifacts, e.g., an RPI if the original packet was generated with it, 320 and an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the 321 RUL to support the basic "IPv6 Node Requirements" [RFC8504]. In 322 particular the RUL is expected to ignore the RPL artifacts that are 323 either consumed or not applicable to a Host. 325 A RUL is not expected to support the compression method defined in 326 [RFC8138]. Unless configured otherwise, the border Router MUST 327 restore the outgoing packet before forwarding over an external route, 328 even if it is not the destination of the incoming packet, and even 329 when delivering to a RUL. 331 4. 6LoWPAN Neighbor Discovery 333 4.1. RFC 6775 Address Registration 335 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 336 [RFC4862] was defined for serial links and transit media such as 337 Ethernet. It is a reactive protocol that relies heavily on multicast 338 operations for address discovery (aka lookup) and duplicate address 339 detection (DAD). 341 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 342 adapts IPv6 ND for operations over energy-constrained LLNs. The main 343 functions of [RFC6775] are to proactively establish the Neighbor 344 Cache Entry (NCE) in the 6LR and to prevent address duplication. To 345 that effect, [RFC6775] introduces a new unicast Address Registration 346 mechanism that contributes to reducing the use of multicast messages 347 compared to the classical IPv6 ND protocol. 349 [RFC6775] defines a new Address Registration Option (ARO) that is 350 carried in the unicast Neighbor solicitation (NS) and Neighbor 351 Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 352 6LoWPAN Router (6LR). It also defines the Duplicate Address Request 353 (DAR) and Duplicate Address Confirmation (DAC) messages between the 354 6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the 355 central repository of all the Registered Addresses in its domain and 356 the source of truth for uniqueness and ownership. 358 4.2. RFC 8505 Extended Address Registration 360 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 361 updates the behavior of RFC 6775 to enable a generic Address 362 Registration to services such as routing and ND proxy, and defines 363 the Extended Address Registration Option (EARO) as shown in Figure 1: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Length | Status | Opaque | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Rsvd | I |R|T| TID | Registration Lifetime | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 ... Registration Ownership Verifier ... 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 1: EARO Option Format 379 4.2.1. R Flag 381 [RFC8505] introduces the "R" flag in the EARO. The Registering Node 382 sets the "R" flag to indicate whether the 6LR should ensure 383 reachability for the Registered Address. If the "R" flag is not set, 384 then the Registering Node handles the reachability of the Registered 385 Address by other means. In a RPL network, this means that either it 386 is a RAN that injects the route by itself or that it uses another RPL 387 Router for reachability services. 389 This document specifies how the "R" flag is used in the context of 390 RPL. A RPL Leaf that implements the 6LN functionality in [RFC8505] 391 requires reachability services for an IPv6 address if and only if it 392 sets the "R" flag in the NS(EARO) used to register the address to a 393 RPL border Router acting as 6LR. Upon receiving the NS(EARO), the 394 RPL Router generates a DAO message for the Registered Address if and 395 only if the "R" flag is set. More in Section 9.2. 397 4.2.2. TID, I Field and Opaque Fields 399 When the "T" flag is set, the EARO includes a sequence counter called 400 Transaction ID (TID), that is needed to fill the Path Sequence Field 401 in the RPL Transit Option. This is the reason why the support of 402 [RFC8505] by the RUL, as opposed to only [RFC6775] is a prerequisite 403 for this specification (more in Section 5.1). The EARO also 404 transports an Opaque field and an associated "I" field that describes 405 what the Opaque field transports and how to use it. Section 9.2.1 406 specifies the use of the "I" field and the Opaque field by a RUL. 408 4.2.3. ROVR 410 Section 5.3 of [RFC8505] introduces the Registration Ownership 411 Verifier (ROVR) field of variable length from 64 to 256 bits. The 412 ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was 413 used to identify uniquely an Address Registration with the Link-Layer 414 address of the owner but provided no protection against spoofing. 416 "Address Protected Neighbor Discovery for Low-power and Lossy 417 Networks" [AP-ND] leverages the ROVR field as a cryptographic proof 418 of ownership to prevent a rogue third party from misusing the 419 address. [AP-ND] adds a challenge/response exchange to the [RFC8505] 420 Address Registration and enables Source Address Validation by a 6LR. 422 This specification does not address how the protection by [AP-ND] 423 could be extended for the use of RPL. On the other hand, it adds the 424 ROVR to the DAO to build the proxied EDAR at the Root (see 425 Section 6.1), which means that nodes that are aware of the Host route 426 are also aware of the ROVR associated to the Target Address. 428 4.3. RFC 8505 Extended DAR/DAC 430 [RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to 431 carry the ROVR field. The EDAR/EDAC exchange takes place between the 432 6LR and the 6LBR. It is triggered by an NS(EARO) message from a 6LN 433 to create, refresh, and delete the corresponding state in the 6LBR. 434 The exchange is protected by the retry mechanism (ARQ) specified in 435 8.2.6 of [RFC6775], though in an LLN, a duration longer than the 436 RETRANS_TIMER [RFC4861] of 1 second may be necessary to cover the 437 Turn Around Trip delay between the 6LR and the 6LBR. 439 RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to 440 the Root that maintains the routing state in the RPL network for the 441 lifetime indicated by the source of the DAO. This means that for 442 each address, there are two keep-alive messages that traverse the 443 whole network, one to the Root and one to the 6LBR. 445 This specification avoids the periodic EDAR/EDAC exchange across the 446 LLN. The 6LR turns the periodic NS(EARO) from the RUL into a DAO 447 message to the Root on every refresh, but it only generates the EDAR 448 upon the first registration, for the purpose of DAD, which must be 449 verified before the address is injected in RPL. Upon the DAO 450 message, the Root proxies the EDAR exchange to refresh the state at 451 the 6LBR on behalf of the 6LR, as illustrated in Figure 8. 453 4.3.1. RFC 7400 Capability Indication Option 455 "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power 456 Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the 457 6LoWPAN Capability Indication Option (6CIO) that enables a node to 458 expose its capabilities in Router Advertisement (RA) messages. 459 [RFC8505] defines a number of bits in the 6CIO, in particular: 461 L: Node is a 6LR. 462 E: Node is an IPv6 ND Registrar -- i.e., it supports registrations 463 based on EARO. 464 P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that 465 also provides reachability services for the Registered Address. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type | Length = 1 | Reserved |D|L|B|P|E|G| 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Reserved | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 2: 6CIO flags 477 A 6LR that can provide reachability services for a RUL in a RPL 478 network as specified in this document MUST include a 6CIO in its RA 479 messages and set the L, P and E flags as prescribed by [RFC8505]. 481 5. Requirements on the RPL-Unware Leaf 483 This document provides RPL routing for a RUL. This section describes 484 the minimal RPL-independent functionality that the RUL needs to 485 implement to obtain routing services for its addresses. 487 5.1. Support of 6LoWPAN ND 489 To obtain routing services from a Router that implements this 490 specification, a RUL needs to implement [RFC8505] and set the "R" and 491 "T" flags in the EARO as discussed in Section 4.2.1 and 492 Section 4.2.3, respectively. The RUL is expected not to request 493 routing services from a Router that does not originate RA messages 494 with a CIO that has the L, P, and E flags all set as discussed in 495 Section 4.3.1, unless configured to do so. It is suggested that the 496 RUL also implements [AP-ND] to protect the ownership of its 497 addresses. 499 A RUL that may attach to multiple 6LRs is expected to prefer those 500 that provide routing services. The RUL needs to register to all the 501 6LRs from which it desires routing services. 503 Parallel Address Registrations to several 6LRs should be performed in 504 an rapid sequence, using the exact same EARO for the same Address. 505 Gaps between the Address Registrations will invalidate some of the 506 routes till the Address Registration finally shows on those routes. 508 [RFC8505] introduces error Status values in the NA(EARO) which can be 509 received synchronously upon an NS(EARO) or asynchronously. The RUL 510 needs to support both cases and should refrain from using the address 511 when the Status Value indicates a rejection. 513 5.2. Support of IPv6 Encapsulation 515 Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either 516 to the final destination (e.g., a RUL) or to its attachment Router 517 (designated as 6LR). To terminate the IP-in-IP tunnel, the RUL, as 518 an IPv6 Host, must be able to decapsulate the tunneled packet and 519 either drop the inner packet if it is not the final destination, or 520 pass it to the upper layer for further processing. Unless it is 521 aware by other means that the RUL can handle IP-in-IP properly, which 522 is not mandated by [RFC8504], the Root terminates the IP-in-IP tunnel 523 at the parent 6LR. It is thus not necessary for a RUL to support IP- 524 in-IP decapsulation. 526 5.3. Support of the HbH Header 528 A RUL is expected to process an Option Type in a Hop-by-Hop Header as 529 prescribed by section 4.2 of [RFC8200]. An RPI with an Option Type 530 of 0x23 [USEofRPLinfo] is thus skipped when not recognized. 532 5.4. Support of the Routing Header 534 A RUL is expected to process an unknown Routing Header Type as 535 prescribed by section 4.4 of [RFC8200]. This implies that the Source 536 Routing Header with a Routing Type of 3 [RFC6554] is ignored when the 537 Segments Left is zero, and the packet is dropped otherwise. 539 6. Updating RFC 6550 541 This document specifies a new behavior whereby a 6LR injects DAO 542 messages for unicast addresses (see Section 9) and multicast 543 addresses (see Section 10) on behalf of leaves that are not aware of 544 RPL. The RUL addresses are exposed as external targets [RFC6550]. 545 Conforming to [USEofRPLinfo], an IP-in-IP encapsulation between the 546 6LR and the RPL Root is used to carry the RPL artifacts and remove 547 them when forwarding outside the RPL domain, e.g., to a RUL. 549 This document also synchronizes the liveness monitoring at the Root 550 and the 6LBR. The same value of lifetime is used for both, and a 551 single keep-alive message, the RPL DAO, traverses the RPL network. A 552 new behavior is introduced whereby the RPL Root proxies the EDAR 553 message to the 6LBR on behalf of the 6LR (more in Section 8), for any 554 Leaf node that implements the 6LN functionality in [RFC8505]. 556 Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which 557 can be used in RPL Control messages such as the DAO message to signal 558 a destination prefix. Section 6.1 adds the capabilities to transport 559 the ROVR field (see Section 4.2.3) and the full IPv6 Address of the 560 prefix advertiser when the Target is a shorter prefix, signaled by a 561 new "F" flag. The position of the "F" flag is indicated in 562 Section 12.4. 564 This specification defines the new "Root Proxies EDAR/EDAC" (P) flag 565 and encodes it in one of these reserved flags of the the RPL DODAG 566 Configuration option , more in Section 6.2. The position of the "P" 567 flag is indicated in Section 12.3. 569 The RPL Status defined in section 6.5.1 of [RFC6550] for use in the 570 DAO-ACK message is extended to be placed in DCO messages 571 [EFFICIENT-NPDAO] as well. Furthermore, this specification enables 572 to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO 573 messages, embedded in a RPL Status, more in Section 6.3. 575 6.1. Updated RPL Target Option 577 This specification updates the RPL Target Option to transport the 578 ROVR that was also defined for 6LoWPAN ND messages. This enables the 579 RPL Root to generate the proxied EDAR message to the 6LBR. 581 The new "F" flag is set to indicate that the Target Prefix field 582 contains the address of the advertising node in full, in which case 583 the length of the Target Prefix field is 16 bytes regardless of the 584 value of the Prefix Length field. If the "F" flag is reset, the 585 Target Prefix field MUST be aligned to the next byte boundary after 586 the size (expressed in bits) indicated by the Prefix Length field. 587 Padding bits are reserved and set to 0 as prescribed by section 6.7.7 588 of [RFC6550]. 590 With this specification the ROVR is the remainder of the RPL Target 591 Option. The size of the ROVR is indicated in a new ROVR Size field 592 that is encoded to map one-to-one with the Code Suffix in the EDAR 593 message (see table 4 of [RFC8505]). 595 The modified format is illustrated in Figure 3. It is backward 596 compatible with the Target Option in [RFC6550] and SHOULD be used as 597 a replacement in new implementations even for Storing Mode operations 598 in preparation for upcoming security mechanisms based in the ROVR. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 | Target Prefix (Variable Length) | 607 . . 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | 610 ... Registration Ownership Verifier (ROVR) ... 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 3: Updated Target Option 616 New fields: 618 ROVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, 619 denoting a ROVR size of 64, 128, 192, or 256 bits, respectively. 621 F: 1-bit flag. Set to indicate that Target Prefix field contains an 622 Address of prefix advertiser in full. 624 Registration Ownership Verifier (ROVR): This is the same field as in 625 the EARO, see [RFC8505] 627 6.2. Updated DODAG Configuration Option 629 The DODAG Configuration Option is defined in Section 6.7.6 of 630 [RFC6550]. Its purpose is extended to distribute configuration 631 information affecting the construction and maintenance of the DODAG, 632 as well as operational parameters for RPL on the DODAG, through the 633 DODAG. As shown in Figure 4, the Option was originally designed with 634 4 bit positions reserved for future use as Flags. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type = 0x04 |Opt Length = 14| |P| | |A| ... | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 641 <- Flags -> 643 Figure 4: DODAG Configuration Option (Partial View) 645 This specification defines a new flag "Root Proxies EDAR/EDAC" (P). 646 The "P" flag is set to indicate support for this specification at the 647 Root within the DODAG. The "P" flag is encoded in position 1 of the 648 reserved Flags in the DODAG Configuration Option (counting from bit 0 649 as the most significant bit) and set to 0 in legacy implementations 650 as specified respectively in Sections 20.14 and 6.7.6 of [RFC6550]. 652 The "P" flag is set to indicate that the Root performs the proxy 653 operation, which implies that it supports the Updated RPL Target 654 Option (see Section 6.1). 656 Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the 657 definition of the Flags applies to Mode of Operation (MOP) values 658 zero (0) to six (6) only. For a MOP value of 7, the Root is expected 659 to perform the proxy operation by default. 661 The RPL DODAG Configuration Option is typically placed in a DODAG 662 Information Object (DIO) message. The DIO message propagates down 663 the DODAG to form and then maintain its structure. The DODAG 664 Configuration Option is copied unmodified from parents to children. 665 [RFC6550] states that "Nodes other than the DODAG Root MUST NOT 666 modify this information when propagating the DODAG Configuration 667 option". Therefore, a legacy parent propagates the "T" flag as set 668 by the Root, and when the "T" flag is set, it is transparently 669 flooded to all the nodes in the DODAG. 671 6.3. Updated RPL Status 673 The RPL Status is defined in section 6.5.1 of [RFC6550] for use in 674 the DAO-ACK message and values are assigned as follows: 676 +---------+--------------------------------+ 677 | Range | Meaning | 678 +---------+--------------------------------+ 679 | 0 | Success/Unqualified acceptance | 680 +---------+--------------------------------+ 681 | 1-127 | Not an outright rejection | 682 +---------+--------------------------------+ 683 | 128-255 | Rejection | 684 +---------+--------------------------------+ 686 Table 1: RPL Status per RFC 6550 688 The 6LoWPAN ND Status was defined for use in the EARO and the 689 currently defined values are listed in table 1 of [RFC8505]. This 690 specification enables to carry the 6LoWPAN ND Status values in RPL 691 DAO and DCO messages, embedded in the RPL Status field. 693 To achieve this, Section 12.2 reduces the range of the EARO Status 694 values to 0-63 to ensure that they fit within a RPL Status as shown 695 in Figure 5. 697 0 1 2 3 4 5 6 7 698 +-+-+-+-+-+-+-+-+ 699 |E|A| Value | 700 +-+-+-+-+-+-+-+-+ 702 Figure 5: RPL Status Format 704 The following RPL Status subfields are defined: 706 E: 1-bit flag. Set to indicate a rejection. When not set, a value 707 of 0 indicates Success/Unqualified acceptance and other values 708 indicate "not an outright rejection" as per RFC 6550. 710 A: 1-bit flag. Indicates the type of the Status Value. 712 Status Value: 6-bit unsigned integer. If the 'A' flag is set this 713 field transports a Status Value defined for IPv6 ND EARO. When 714 the 'A' flag is not set, the Status Value is defined for RPL. 716 When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC 717 message, the RPL Root MUST copy the 6LoWPAN ND Status unchanged in 718 the RPL Status and set the 'A' bit. The RPL Root MUST set the 'E' 719 flag for Values in range 1-10 which are all considered rejections. 721 Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with 722 a RPL Status that has the 'A' bit set, the 6LR MUST copy the RPL 723 Status Value unchanged in the Status field of the EARO when 724 generating an NA to the RUL. 726 7. Updating draft-ietf-roll-efficient-npdao 728 [EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with a 729 link-local scope. This specification extends its use to the Non- 730 Storing MOP, whereby the DCO is sent unicast by the Root directly to 731 the RAN that injected the DAO message for the considered target. 733 This specification leverages the DCO between the Root and the 6LR 734 that serves as attachment Router for a RUL. 736 8. Updating RFC 8505 738 This document updates [RFC8505] to change the behavior of a RPL 739 Router acting as 6LR and of a RUL acting as 6LN in the 6LoWPAN ND 740 Address Registration. If the RPL Root advertise the capability to 741 proxy the EDAR/EDAC exchange to the 6LBR, the 6LR refrains from 742 sending the keep-alive EDAR message. Instead, if it is separated 743 from the 6LBR, the Root regenerates the EDAR message to the 6LBR 744 periodically, upon a DAO message that signals the liveliness of the 745 Address. 747 9. Protocol Operations for Unicast Addresses 749 The description below assumes that the Root sets the "P" flag in the 750 DODAG Configuration Option and performs the EDAR proxy operation. 752 If the "P" flag is reset, the 6LR MUST generate the periodic EDAR 753 messages and process the returned status as specified in [RFC8505]. 754 If the EDAC indicates success, the rest of the flow takes place as 755 presented but without the proxied EDAR/EDAC exchange. 757 9.1. General Flow 759 This specification eliminates the need to exchange keep-alive 760 Extended Duplicate Address messages, EDAR and EDAC, all the way from 761 a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange 762 with the 6LBR is proxied by the RPL Root upon the DAO message that 763 refreshes the RPL routing state. The first EDAR upon a new 764 Registration cannot be proxied, though, as it serves for the purpose 765 of DAD, which must be verified before the address is injected in RPL. 767 In a RPL network where the function is enabled, refreshing the state 768 in the 6LBR is the responsibility of the Root. Consequently, only 769 addresses that are injected in RPL will be kept alive at the 6LBR by 770 the RPL Root. 772 Since RULs are advertised using Non-Storing Mode, the DAO message 773 flow and the keep alive EDAR/EDAC can be nested within the Address 774 (re)Registration flow. Figure 6 illustrates that for the first 775 Registration, both the DAD and the keep-alive EDAR/EDAC exchanges 776 happen in the same sequence. 778 6LN/RUL 6LR Root 6LBR 779 | | | | 780 | NS(EARO) | | | 781 |--------------->| | 782 | | Extended DAR | 783 | |--------------------------------->| 784 | | | 785 | | Extended DAC | 786 | |<---------------------------------| 787 | | DAO | | 788 | |------------->| | 789 | | | EDAR | 790 | | |------------------>| 791 | | | EDAC | 792 | | |<------------------| 793 | | DAO-ACK | | 794 | |<-------------| | 795 | NA(EARO) | | | 796 |<---------------| | | 797 | | | | 799 Figure 6: First RUL Registration Flow 801 To achieve this, the lifetimes and sequence counters in 6LoWPAN ND 802 and RPL are aligned. In other words, the Path Sequence and the Path 803 Lifetime in the DAO message are taken from the Transaction ID and the 804 Address Registration lifetime in the NS(EARO) message from the 6LN. 806 On the first Address Registration, illustrated in Figure 6 for RPL 807 Non-Storing Mode, the Extended Duplicate Address exchange takes place 808 as prescribed by [RFC8505]. If the exchange fails, the 6LR returns 809 an NA message with a negative status to the 6LN, the NCE is not 810 created and the address is not injected in RPL. If it is successful, 811 the 6LR creates an NCE and injects the Registered Address in the RPL 812 routing using a DAO/DAO-ACK exchange with the RPL DODAG Root. 814 An issue may be detected later, e.g., the address moves within the 815 LLN or to a different Root on a backbone [6BBR]. In that case the 816 value of the status that indicates the issue can be passed from 817 6LoWPAN ND to RPL and back as illustrated in Figure 7. 819 6LN/RUL 6LR Root 6LBR 820 | | | | 821 | | | NA(EARO, Status) | 822 | | |<-----------------| 823 | | DCO(Status) | | 824 | |<------------| | 825 | NA(EARO, Status) | | | 826 |<-----------------| | | 827 | | | | 829 Figure 7: Asynchronous Issue 831 An Address re-Registration is performed by the 6LN to maintain the 832 NCE in the 6LR alive before lifetime expires. Upon the refresh of an 833 Address re-Registration, as illustrated in Figure 8, the 6LR injects 834 the Registered Address in RPL. 836 6LN/RUL 6LR Root 6LBR 837 | | | | 838 | NS(EARO) | | | 839 |--------------->| | 840 | | DAO | | 841 | |------------->| | 842 | | | EDAR | 843 | | |------------------>| 844 | | | EDAC | 845 | | |<------------------| 846 | | DAO-ACK | | 847 | |<-------------| | 848 | NA(EARO) | | | 849 |<---------------| | | 851 Figure 8: Next RUL Registration Flow 853 This is what causes the RPL Root to refresh the state in the 6LBR, 854 using an EDAC message. In case of an error in the proxied EDAR flow, 855 the error is returned in the DAO-ACK using a RPL Status with the 'A' 856 flag set that imbeds a 6LoWPAN Status Value as discussed in 857 Section 6.3. 859 The 6LR may receive a requested DAO-ACK after it received an 860 asynchronous DCO, but the negative Status in the DCO supersedes a 861 positive Status in the DAO-ACK regardless of the order in which they 862 are received. Upon the DAO-ACK - or the DCO if one arrives first - 863 the 6LR responds to the RUL with an NA(EARO). 865 The RUL MAY terminate the registration at any time by using a 866 Registration Lifetime of 0. This specification requires that the RPL 867 Target Option transports the ROVR. This way, the same flow as the 868 heartbeat flow is sufficient to inform the 6LBR using the Root as 869 proxy as illustrated in Figure 8. 871 Any combination of the logical functions of 6LR, Root and 6LBR might 872 be collapsed in a single node. 874 9.2. Detailed Operation 876 9.2.1. Perspective of the RUL Acting as 6LN 878 This specification does not alter the operation of a 6LoWPAN ND- 879 compliant 6LN, and a RUL is expected to operate as follows: 881 1. The 6LN obtains an IPv6 global address, either using Stateless 882 Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix 883 Information Option (PIO) [RFC4861] found in an RA message, or 884 some other means such as DHCPv6 [RFC3315]. 886 2. Once it has formed an address, the 6LN (re)registers its address 887 periodically, within the Lifetime of the previous Address 888 Registration, as prescribed by [RFC6775], to refresh the NCE 889 before the lifetime indicated in the EARO expires. It MUST set 890 the "T" flag and the TID is incremented each time and wraps in a 891 lollipop fashion (see section 5.2.1 of [RFC8505] which is fully 892 compatible with section 7.2 of [RFC6550]). 894 3. As stated in section 5.2 of [RFC8505], the 6LN can register to 895 more than one 6LR at the same time. In that case, it uses the 896 same EARO for all of the parallel Address Registrations. The 6LN 897 SHOULD send the registration(s) that have a non-zero Registration 898 Lifetime and ensure that one succeeds before it terminates other 899 registrations, to maintain the state in the network and at the 900 6LBR and minimize the churn. 902 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets 903 the "R" flag in the EARO of at least one registration, whereas 904 acting as a RAN it never does. If the "R" flag is not echoed in 905 the NA, the RUL SHOULD attempt to use another 6LR. The RUL 906 SHOULD send the registration(s) with the "R" flag set and ensure 907 that one succeeds before it sends the registrations with the flag 908 reset. In case of a conflict with the preceeding rule on 909 lifetime, the rule on lifetime has precedence. 911 5. The 6LN may use any of the 6LRs to which it registered as default 912 gateway. Using a 6LR to which the 6LN is not registered may 913 result in packets dropped at the 6LR by a Source Address 914 Validation function (SAVI) so it is NOT RECOMMENDED. 916 Even without support for RPL, a RUL may be aware of opaque values to 917 be provided to the routing protocol. If the RUL has a knowledge of 918 the RPL Instance the packet should be injected into, then it SHOULD 919 set the Opaque field in the EARO to the RPLInstanceID, else it MUST 920 leave the Opaque field to zero. 922 Regardless of the setting of the Opaque field, the 6LN MUST set the 923 "I" field to zero to signal "topological information to be passed to 924 a routing process" as specified in section 5.1 of [RFC8505]. 926 A RUL is not expected to produce RPL artifacts in the data packets, 927 but it MAY do so. For instance, if the RUL has a minimal awareness 928 of the RPL Instance then it can build an RPI. A RUL that places an 929 RPI in a data packet MUST indicate the RPLInstanceID of the RPL 930 Instance where the packet should be forwarded. All the flags and the 931 Rank field are set to zero as specified by section 11.2 of [RFC6550]. 933 9.2.2. Perspective of the Border Router Acting as 6LR 935 Also as prescribed by [RFC8505], the 6LR generates an EDAR message 936 upon reception of a valid NS(EARO) message for the registration of a 937 new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange 938 succeeds, then the 6LR installs an NCE for the Registration Lifetime. 939 For the registration refreshes, if the RPL Root has indicated that it 940 proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see 941 Section 6), the 6LR MUST refrain from sending the keep-alive EDAR. 943 If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host 944 route in RPL, unless this is barred for other reasons, such as the 945 saturation of the RPL parents. The 6LR MUST use a RPL Non-Storing 946 Mode signaling and the updated Target Option (see Section 6.1). The 947 6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO 948 message. Success injecting the route to the RUL is indicated by the 949 'E' flag set to 0 in the RPL status of the DAO-ACK message. 951 The Opaque field in the EARO hints the 6LR on the RPL Instance that 952 SHOULD be used for the DAO advertisements, and for the forwarding of 953 packets sourced at the registered address when there is no RPI in the 954 packet, in which case the 6LR MUST encapsulate the packet to the Root 955 adding an RPI in the outer header. If the Opaque field is zero, the 956 6LR is free to use the default RPL Instance (zero) for the registered 957 address or to select an Instance of its choice. 959 If the "I" field is not zero, then the 6LR MUST consider that the 960 Opaque field is zero. If the Opaque field is not zero, then it is 961 expected to carry a RPLInstanceID for the RPL Instance suggested by 962 the 6LN. If the 6LR does not participate to the associated Instance, 963 then the 6LR MUST consider that the Opaque field is zero; else, that 964 is if the 6LR participates to the suggested RPL Instance, then the 965 6LR SHOULD use that Instance for the Registered Address. 967 The DAO message advertising the Registered Address MUST be 968 constructed as follows: 970 1. The Registered Address is signaled as Target Prefix in the 971 updated Target Option in the DAO message; the Prefix Length is 972 set to 128. The ROVR field is copied unchanged from the EARO 973 (see Section 6.1). 975 2. The 6LR indicates one of its global or unique-local IPv6 unicast 976 addresses as the Parent Address in the RPL Transit Information 977 Option (TIO) associated with the Target Option 979 3. The 6LR sets the External 'E' flag in the TIO to indicate that it 980 redistributes an external target into the RPL network 982 4. the Path Lifetime in the TIO is computed from the Lifetime in the 983 EARO Option. This adapts it to the Lifetime Units used in the 984 RPL operation; note that if the lifetime is 0, then the DAO 985 message is a No-Path DAO that cleans up the the routes down to 986 the RUL; this also causes the Root as a proxy to send an EDAR 987 message to the 6LBR with a Lifetime of 0. 989 5. the Path Sequence in the TIO is set to the TID value found in the 990 EARO option. 992 Upon receiving the DAO-ACK or an asynchronous DCO message, the 6LR 993 MUST send the NA(EARO) to the RUL. 995 The 6LR MUST set "R" flag in the NA(EARO) back if and only if the 'E' 996 flag is reset, indicating that the 6LR injected the Registered 997 Address in the RPL routing successfully and that the EDAR proxy 998 operation succeeded. 1000 If the 'A' flag in the RPL Status is set, the embedded Status Value 1001 is passed back to the RUL in the EARO Status. If the 'E' flags is 1002 also set, the registration failed for 6LoWPAN ND related reasons, and 1003 the NCE is removed. 1005 If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the 1006 6LoWPAN ND operation succeeded and an EARO Status of 0 (Success) MUST 1007 be returned to the RUL, even if the 'E' flag is set in the RPL 1008 Status. The EARO Status of 0 MUST also be used if the 6LR could not 1009 even try to inject the route. 1011 This means that, in case of an error injecting the route that is not 1012 related to ND, the registration succeeds but the RPL route is not 1013 installed, which is signaled by the "R" flag reset. It is up to the 1014 6LN to keep the binding with the 6LR or destroy it. 1016 In a network where Address Protected Neighbor Discovery (AP-ND) is 1017 enabled, in case of a DAO-ACK or a DCO indicating transporting an 1018 EARO Status Value of 5 (Validation Requested), the 6LR MUST challenge 1019 the 6LN for ownership of the address, as described in section 6.1 of 1020 [AP-ND], before the Registration is complete. This ensures that the 1021 address is validated before it is injected in the RPL routing. 1023 If the challenge succeeds then the operations continue as normal. In 1024 particular a DAO message is generated upon the NS(EARO) that proves 1025 the ownership of the address. If the challenge failed, the 6LR 1026 rejects the registration as prescribed by AP-ND and may take actions 1027 to protect itself against DoS attacks by a rogue 6LN, see Section 11. 1029 The 6LR may at any time send a unicast asynchronous NA(EARO) with the 1030 "R" flag reset to signal that it stops providing routing services, 1031 and/or with the EARO Status 2 "Neighbor Cache full" to signal that it 1032 removes the NCE. It may also send a final RA, unicast or multicast, 1033 with a Router Lifetime field of zero, to signal that it stops serving 1034 as Router, as specified in section 6.2.5 of [RFC4861]. 1036 If a 6LR receives a valid NS(EARO) message with the "R" flag reset 1037 and a Registration Lifetime that is not 0, and the 6LR was injecting 1038 the Registered Address due to previous NS(EARO) messages with the "R" 1039 flag set, then the 6LR MUST stop injecting the address. It is up to 1040 the Registering 6LN to maintain the corresponding route from then on, 1041 either keeping it active via a different 6LR or by acting as a RAN 1042 and managing its own reachability. 1044 9.2.3. Perspective of the RPL Root 1046 A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration 1047 Option of the DIO messages that it generates (see Section 6) to 1048 signal that it proxies the EDAR/EDAC exchange and supports the 1049 Updated RPL Target option. The remainder of this section assumes 1050 that it does. 1052 Upon reception of a DAO message, for each updated RPL Target Option 1053 (see Section 6.1) that creates or updates an existing RPL state, the 1054 Root MUST notify the 6LBR. This can be done using an internal API if 1055 they are integrated, or using a proxied EDAR/EDAC exchange if they 1056 are separate entities. 1058 The EDAR message MUST be constructed as follows: 1060 1. The Target IPv6 address from the RPL Target Option is placed in 1061 the Registered Address field of the EDAR message; 1063 2. the Registration Lifetime is adapted from the Path Lifetime in 1064 the TIO by converting the Lifetime Units used in RPL into units 1065 of 60 seconds used in the 6LoWPAN ND messages; 1067 3. the TID value is set to the Path Sequence in the TIO and 1068 indicated with an ICMP code of 1 in the EDAR message; 1070 4. The ROVR in the RPL Target Option is copied as is in the EDAR and 1071 the ICMP Code Suffix is set to the appropriate value as shown in 1072 Table 4 of [RFC8505] depending on the size of the ROVR field. 1074 Upon receiving an EDAC message from the 6LBR, if a DAO is pending, 1075 then the Root MUST send a DAO-ACK back to the 6LR. Else, if the 1076 Status in the EDAC message is not "Success", then it MUST send an 1077 asynchronous DCO to the 6LR. 1079 In either case, the EDAC Status is embedded in the RPL Status with 1080 the 'A' flag set. 1082 9.2.4. Perspective of the 6LBR 1084 The 6LBR is unaware that the RPL Root is not the new attachment 6LR 1085 of the RUL, so it is not impacted by this specification. 1087 Upon reception of an EDAR message, the 6LBR acts as prescribed by 1088 [RFC8505] and returns an EDAC message to the sender. 1090 10. Protocol Operations for Multicast Addresses 1092 Section 12 of [RFC6550] details the RPL support for multicast flows. 1093 This support is not source-specific and only operates as an extension 1094 to the Storing Mode of Operation for unicast packets. Note that it 1095 is the RPL model that the multicast packet is passed as a Layer-2 1096 unicast to each of the interested children. This remains true when 1097 forwarding between the 6LR and the listener 6LN. 1099 "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its 1100 updated version "Multicast Listener Discovery Version 2 (MLDv2) for 1101 IPv6" [RFC3810] provide an interface for a listener to register to 1102 multicast flows. MLDv2 is backwards compatible with MLD, and adds in 1103 particular the capability to filter the sources via black lists and 1104 white lists. In the MLD model, the Router is a "querier" and the 1105 Host is a multicast listener that registers to the querier to obtain 1106 copies of the particular flows it is interested in. 1108 On the first Address Registration, as illustrated in Figure 9, the 1109 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 1110 order to start receiving the flow immediately. 1112 6LN/RUL 6LR Root 6LBR 1113 | | | | 1114 | unsolicited Report | | | 1115 |------------------->| | | 1116 | | | | 1117 | | DAO | | 1118 | |-------------->| | 1119 | | DAO-ACK | | 1120 | |<--------------| | 1121 | | | | 1122 | | | unsolicited Report | 1123 | | |------------------->| 1124 | | | | 1126 Figure 9: First Multicast Registration Flow 1128 Since multicast Layer-2 messages are avoided, it is important that 1129 the asynchronous messages for unsolicited Report and Done are sent 1130 reliably, for instance using a Layer-2 acknowledgment, or attempted 1131 multiple times. 1133 The 6LR acts as a generic MLD querier and generates a DAO for the 1134 multicast target. The lifetime of the DAO is set to be in the order 1135 of the Query Interval, yet larger to account for variable propagation 1136 delays. 1138 The Root proxies the MLD exchange as a listener with the 6LBR acting 1139 as the querier, so as to get packets from a source external to the 1140 RPL domain. 1142 Upon a DAO with a multicast target, the RPL Root checks if it is 1143 already registered as a listener for that address, and if not, it 1144 performs its own unsolicited Report for the multicast target. 1146 An Address re-Registration is pulled periodically by 6LR acting as 1147 querier. Note that the message may be sent unicast to all the known 1148 individual listeners. 1150 Upon the timing out of the Query Interval, the 6LR sends a Query to 1151 each of its listeners, and gets a Report back that is mapped into a 1152 DAO, as illustrated in Figure 10: 1154 6LN/RUL 6LR Root 6LBR 1155 | | | | 1156 | Query | | | 1157 |<-------------------| | | 1158 | Report | | | 1159 |------------------->| | | 1160 | | | | 1161 | | DAO | | 1162 | |-------------->| | 1163 | | DAO-ACK | | 1164 | |<--------------| | 1165 | | | | 1166 | | | Query | 1167 | | |<-------------------| 1168 | | | Report | 1169 | | |------------------->| 1170 | | | | 1171 | | | | 1173 Figure 10: Next Registration Flow 1175 Note that any of the functions 6LR, Root and 6LBR might be collapsed 1176 in a single node, in which case the flow above happens internally, 1177 and possibly through internal API calls as opposed to messaging. 1179 11. Security Considerations 1181 First of all, it is worth noting that with [RFC6550], every node in 1182 the LLN is RPL-aware and can inject any RPL-based attack in the 1183 network. This specification isolates edge nodes that can only 1184 interact with the RPL Routers using 6LoWPAN ND, meaning that they 1185 cannot perform RPL insider attacks. 1187 6LoWPAN ND can optionally provide SAVI features with [AP-ND], which 1188 reduces even more the attack perimeter that is available to the edge 1189 nodes. 1191 The LLN nodes depend on the 6LBR and the RPL participants for their 1192 operation. A trust model must be put in place to ensure that the 1193 right devices are acting in these roles, so as to avoid threats such 1194 as black-holing, (see [RFC7416] section 7), Denial-Of-Service attacks 1195 whereby a rogue 6LR creates a high churn in the RPL network by 1196 advertising and removing many forged addresses, or bombing attack 1197 whereby an impersonated 6LBR would destroy state in the network by 1198 using the "Removed" Status code. 1200 This trust model could be at a minimum based on a Layer-2 Secure 1201 joining and the Link-Layer security. This is a generic 6LoWPAN 1202 requirement, see Req5.1 in Appendix of [RFC8505]. It is needed in 1203 particular to prevent Denial-Of-Service attacks whereby a rogue 6LN 1204 creates a high churn in the RPL network by constantly registering and 1205 deregistering addresses with the "R" flag set in the EARO. 1207 Additionally, the trust model could include a role validation to 1208 ensure that the node that claims to be a 6LBR or a RPL Root is 1209 entitled to do so. 1211 At the time of this writing RPL does not have a zerotrust model 1212 whereby it is possible to validate the origin of an address that is 1213 injected in a DAO. This specification makes a first step in that 1214 direction by allowing the Root to challenge the RUL via the 6LR that 1215 serves it. 1217 12. IANA Considerations 1219 12.1. Fixing the Address Registration Option Flags 1221 Section 9.1 of [RFC8505] creates a Registry for the 8-bit Address 1222 Registration Option Flags field. IANA is requested to rename the 1223 first column of the table from "ARO Status" to "Bit number". 1225 12.2. Resizing the ARO Status values 1227 Section 12 of [RFC6775] creates the Address Registration Option 1228 Status Values Registry with a range 0-255. 1230 This specification reduces that range to 0-63. 1232 IANA is requested to reduce the upper bound of the unassigned values 1233 in the Address Registration Option Status Values Registry from -255 1234 to -63. 1236 12.3. New DODAG Configuration Option Flag 1238 This specification updates the Registry that was created for 1239 [RFC6550] as the registry for "DODAG Configuration Option Flags" and 1240 updated as the registry for "DODAG Configuration Option Flags for MOP 1241 0..6" by [USEofRPLinfo], by allocating one new Flag as follows: 1243 +------------+----------------------------+-----------+ 1244 | Bit Number | Capability Description | Reference | 1245 +------------+----------------------------+-----------+ 1246 | 1 | Root Proxies EDAR/EDAC (P) | THIS RFC | 1247 +------------+----------------------------+-----------+ 1249 Table 2: New DODAG Configuration Option Flag 1251 12.4. New RPL Target Option Flag 1253 Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL 1254 Target Option Flags" field. IANA is requested to reduce the size of 1255 the field in the Registry to 4 bits. This specification also defines 1256 a new entry in the Registry as follows: 1258 +------------+--------------------------------+-----------+ 1259 | Bit Number | Capability Description | Reference | 1260 +------------+--------------------------------+-----------+ 1261 | 1 | Advertiser Address in Full (F) | THIS RFC | 1262 +------------+--------------------------------+-----------+ 1264 Table 3: New RPL Target Option Flag 1266 12.5. New Subregistry for the RPL Non-Rejection Status values 1268 This specification creates a new Subregistry for the RPL Non- 1269 Rejection Status values for use in RPL DAO-ACK and DCO messages with 1270 the 'A' flag reset, under the ICMPv6 parameters registry. 1272 * Possible values are 6-bit unsigned integers (0..63). 1274 * Registration procedure is "Standards Action" [RFC8126]. 1276 * Initial allocation is as indicated in Table 4: 1278 +-------+------------------------+-----------+ 1279 | Value | Meaning | Reference | 1280 +-------+------------------------+-----------+ 1281 | 0 | Unqualified acceptance | RFC 6550 | 1282 +-------+------------------------+-----------+ 1284 Table 4: Acceptance values of the RPL Status 1286 12.6. New Subregistry for the RPL Rejection Status values 1288 This specification creates a new Subregistry for the RPL Rejection 1289 Status values for use in RPL DAO-ACK and RCO messages with the 'A' 1290 flag reset, under the ICMPv6 parameters registry. 1292 * Possible values are 6-bit unsigned integers (0..63). 1294 * Registration procedure is "Standards Action" [RFC8126]. 1296 * Initial allocation is as indicated in Table 5: 1298 +-------+-----------------------+---------------+ 1299 | Value | Meaning | Reference | 1300 +-------+-----------------------+---------------+ 1301 | 0 | Unqualified rejection | This document | 1302 +-------+-----------------------+---------------+ 1304 Table 5: Rejection values of the RPL Status 1306 13. Acknowledgments 1308 The authors wish to thank Ines Robles, Georgios Papadopoulos and 1309 especially Rahul Jadhav and Alvaro Retana for their reviews and 1310 contributions to this document. 1312 14. Normative References 1314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1315 Requirement Levels", BCP 14, RFC 2119, 1316 DOI 10.17487/RFC2119, March 1997, 1317 . 1319 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1320 Listener Discovery (MLD) for IPv6", RFC 2710, 1321 DOI 10.17487/RFC2710, October 1999, 1322 . 1324 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1325 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1326 DOI 10.17487/RFC3810, June 2004, 1327 . 1329 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1330 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1331 Overview, Assumptions, Problem Statement, and Goals", 1332 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1333 . 1335 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1336 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1337 DOI 10.17487/RFC4861, September 2007, 1338 . 1340 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1341 Address Autoconfiguration", RFC 4862, 1342 DOI 10.17487/RFC4862, September 2007, 1343 . 1345 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1346 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1347 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1348 Low-Power and Lossy Networks", RFC 6550, 1349 DOI 10.17487/RFC6550, March 2012, 1350 . 1352 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1353 Power and Lossy Networks (RPL) Option for Carrying RPL 1354 Information in Data-Plane Datagrams", RFC 6553, 1355 DOI 10.17487/RFC6553, March 2012, 1356 . 1358 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1359 Routing Header for Source Routes with the Routing Protocol 1360 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1361 DOI 10.17487/RFC6554, March 2012, 1362 . 1364 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1365 Bormann, "Neighbor Discovery Optimization for IPv6 over 1366 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1367 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1368 . 1370 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1371 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1372 2014, . 1374 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1375 Constrained-Node Networks", RFC 7228, 1376 DOI 10.17487/RFC7228, May 2014, 1377 . 1379 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1380 IPv6 over Low-Power Wireless Personal Area Networks 1381 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1382 2014, . 1384 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1385 Writing an IANA Considerations Section in RFCs", BCP 26, 1386 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1387 . 1389 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1390 "IPv6 over Low-Power Wireless Personal Area Network 1391 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1392 April 2017, . 1394 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1395 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1396 May 2017, . 1398 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1399 (IPv6) Specification", STD 86, RFC 8200, 1400 DOI 10.17487/RFC8200, July 2017, 1401 . 1403 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1404 Perkins, "Registration Extensions for IPv6 over Low-Power 1405 Wireless Personal Area Network (6LoWPAN) Neighbor 1406 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1407 . 1409 [AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 1410 "Address Protected Neighbor Discovery for Low-power and 1411 Lossy Networks", Work in Progress, Internet-Draft, draft- 1412 ietf-6lo-ap-nd-23, 30 April 2020, 1413 . 1415 [USEofRPLinfo] 1416 Robles, I., Richardson, M., and P. Thubert, "Using RPI 1417 Option Type, Routing Header for Source Routes and IPv6-in- 1418 IPv6 encapsulation in the RPL Data Plane", Work in 1419 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40, 1420 25 June 2020, . 1423 [EFFICIENT-NPDAO] 1424 Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient 1425 Route Invalidation", Work in Progress, Internet-Draft, 1426 draft-ietf-roll-efficient-npdao-18, 15 April 2020, 1427 . 1430 15. Informative References 1432 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1433 Statement and Requirements for IPv6 over Low-Power 1434 Wireless Personal Area Network (6LoWPAN) Routing", 1435 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1436 . 1438 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1439 C., and M. Carney, "Dynamic Host Configuration Protocol 1440 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1441 2003, . 1443 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1444 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1445 DOI 10.17487/RFC6282, September 2011, 1446 . 1448 [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, 1449 Ed., "Performance Evaluation of the Routing Protocol for 1450 Low-Power and Lossy Networks (RPL)", RFC 6687, 1451 DOI 10.17487/RFC6687, October 2012, 1452 . 1454 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1455 and M. Richardson, Ed., "A Security Threat Analysis for 1456 the Routing Protocol for Low-Power and Lossy Networks 1457 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1458 . 1460 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1461 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1462 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1463 . 1465 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1466 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1467 January 2019, . 1469 [6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1470 Backbone Router", Work in Progress, Internet-Draft, draft- 1471 ietf-6lo-backbone-router-20, 23 March 2020, 1472 . 1475 Appendix A. Example Compression 1477 Figure 11 illustrates the case in Storing Mode where the packet is 1478 received from the Internet, then the Root encapsulates the packet to 1479 insert the RPI and deliver to the 6LR that is the parent and last hop 1480 to the final destination, which is not known to support [RFC8138]. 1482 +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... 1483 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 1484 |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 1485 +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... 1486 <-4 bytes-> <- RFC 6282 -> 1487 <- No RPL artifact ... 1489 Figure 11: Encapsulation to Parent 6LR in Storing Mode 1491 The difference with the example presented in Figure 19 of [RFC8138] 1492 is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the 1493 compressed address of the 6LR as the destination address of the outer 1494 IPv6 header. In the original example the destination IP of the outer 1495 header was elided and was implicitly the same address as the 1496 destination of the inner header. Type 1 was arbitrarily chosen, and 1497 the size of 0 denotes a single address in the SRH. 1499 In Figure 11, the source of the IP-in-IP encapsulation is the Root, 1500 so it is elided in the IP-in-IP 6LoRH. The destination is the parent 1501 6LR of the destination of the inner packet so it cannot be elided. 1502 If the DODAG is operated in Storing Mode, it is the single entry in 1503 the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The SRH-6LoRH 1504 is the first 6LoRH in the chain. In this particular example, the 6LR 1505 address can be compressed to 2 bytes so a Type of 1 is used. It 1506 results that the total length of the SRH-6LoRH is 4 bytes. 1508 In Non-Storing Mode, the encapsulation from the Root would be similar 1509 to that represented in Figure 11 with possibly more hops in the SRH- 1510 6LoRH and possibly multiple SRH-6LoRHs if the various addresses in 1511 the routing header are not compressed to the same format. Note that 1512 on the last hop to the parent 6LR, the RH3 is consumed and removed 1513 from the compressed form, so the use of Non-Storing Mode vs. Storing 1514 Mode is indistinguishable from the packet format. 1516 The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH. 1517 When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that 1518 precede it are also removed. The Paging Dispatch [RFC8025] may also 1519 be removed if there was no previous Page change to a Page other than 1520 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the 1521 default Page 0 and in Page 1. The resulting packet to the 1522 destination is the inner packet compressed with [RFC6282]. 1524 Authors' Addresses 1526 Pascal Thubert (editor) 1527 Cisco Systems, Inc 1528 Building D 1529 45 Allee des Ormes - BP1200 1530 06254 Mougins - Sophia Antipolis 1531 France 1533 Phone: +33 497 23 26 34 1534 Email: pthubert@cisco.com 1536 Michael C. Richardson 1537 Sandelman Software Works 1539 Email: mcr+ietf@sandelman.ca 1540 URI: http://www.sandelman.ca/