idnits 2.17.00 (12 Aug 2021) /tmp/idnits12399/draft-ietf-roll-useofrplinfo-39.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 abstract seems to contain references ([RFC8138]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2020) is 712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-6lo-ap-nd has been published as RFC 8928 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-anima-autonomic-control-plane has been published as RFC 8994 == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: draft-ietf-roll-unaware-leaves has been published as RFC 9010 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group M. Robles 3 Internet-Draft UTN-FRM/Aalto 4 Updates: 6553, 6550, 8138 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: December 10, 2020 P. Thubert 7 Cisco 8 June 8, 2020 10 Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 11 encapsulation in the RPL Data Plane 12 draft-ietf-roll-useofrplinfo-39 14 Abstract 16 This document looks at different data flows through LLN (Low-Power 17 and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power 18 and Lossy Networks) is used to establish routing. The document 19 enumerates the cases where RFC6553 (RPI Option Type), RFC6554 20 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is 21 required in data plane. This analysis provides the basis on which to 22 design efficient compression of these headers. This document updates 23 RFC6553 adding a change to the RPI Option Type. Additionally, this 24 document updates RFC6550 defining a flag in the DIO Configuration 25 option to indicate about this change and updates [RFC8138] as well to 26 consider the new Option Type when the RPL Option is decompressed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 10, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Language . . . . . . . . . . . . 5 65 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 67 4.1. Updates to RFC6550: Advertising External Routes with Non- 68 Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 69 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8 70 4.3. Updates to RFC6550: Indicating the new RPI in the 71 DODAG Configuration option Flag. . . . . . . . . . . . . 11 72 4.4. Updates to RFC8138: Indicating the way to decompress with 73 the new RPI Option Type. . . . . . . . . . . . . . . . . 12 74 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14 75 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20 78 7.1.1. SM: Example of Flow from RAL to Root . . . . . . . . 21 79 7.1.2. SM: Example of Flow from Root to RAL . . . . . . . . 22 80 7.1.3. SM: Example of Flow from Root to RUL . . . . . . . . 22 81 7.1.4. SM: Example of Flow from RUL to Root . . . . . . . . 24 82 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 25 83 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 25 84 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 27 85 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 28 86 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 29 87 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 30 88 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 30 89 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 31 90 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 33 91 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 34 92 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 35 93 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 37 94 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 37 95 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 38 96 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 39 97 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 40 98 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 41 99 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 41 100 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 43 101 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 44 102 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45 103 8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46 104 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46 105 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49 106 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51 107 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52 108 9. Operational Considerations of supporting 109 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53 110 10. Operational considerations of introducing 0x23 . . . . . . . 54 111 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 113 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 115 14.1. Normative References . . . . . . . . . . . . . . . . . . 59 116 14.2. Informative References . . . . . . . . . . . . . . . . . 60 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 119 1. Introduction 121 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 122 [RFC6550] is a routing protocol for constrained networks. [RFC6553] 123 defines the RPL Option carried within the IPv6 Hop-by-Hop Header to 124 carry the RPLInstanceID and quickly identify inconsistencies (loops) 125 in the routing topology. The RPL Option is commonly referred to as 126 the RPL Packet Information (RPI) though the RPI is really the 127 abstract information that is defined in [RFC6550] and transported in 128 the RPL Option. RFC6554 [RFC6554] defines the "RPL Source Route 129 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 130 RPL routing domain, particularly in non-storing mode. 132 These various items are referred to as RPL artifacts, and they are 133 seen on all of the data-plane traffic that occurs in RPL routed 134 networks; they do not in general appear on the RPL control plane 135 traffic at all which is mostly Hop-by-Hop traffic (one exception 136 being DAO messages in non-storing mode). 138 It has become clear from attempts to do multi-vendor 139 interoperability, and from a desire to compress as many of the above 140 artifacts as possible that not all implementers agree when artifacts 141 are necessary, or when they can be safely omitted, or removed. 143 The ROLL WG analysized how [RFC2460] rules apply to storing and non- 144 storing use of RPL. The result was 24 data plane use cases. They 145 are exhaustively outlined here in order to be completely unambiguous. 146 During the processing of this document, new rules were published as 147 [RFC8200], and this document was updated to reflect the normative 148 changes in that document. 150 This document updates [RFC6553], changing the value of the Option 151 Type of the RPL Option to make [RFC8200] routers ignore this option 152 when not recognized. 154 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 155 mechanism for compressing RPL Option information and Routing Header 156 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 157 technique. 159 Since some of the uses cases here described, use IPv6-in-IPv6 160 encapsulation. It MUST take in consideration, when encapsulation is 161 applied, the RFC6040 [RFC6040], which defines how the explicit 162 congestion notification (ECN) field of the IP header should be 163 constructed on entry to and exit from any IPV6-in-IPV6 tunnel. 164 Additionally, it is recommended the reading of 165 [I-D.ietf-intarea-tunnels] that explains the relationship of IP 166 tunnels to existing protocol layers and the challenges in supporting 167 IP tunneling. 169 Non-constrained uses of RPL are not in scope of this document, and 170 applicability statements for those uses may provide different advice, 171 E.g. [I-D.ietf-anima-autonomic-control-plane]. 173 1.1. Overview 175 The rest of the document is organized as follows: Section 2 describes 176 the used terminology. Section 3 provides a RPL Overview. Section 4 177 describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5 178 provides the reference topology used for the uses cases. Section 6 179 describes the uses cases included. Section 7 describes the storing 180 mode cases and section 8 the non-storing mode cases. Section 9 181 describes the operational considerations of supporting RPL-unaware- 182 leaves. Section 10 depicts operational considerations for the 183 proposed change on RPI Option Type, section 11 the IANA 184 considerations and then section 12 describes the security aspects. 186 2. Terminology and Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 Terminology defined in [RFC7102] applies to this document: LLN, RPL, 195 RPL domain and ROLL. 197 RPL Leaf: An IPv6 host that is attached to a RPL router and obtains 198 connectivity through a RPL Destination Oriented Directed Acyclic 199 Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a 200 consumed Routing Header and as an IPv6 host, it is expected to ignore 201 a Hop-by-Hop header. It results that a RPL Leaf can correctly 202 receive a packet with RPL artifacts. On the other hand, a RPL Leaf 203 is not expected to generate RPL artifacts or to support IP-in-IP 204 encapsulation. For simplification, this document uses the standalone 205 term leaf to mean a RPL leaf. 207 RPL Packet Information (RPI): The abstract information that [RFC6550] 208 places in IP packets. The term is commonly used, including in this 209 document, to refer to the RPL Option [RFC6553] that transports that 210 abstract information in an IPv6 Hob-by-Hop Header. 212 RPL-aware-node (RAN): A device which implements RPL. Please note 213 that the device can be found inside the LLN or outside LLN. 215 RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. 217 RPL-unaware-node: A device which does not implement RPL, thus the 218 device is not-RPL-aware. Please note that the device can be found 219 inside the LLN. 221 RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. 223 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any 224 host or router participating in a LoWPAN. This term is used when 225 referring to situations in which either a host or router can play the 226 role described.". In this document, a 6LN acts as a leaf. 228 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate 229 router in the LoWPAN that is able to send and receive Router 230 Advertisements (RAs) and Router Solicitations (RSs) as well as 231 forward and route IPv6 packets. 6LoWPAN routers are present only in 232 route-over topologies." 233 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 234 router located at the junction of separate 6LoWPAN networks or 235 between a 6LoWPAN network and another IP network. There may be one 236 or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the 237 responsible authority for IPv6 prefix propagation for the 6LoWPAN 238 network it is serving. An isolated LoWPAN also contains a 6LBR in 239 the network, which provides the prefix(es) for the isolated network." 241 Flag Day: In this document, refers to a transition that involves 242 having a network with different values of RPI Option Type. 244 Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- 245 aware-nodes send information to the root about their parents. Thus, 246 the root knows the topology. Because the root knows the topology, 247 the intermediate 6LRs do not maintain routing state and source 248 routing is needed. 250 Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes 251 (6LRs) maintain routing state (of the children) so that source 252 routing is not needed. 254 Note: Due to lack of space in some figures (tables) we refer to IPv6- 255 in-IPv6 as IP6-IP6. 257 3. RPL Overview 259 RPL defines the RPL Control messages (control plane), a new ICMPv6 260 [RFC4443] message with Type 155. DIS (DODAG Information 261 Solicitation), DIO (DODAG Information Object) and DAO (Destination 262 Advertisement Object) messages are all RPL Control messages but with 263 different Code values. A RPL Stack is shown in Figure 1. 265 +--------------+ 266 | Upper Layers | 267 | | 268 +--------------+ 269 | RPL | 270 | | 271 +--------------+ 272 | ICMPv6 | 273 | | 274 +--------------+ 275 | IPv6 | 276 | | 277 +--------------+ 278 | 6LoWPAN | 279 | | 280 +--------------+ 281 | PHY-MAC | 282 | | 283 +--------------+ 285 Figure 1: RPL Stack. 287 RPL supports two modes of Downward traffic: in storing mode (SM), it 288 is fully stateful; in non-storing mode (Non-SM), it is fully source 289 routed. A RPL Instance is either fully storing or fully non-storing, 290 i.e. a RPL Instance with a combination of storing and non-storing 291 nodes is not supported with the current specifications at the time of 292 writing this document. 294 4. Updates to RFC6553, RFC6550 and RFC8138 296 4.1. Updates to RFC6550: Advertising External Routes with Non-Storing 297 Mode Signaling. 299 Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to 300 indicate that the 6LR that generates the DAO redistributes external 301 targets into the RPL network. An external Target is a Target that 302 has been learned through an alternate protocol, for instance a route 303 to a prefix that is outside the RPL domain but reachable via a 6LR. 304 Being outside of the RPL domain, a node that is reached via an 305 external target cannot be guaranteed to ignore the RPL artifacts and 306 cannot be expected to process the [RFC8138] compression correctly. 307 This means that the RPL artifacts should be contained in an IP-in-IP 308 encapsulation that is removed by the 6LR, and that any remaining 309 compression should be expanded by the 6LR before it forwards a packet 310 outside the RPL domain. 312 This specification updates [RFC6550] to RECOMMEND that external 313 targets are advertised using Non-Storing Mode DAO messaging even in a 314 Storing-Mode network. This way, external routes are not advertised 315 within the DODAG and all packets to an external target reach the Root 316 like normal Non-Storing Mode traffic. The Non-Storing Mode DAO 317 informs the Root of the address of the 6LR that injects the external 318 route, and the root uses IP-in-IP encapsulation to that 6LR, which 319 terminates the IP-in-IP tunnel and forwards the original packet 320 outside the RPL domain free of RPL artifacts. In the other 321 direction, for traffic coming from an external target into the LLN, 322 the parent (6LR) that injects the traffic always encapsulates to the 323 root. This whole operation is transparent to intermediate routers 324 that only see traffic between the 6LR and the Root, and only the Root 325 and the 6LRs that inject external routes in the network need to be 326 upgraded to add this function to the network. 328 A RUL is a special case of external target when the target is 329 actually a host and it is known to support a consumed Routing Header 330 and to ignore a HbH header as prescribed by [RFC8200]. The target 331 may have been learned through an external routing protocol or may 332 have been registered to the 6LR using [RFC8505]. 334 In order to enable IP-in-IP all the way to a 6LN, it is beneficial 335 that the 6LN supports decapsulating IP-in-IP, but that is not assumed 336 by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a 337 packet SHOULD terminate the tunnel at a parent 6LR unless it is aware 338 that the RUL supports IP-in-IP decapsulation. 340 A node that is reachable over an external route is not expected to 341 support [RFC8138]. Whether a decapsulation took place or not and 342 even when the 6LR is delivering the packet to a RUL, the 6LR that 343 injected an external route MUST uncompress the packet before 344 forwarding over that external route. 346 4.2. Updates to RFC6553: Indicating the new RPI Option Type. 348 This modification is required in order to be able to send, for 349 example, IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node 350 through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 351 encapsulation. 353 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 354 the Option Type field of the RPL Option, the two high order bits must 355 be set to '01' and the third bit is equal to '1'. The first two bits 356 indicate that the IPv6 node must discard the packet if it doesn't 357 recognize the Option Type, and the third bit indicates that the 358 Option Data may change in route. The remaining bits serve as the 359 Option Type. 361 +-------+-------------------+----------------+-----------+ 362 | Hex | Binary Value | Description | Reference | 363 + Value +-------------------+ + + 364 | | act | chg | rest | | | 365 +-------+-----+-----+-------+----------------+-----------+ 366 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 367 +-------+-----+-----+-------+----------------+-----------+ 369 Figure 2: Option Type in RPL Option. 371 This document illustrates that it is not always possible to know for 372 sure at the source that a packet will only travel within the RPL 373 domain or may leave it. 375 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 376 the outer IPv6 header chain could potentially impact core routers in 377 the internet. So at that time, it was decided to encapsulate any 378 packet with a RPL Option using IPv6-in-IPv6 in all cases where it was 379 unclear whether the packet would remain within the RPL domain. In 380 the exception case where a packet would still leak, the Option Type 381 would ensure that the first router in the Internet that does not 382 recognize the option would drop the packet and protect the rest of 383 the network. 385 Even with [RFC8138], where the IPv6-in-IPv6 header is compressed, 386 this approach yields extra bytes in a packet; this means consuming 387 more energy, more bandwidth, incurring higher chances of loss and 388 possibly causing a fragmentation at the 6LoWPAN level. This impacts 389 the daily operation of constrained devices for a case that generally 390 does not happen and would not heavily impact the core anyway. 392 While intention was and remains that the Hop-by-Hop header with a RPL 393 Option should be confined within the RPL domain, this specification 394 modifies this behavior in order to reduce the dependency on IPv6-in- 395 IPv6 and protect the constrained devices. Section 4 of [RFC8200] 396 clarifies the behaviour of routers in the Internet as follows: "it is 397 now expected that nodes along a packet's delivery path only examine 398 and process the Hop-by-Hop Options header if explicitly configured to 399 do so". 401 When unclear about the travel of a packet, it becomes preferable for 402 a source not to encapsulate, accepting the fact that the packet may 403 leave the RPL domain on its way to its destination. In that event, 404 the packet should reach its destination and should not be discarded 405 by the first node that does not recognize the RPL Option. But with 406 the current value of the Option Type, if a node in the Internet is 407 configured to process the Hop-by-Hop header, and if such node 408 encounters an option with the first two bits set to 01 and conforms 409 to [RFC8200], it will drop the packet. Host systems should do the 410 same, irrespective of the configuration. 412 Thus, this document updates the Option Type of the RPL Option 413 [RFC6553], abusively naming it RPI Option Type for simplicity, to 414 (Figure 3): the two high order bits MUST be set to '00' and the third 415 bit is equal to '1'. The first two bits indicate that the IPv6 node 416 MUST skip over this option and continue processing the header 417 ([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and 418 the third bit continues to be set to indicate that the Option Data 419 may change en route. The rightmost five bits remain at 0x3(00011). 420 This ensures that a packet that leaves the RPL domain of an LLN (or 421 that leaves the LLN entirely) will not be discarded when it contains 422 the RPL Option. 424 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 425 capable) receives a packet with a RPL Option, it should ignore the 426 Hop-by-Hop RPL Option (skip over this option and continue processing 427 the header). This is relevant, as it was mentioned previously, in 428 the case that there is a flow from RAL to Internet (see 429 Section 7.2.1). 431 This is a significant update to [RFC6553]. 433 +-------+-------------------+-------------+------------+ 434 | Hex | Binary Value | Description | Reference | 435 + Value +-------------------+ + + 436 | | act | chg | rest | | | 437 +-------+-----+-----+-------+-------------+------------+ 438 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 439 +-------+-----+-----+-------+-------------+------------+ 441 Figure 3: Revised Option Type in RPL Option. (*)represents this 442 document 444 Without the signaling described below, this change would otherwise 445 create a lack of interoperation (flag day) for existing networks 446 which are currently using 0x63 as the RPI Option Type value. A move 447 to 0x23 will not be understood by those networks. It is suggested 448 that RPL implementations accept both 0x63 and 0x23 when processing 449 the header. 451 When forwarding packets, implementations SHOULD use the same value of 452 RPI Type as was received. This is required because the RPI Option 453 Type does not change en route ([RFC8200] - Section 4.2). It allows 454 the network to be incrementally upgraded and allows the DODAG root to 455 know which parts of the network have been upgraded. 457 When originating new packets, implementations SHOULD have an option 458 to determine which value to originate with, this option is controlled 459 by the DIO option described below. 461 The change of RPI Option Type from 0x63 to 0x23, makes all [RFC8200] 462 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 463 therefore no longer a necessity to remove the artifacts when sending 464 traffic to the Internet. This change clarifies when to use IPv6-in- 465 IPv6 headers, and how to address them: The Hop-by-Hop Options header 466 containing the RPI MUST always be added when 6LRs originate packets 467 (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST always 468 be added when a 6LR finds that it needs to insert a Hop-by-Hop 469 Options header containing the RPL Option. The IPv6-in-IPv6 header is 470 to be addressed to the RPL root when on the way up, and to the end- 471 host when on the way down. 473 In the non-storing case, dealing with not-RPL aware leaf nodes is 474 much easier as the 6LBR (DODAG root) has complete knowledge about the 475 connectivity of all DODAG nodes, and all traffic flows through the 476 root node. 478 The 6LBR can recognize not-RPL aware leaf nodes because it will 479 receive a DAO about that node from the 6LR immediately above that 480 not-RPL aware node. 482 The non-storing mode case does not require the type change from 0x63 483 to 0x23, as the root can always create the right packet. The type 484 change does not adversely affect the non-storing case. 486 4.3. Updates to RFC6550: Indicating the new RPI in the DODAG 487 Configuration option Flag. 489 In order to avoid a Flag Day caused by lack of interoperation between 490 new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this 491 section defines a flag in the DIO Configuration option, to indicate 492 when the new RPI Option Type can be safely used. This means, the 493 flag is going to indicate the value of Option Type that the network 494 will be using for the RPL Option. Thus, when a node joins to a 495 network will know which value to use. With this, RPL-capable nodes 496 know if it is safe to use 0x23 when creating a new RPL Option. A 497 node that forwards a packet with an RPI MUST NOT modify the Option 498 Type of the RPL Option. 500 This is done using a DODAG Configuration option flag which will 501 signal "RPI 0x23 enable" and propagate through the network. 502 Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) 503 in the DIO Base Object. The flag is defined only for MOP value 504 between 0 to 6. For a MOP value of 7 or above, the flag MAY indicate 505 something different and MUST NOT be interpreted as "RPI 0x23 enable" 506 unless the specification of the MOP indicates to do so. 508 As stated in [RFC6550] the DODAG Configuration option is present in 509 DIO messages. The DODAG Configuration option distributes 510 configuration information. It is generally static, and does not 511 change within the DODAG. This information is configured at the DODAG 512 root and distributed throughout the DODAG with the DODAG 513 Configuration option. Nodes other than the DODAG root do not modify 514 this information when propagating the DODAG Configuration option. 516 Currently, the DODAG Configuration option in [RFC6550] states: "the 517 unused bits MUST be initialize to zero by the sender and MUST be 518 ignored by the receiver". If the flag is received with a value zero 519 (which is the default), then new nodes will remain in RFC6553 520 Compatible Mode; originating traffic with the old-RPI Option Type 521 (0x63) value. If the flag is received with a value of 1, then the 522 value for the RPL Option MUST be set to 0x23. 524 Bit number three of the flag field in the DODAG Configuration option 525 is to be used as shown in Figure 4 (which is the same as Figure 39 in 526 Section 11 and is shown here for convenience): 528 +------------+-----------------+---------------+ 529 | Bit number | Description | Reference | 530 +------------+-----------------+---------------+ 531 | 3 | RPI 0x23 enable | This document | 532 +------------+-----------------+---------------+ 534 Figure 4: DODAG Configuration option Flag to indicate the RPI-flag- 535 day. 537 In the case of reboot, the node (6LN or 6LR) does not remember the 538 RPI Option Type (i.e., whether or not the flag is set), so the node 539 will not trigger DIO messages until a DIO message is received 540 indicating the RPI value to be used. The node will use the value 541 0x23 if the network supports this feature 543 4.4. Updates to RFC8138: Indicating the way to decompress with the new 544 RPI Option Type. 546 This modification is required in order to be able to decompress the 547 RPL Option with the new Option Type of 0x23. 549 RPI-6LoRH header provides a compressed form for the RPL RPI; see 550 [RFC8138], Section 6. A node that is decompressing this header MUST 551 decompress using the RPI Option Type that is currently active: that 552 is, a choice between 0x23 (new) and 0x63 (old). The node will know 553 which to use based upon the presence of the flag in the DODAG 554 Configuration option defined in Section 4.3. E.g. If the network is 555 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 557 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 558 header. 560 There are potential significant advantages to having a single code 561 path that always processes IPv6-in-IPv6 headers with no conditional 562 branches. 564 In Storing Mode, the scenarios where the flow goes from RAL to RUL 565 and RUL to RUL include compression of the IPv6-in-IPv6 and RPI 566 headers. The use of the IPv6-in-IPv6 header is MANDATORY in this 567 case, and it SHOULD be compressed with [RFC8138] section 7. Figure 5 568 illustrates the case in Storing mode where the packet is received 569 from the Internet, then the root encapsulates the packet to insert 570 the RPI. In that example, the leaf is not known to support RFC 8138, 571 and the packet is encapsulated to the 6LR that is the parent and last 572 hop to the final destination. 574 +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... 575 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 576 |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 577 +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-... 578 <-4bytes-> <- RFC 6282 -> 579 No RPL artifact 581 Figure 5: RPI Inserted by the Root in Storing Mode 583 In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the 584 Root, so it is elided in the IP-in-IP 6LoRH. The destination is the 585 parent 6LR of the destination of the inner packet so it cannot be 586 elided. It is placed as the single entry in an SRH-6LoRH as the 587 first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In 588 that example, the type is 1 so the 6LR address is compressed to 2 589 bytes. It results that the total length of the SRH-6LoRH is 4 bytes. 590 Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 591 6LoRH is removed, all the router headers that precede it are also 592 removed. The Paging Dispatch [RFC8025] may also be removed if there 593 was no previous Page change to a Page other than 0 or 1, since the 594 LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and 595 in Page 1. The resulting packet to the destination is the inner 596 packet compressed with [RFC6282]. 598 5. Sample/reference topology 600 A RPL network in general is composed of a 6LBR, a Backbone Router 601 (6BBR), a 6LR and a 6LN as a leaf logically organized in a DODAG 602 structure. 604 Figure 6 shows the reference RPL Topology for this document. The 605 letters above the nodes are there so that they may be referenced in 606 subsequent sections. In the figure, 6LR represents a full router 607 node. The 6LN is a RPL aware router, or host (as a leaf). 608 Additionally, for simplification purposes, it is supposed that the 609 6LBR has direct access to Internet and is the root of the DODAG, thus 610 the 6BBR is not present in the figure. 612 The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no 613 children hosts. 615 The leaves marked as RUL (G and J) are devices which do not speak RPL 616 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 617 DAC and 6LoWPAN ND only to participate in the network [RFC8505]. In 618 the document these leaves (G and J) are also referred to as a RUL. 620 The 6LBR ("A") in the figure is the root of the Global DODAG. 622 +------------+ 623 | INTERNET ----------+ 624 | | | 625 +------------+ | 626 | 627 | 628 | 629 A | 630 +-------+ 631 |6LBR | 632 +-----------|(root) |-------+ 633 | +-------+ | 634 | | 635 | | 636 | | 637 | | 638 | B |C 639 +---|---+ +---|---+ 640 | 6LR | | 6LR | 641 +---------| |--+ +--- ---+ 642 | +-------+ | | +-------+ | 643 | | | | 644 | | | | 645 | | | | 646 | | | | 647 | D | E | | 648 +-|-----+ +---|---+ | | 649 | 6LR | | 6LR | | | 650 | | +------ | | | 651 +---|---+ | +---|---+ | | 652 | | | | | 653 | | +--+ | | 654 | | | | | 655 | | | | | 656 | | | I | J | 657 F | | G | H | | 658 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 659 | RAL | | RUL | | RAL | | RAL | | RUL | 660 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 661 +-------+ +-------+ +------+ +-------+ +-------+ 663 Figure 6: A reference RPL Topology. 665 6. Use cases 667 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 668 encapsulation are going to be analyzed for a number of representative 669 traffic flows. 671 This document assumes that the LLN is using the no-drop RPI Option 672 Type of 0x23. 674 The use cases describe the communication in the following cases: - 675 Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- 676 nodes with the Internet - Between RUL nodes within the LLN (e.g. see 677 Section 7.1.4) - Inside of the LLN when the final destination address 678 resides outside of the LLN (e.g. see Section 7.2.3). 680 The uses cases are as follows: 682 Interaction between Leaf and Root: 684 RAL to root 686 root to RAL 688 RUL to root 690 root to RUL 692 Interaction between Leaf and Internet: 694 RAL to Internet 696 Internet to RAL 698 RUL to Internet 700 Internet to RUL 702 Interaction between leaves: 704 RAL to RAL 706 RAL to RUL 708 RUL to RAL 710 RUL to RUL 712 This document is consistent with the rule that a Header cannot be 713 inserted or removed on the fly inside an IPv6 packet that is being 714 routed. This is a fundamental precept of the IPv6 architecture as 715 outlined in [RFC8200]. 717 As the rank information in the RPI artifact is changed at each hop, 718 it will typically be zero when it arrives at the DODAG root. The 719 DODAG root MUST force it to zero when passing the packet out to the 720 Internet. The Internet will therefore not see any SenderRank 721 information. 723 Despite being legal to leave the RPI artifact in place, an 724 intermediate router that needs to add an extension header (e.g. RH3 725 or RPL Option) MUST still encapsulate the packet in an (additional) 726 outer IP header. The new header is placed after this new outer IP 727 header. 729 A corollary is that an intermediate router can remove an RH3 or RPL 730 Option only if it is placed in an encapsulating IPv6 Header that is 731 addressed TO this intermediate router. When doing the above, the 732 whole encapsulating header must be removed. (A replacement may be 733 added). This sometimes can result in outer IP headers being 734 addressed to the next hop router using link-local address. 736 Both the RPL Option and the RH3 headers may be modified in very 737 specific ways by routers on the path of the packet without the need 738 to add and remove an encapsulating header. Both headers were 739 designed with this modification in mind, and both the RPL RH3 and the 740 RPL Option are marked mutable but recoverable: so an IPsec AH 741 security header can be applied across these headers, but it can not 742 secure the values which mutate. 744 The RPI MUST be present in every single RPL data packet. 746 Prior to [RFC8138], there was significant interest in creating an 747 exception to this rule and removing the RPI for downward flows in 748 non-storing mode. This exception covered a very small number of 749 cases, and caused significant interoperability challenges while 750 adding significant in the code and tests. The ability to compress 751 the RPI down to three bytes or less removes much of the pressure to 752 optimize this any further [I-D.ietf-anima-autonomic-control-plane]. 754 Throughout the following subsections, the examples are described in 755 more details in the first subsections, and more concisely in the 756 later ones. 758 The uses cases are delineated based on the following IPV6 and RPL 759 mandates: 761 The RPI has to be in every packet that traverses the LLN. 763 - Because of the above requirement, packets from the Internet have 764 to be encapsulated. 766 - A Header cannot be inserted or removed on the fly inside an IPv6 767 packet that is being routed. 769 - Extension headers may not be added or removed except by the 770 sender or the receiver. 772 - RPI and RH3 headers may be modified by routers on the path of 773 the packet without the need to add and remove an encapsulating 774 header. 776 - an RH3 or RPL Option can only be removed by an intermediate 777 router if it is placed in an encapsulating IPv6 Header, which is 778 addressed to the intermediate router. 780 - Non-storing mode requires downstream encapsulation by root for 781 RH3. 783 The uses cases are delineated based on the following assumptions: 785 This document assumes that the LLN is using the no-drop RPI Option 786 Type (0x23). 788 - Each IPv6 node (including Internet routers) obeys [RFC8200], so 789 that 0x23 RPI Option Type can be safely inserted. 791 - All 6LRs obey [RFC8200]. 793 - The RPI is ignored at the IPv6 dst node (RUL). 795 - In the uses cases, we assume that the RAL supports IP-in-IP 796 encapsulation. 798 - In the uses cases, we dont assume that the RUL supports IP-in-IP 799 encapsulation. 801 - For traffic leaving a RUL, if the RUL adds an opaque RPI then 802 the description of the RAL applies. 804 - The description for RALs applies to RAN in general. 806 - Non-constrained uses of RPL are not in scope of this document. 808 - Compression is based on [RFC8138]. 810 - The flow label [RFC6437] is not needed in RPL. 812 7. Storing mode 814 In storing mode (SM) (fully stateful), the sender can determine if 815 the destination is inside the LLN by looking if the destination 816 address is matched by the DIO's Prefix Information Option (PIO) 817 option. 819 The following table (Figure 7) itemizes which headers are needed in 820 each of the following scenarios. It indicates whether an IPv6-in- 821 IPv6 header must be added and what destination it must be addressed 822 to: (1) the final destination (the RAL node that is the target 823 (tgt)), (2) the "root", or (3) the 6LR parent of a RUL. 825 In cases where no IPv6-in-IPv6 header is needed, the column states 826 "No", and the destination is N/A (Not Applicable). If the IPv6-in- 827 IPv6 header is needed, the column shows "must". 829 In all cases, the RPI is needed, since it identifies inconsistencies 830 (loops) in the routing topology. In general, the RH3 is not needed 831 because it is not used in storing mode. However, there is one 832 scenario (from the root to the RUL in SM) where the RH3 can be used 833 to point at the RUL (Figure 11). 835 The leaf can be a router 6LR or a host, both indicated as 6LN. The 836 root refers to the 6LBR (see Figure 6). 838 +---------------------+--------------+------------+----------------+ 839 | Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst| 840 +---------------------+--------------+------------+----------------+ 841 | | RAL to root | No | N/A | 842 + +--------------+------------+----------------+ 843 | Leaf - Root | root to RAL | No | N/A | 844 + +--------------+------------+----------------+ 845 | | root to RUL | must | 6LR | 846 + +--------------+------------+----------------+ 847 | | RUL to root | must | root | 848 +---------------------+--------------+------------+----------------+ 849 | | RAL to Int | may | root | 850 + +--------------+------------+----------------+ 851 | Leaf - Internet | Int to RAL | must | RAL (tgt) | 852 + +--------------+------------+----------------+ 853 | | RUL to Int | must | root | 854 + +--------------+------------+----------------+ 855 | | Int to RUL | must | 6LR | 856 +---------------------+--------------+------------+----------------+ 857 | | RAL to RAL | No | N/A | 858 | Leaf - Leaf +--------------+------------+----------------+ 859 | | RAL to RUL | No(up) | N/A | 860 | + +------------+----------------+ 861 | | | must(down) | 6LR | 862 | +--------------+------------+----------------+ 863 | | RUL to RAL | must(up) | root | 864 | | +------------+----------------+ 865 | | | must(down) | RAL | 866 | +--------------+------------+----------------+ 867 | | RUL to RUL | must(up) | root | 868 | | +------------+----------------+ 869 | | | must(down) | 6LR | 870 |---------------------+--------------+------------+----------------+ 872 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 874 7.1. Storing Mode: Interaction between Leaf and Root 876 In this section is described the communication flow in storing mode 877 (SM) between, 879 RAL to root 881 root to RAL 883 RUL to root 885 root to RUL 887 7.1.1. SM: Example of Flow from RAL to Root 889 In storing mode, RFC 6553 (RPI) is used to send RPL Information 890 instanceID and rank information. 892 In this case the flow comprises: 894 RAL (6LN) --> 6LR_i --> root(6LBR) 896 For example, a communication flow could be: Node F (6LN) --> Node D 897 (6LR_i) --> Node B (6LR_i)--> Node A root(6LBR) 899 The RAL (Node F) inserts the RPI, and sends the packet to 6LR (Node 900 D) which decrements the rank in the RPI and sends the packet up. 901 When the packet arrives at 6LBR (Node A), the RPI is removed and the 902 packet is processed. 904 No IPv6-in-IPv6 header is required. 906 The RPI can be removed by the 6LBR because the packet is addressed to 907 the 6LBR. The RAL must know that it is communicating with the 6LBR 908 to make use of this scenario. The RAL can know the address of the 909 6LBR because it knows the address of the root via the DODAGID in the 910 DIO messages. 912 The Figure 8 summarizes what headers are needed for this use case. 914 +-----------+-----+-------+------+ 915 | Header | RAL | 6LR_i | 6LBR | 916 | | src | | dst | 917 +-----------+-----+-------+------+ 918 | Added | RPI | -- | -- | 919 | headers | | | | 920 +-----------+-----+-------+------+ 921 | Modified | -- | RPI | -- | 922 | headers | | | | 923 +-----------+-----+-------+------+ 924 | Removed | -- | -- | RPI | 925 | headers | | | | 926 +-----------+-----+-------+------+ 927 | Untouched | -- | -- | -- | 928 | headers | | | | 929 +-----------+-----+-------+------+ 931 Figure 8: SM: Summary of the use of headers from RAL to root 933 7.1.2. SM: Example of Flow from Root to RAL 935 In this case the flow comprises: 937 root (6LBR) --> 6LR_i --> RAL (6LN) 939 For example, a communication flow could be: Node A root(6LBR) --> 940 Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN) 942 In this case the 6LBR inserts RPI and sends the packet down, the 6LR 943 is going to increment the rank in RPI (it examines the RPLInstanceID 944 to identify the right forwarding table), the packet is processed in 945 the RAL and the RPI removed. 947 No IPv6-in-IPv6 header is required. 949 The Figure 9 summarizes what headers are needed for this use case. 951 +-----------+------+-------+-----+ 952 | Header | 6LBR | 6LR_i | RAL | 953 | | src | | dst | 954 +-----------+------+-------+-----+ 955 | Added | RPI | -- | -- | 956 | headers | | | | 957 +-----------+------+-------+-----+ 958 | Modified | -- | RPI | -- | 959 | headers | | | | 960 +-----------+------+-------+-----+ 961 | Removed | -- | -- | RPI | 962 | headers | | | | 963 +-----------+------+-------+-----+ 964 | Untouched | -- | -- | -- | 965 | headers | | | | 966 +-----------+------+-------+-----+ 968 Figure 9: SM: Summary of the use of headers from root to RAL 970 7.1.3. SM: Example of Flow from Root to RUL 972 In this case the flow comprises: 974 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 976 For example, a communication flow could be: Node A (6LBR) --> Node B 977 (6LR_i) --> Node E (6LR_n) --> Node G (RUL) 979 6LR_i (Node B) represents the intermediate routers from the source 980 (6LBR) to the destination (RUL), 1 <= i <= n, where n is the total 981 number of routers (6LR) that the packet goes through from the 6LBR 982 (Node A) to the RUL (Node G). 984 The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and 985 prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR 986 parent of the RUL (6LR_n). The 6LR parent of the RUL removes the 987 header and sends the packet to the RUL. 989 The Figure 10 summarizes what headers are needed for this use case. 991 +-----------+---------+---------+---------+-----+ 992 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 993 | | src | | | dst | 994 +-----------+---------+---------+---------+-----+ 995 | Added | IP6-IP6 | -- | -- | -- | 996 | headers | RPI | | | | 997 +-----------+---------+---------+---------+-----+ 998 | Modified | -- | | -- | -- | 999 | headers | | RPI | | | 1000 +-----------+---------+---------+---------+-----+ 1001 | Removed | -- | -- | IP6-IP6 | -- | 1002 | headers | | | RPI | | 1003 +-----------+---------+---------+---------+-----+ 1004 | Untouched | -- | IP6-IP6 | -- | -- | 1005 | headers | | | | | 1006 +-----------+---------+---------+---------+-----+ 1008 Figure 10: SM: Summary of the use of headers from root to RUL 1010 IP-in-IP encapsulation MAY be avoided for Root to RUL communication. 1011 In SM, it can be replaced by a loose RH3 header that indicates the 1012 RUL, in which case the packet is routed to the 6LR as a normal SM 1013 operation, then the 6LR forwards to the RUL based on the RH3, and the 1014 RUL ignores both the consumed RH3 and the RPI, as in Non-Storing 1015 Mode. 1017 The Figure 11 summarizes what headers are needed for this scenario. 1019 +-----------+----------+--------------+----------------+----------+ 1020 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1021 | | src | i=(1,..,n-1) | | dst | 1022 | | | | | | 1023 +-----------+----------+--------------+----------------+----------+ 1024 | Added | RPI, RH3 | -- | -- | -- | 1025 | headers | | | | | 1026 +-----------+----------+--------------+----------------+----------+ 1027 | Modified | -- | RPI | RPI | -- | 1028 | headers | | | RH3(consumed) | | 1029 +-----------+----------+--------------+----------------+----------+ 1030 | Removed | -- | -- | -- | -- | 1031 | headers | | | | | 1032 +-----------+----------+--------------+----------------+----------+ 1033 | Untouched | -- | RH3 | -- | RPI, RH3 | 1034 | headers | | | | (both | 1035 | | | | | ignored) | 1036 +-----------+----------+--------------+----------------+----------+ 1038 Figure 11: SM: Summary of the use of headers from root to RUL without 1039 encapsulation 1041 7.1.4. SM: Example of Flow from RUL to Root 1043 In this case the flow comprises: 1045 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) 1047 For example, a communication flow could be: Node G (RUL) --> Node E 1048 (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) 1050 6LR_i represents the intermediate routers from the source (RUL) to 1051 the destination (6LBR), 1 <= i <= n, where n is the total number of 1052 routers (6LR) that the packet goes through from the RUL to the 6LBR. 1054 When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the 1055 6LR_1 will insert encapsulate the packet in an IPv6-in-IPv6 header 1056 and prepend an RPI. The IPv6-in-IPv6 header is addressed to the root 1057 (Node A). The root removes the header and processes the packet. 1059 The Figure 12 shows the table that summarizes what headers are needed 1060 for this use case where the IPv6-in-IPv6 header is addressed to the 1061 root (Node A). 1063 +-----------+------+--------------+----------------+-----------------+ 1064 | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | 1065 | | src | | | | 1066 | | node | | | | 1067 +-----------+------+--------------+----------------+-----------------+ 1068 | Added | -- | IP6-IP6 | | -- | 1069 | headers | | RPI | -- | | 1070 +-----------+------+--------------+----------------+-----------------+ 1071 | Modified | -- | -- | RPI | -- | 1072 | headers | | | | | 1073 +-----------+------+--------------+----------------+-----------------+ 1074 | Removed | -- | -- | --- | IP6-IP6 | 1075 | headers | | | | RPI | 1076 +-----------+------+--------------+----------------+-----------------+ 1077 | Untouched | -- | -- | IP6-IP6 | -- | 1078 | headers | | | | | 1079 +-----------+------+--------------+----------------+-----------------+ 1081 Figure 12: SM: Summary of the use of headers from RUL to root. 1083 7.2. SM: Interaction between Leaf and Internet. 1085 In this section is described the communication flow in storing mode 1086 (SM) between, 1088 RAL to Internet 1090 Internet to RAL 1092 RUL to Internet 1094 Internet to RUL 1096 7.2.1. SM: Example of Flow from RAL to Internet 1098 In this case the flow comprises: 1100 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 1102 For example, the communication flow could be: Node F (RAL) --> Node D 1103 (6LR_i)--> Node B (6LR_i)--> Node A root(6LBR) --> Internet 1105 6LR_i represents the intermediate routers from the source (RAL) to 1106 the root (6LBR), 1 <= i <= n, where n is the total number of routers 1107 (6LR) that the packet goes through from the RAL to the 6LBR. 1109 RPL information from RFC 6553 may go out to Internet as it will be 1110 ignored by nodes which have not been configured to be RPI aware. No 1111 IPv6-in-IPv6 header is required. 1113 On the other hand, the RAL may insert the RPI encapsulated in a IPv6- 1114 in-IPv6 header to the root. Thus, the root removes the RPI and send 1115 the packet to the Internet. 1117 Note: In this use case, it is used a node as a leaf, but this use 1118 case can be also applicable to any RPL-aware-node type (e.g. 6LR) 1120 The Figure 13 summarizes what headers are needed for this use case 1121 when there is no encapsulation. Note that the RPI is modified by 1122 6LBR to set the SenderRank to zero in case that it is not already 1123 zero. The Figure 14 summarizes what headers are needed when 1124 encapsulation to the root takes place. 1126 +-----------+-----+-------+------+-----------+ 1127 | Header | RAL | 6LR_i | 6LBR | Internet | 1128 | | src | | | dst | 1129 +-----------+-----+-------+------+-----------+ 1130 | Added | RPI | -- | -- | -- | 1131 | headers | | | | | 1132 +-----------+-----+-------+------+-----------+ 1133 | Modified | -- | RPI | RPI | -- | 1134 | headers | | | | | 1135 +-----------+-----+-------+------+-----------+ 1136 | Removed | -- | -- | -- | -- | 1137 | headers | | | | | 1138 +-----------+-----+-------+------+-----------+ 1139 | Untouched | -- | -- | -- | RPI | 1140 | headers | | | | (Ignored) | 1141 +-----------+-----+-------+------+-----------+ 1143 Figure 13: SM: Summary of the use of headers from RAL to Internet 1144 with no encapsulation 1146 +-----------+----------+--------------+--------------+--------------+ 1147 | Header | RAL | 6LR_i | 6LBR | Internet dst | 1148 | | src | | | | 1149 +-----------+----------+--------------+--------------+--------------+ 1150 | Added | IP6-IP6 | -- | -- | -- | 1151 | headers | RPI | | | | 1152 +-----------+----------+--------------+--------------+--------------+ 1153 | Modified | -- | RPI | -- | -- | 1154 | headers | | | | | 1155 +-----------+----------+--------------+--------------+--------------+ 1156 | Removed | -- | -- | IP6-IP6 | -- | 1157 | headers | | | RPI | | 1158 +-----------+----------+--------------+--------------+--------------+ 1159 | Untouched | -- | IP6-IP6 | -- | -- | 1160 | headers | | | | | 1161 +-----------+----------+--------------+--------------+--------------+ 1163 Figure 14: SM: Summary of the use of headers from RAL to Internet 1164 with encapsulation to the root (6LBR). 1166 7.2.2. SM: Example of Flow from Internet to RAL 1168 In this case the flow comprises: 1170 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 1172 For example, a communication flow could be: Internet --> Node A 1173 root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) 1175 When the packet arrives from Internet to 6LBR the RPI is added in a 1176 outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address 1177 set to the RAL) and sent to 6LR, which modifies the rank in the RPI. 1178 When the packet arrives at the RAL the RPI is removed and the packet 1179 processed. 1181 The Figure 15 shows the table that summarizes what headers are needed 1182 for this use case. 1184 +-----------+----------+--------------+--------------+--------------+ 1185 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1186 | | src | | | | 1187 +-----------+----------+--------------+--------------+--------------+ 1188 | Added | -- | IP6-IP6(RPI) | -- | -- | 1189 | headers | | | | | 1190 +-----------+----------+--------------+--------------+--------------+ 1191 | Modified | -- | -- | RPI | -- | 1192 | headers | | | | | 1193 +-----------+----------+--------------+--------------+--------------+ 1194 | Removed | -- | -- | -- | IP6-IP6(RPI) | 1195 | headers | | | | | 1196 +-----------+----------+--------------+--------------+--------------+ 1197 | Untouched | -- | -- | -- | -- | 1198 | headers | | | | | 1199 +-----------+----------+--------------+--------------+--------------+ 1201 Figure 15: SM: Summary of the use of headers from Internet to RAL. 1203 7.2.3. SM: Example of Flow from RUL to Internet 1205 In this case the flow comprises: 1207 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1209 For example, a communication flow could be: Node G (RUL)--> Node E 1210 (6LR_1)--> Node B (6lR_i) --> Node A root(6LBR) --> Internet 1212 The node 6LR_1 (i=1) will add an IPv6-in-IPv6(RPI) header addressed 1213 to the root such that the root can remove the RPI before passing 1214 upwards. In the intermediate 6LR, the rank in the RPI is modified. 1216 The originating node will ideally leave the IPv6 flow label as zero 1217 so that the packet can be better compressed through the LLN. The 1218 6LBR will set the flow label of the packet to a non-zero value when 1219 sending to the Internet, for details check [RFC6437]. 1221 The Figure 16 shows the table that summarizes what headers are needed 1222 for this use case. 1224 +---------+-------+------------+-------------+-------------+--------+ 1225 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1226 | | src | | [i=2,...,n] | | dst | 1227 | | node | | | | | 1228 | | (RUL) | | | | | 1229 +---------+-------+------------+-------------+-------------+--------+ 1230 | Added | -- |IP6-IP6(RPI)| -- | -- | -- | 1231 | headers | | | | | | 1232 +---------+-------+------------+-------------+-------------+--------+ 1233 | Modified| -- | -- | RPI | -- | -- | 1234 | headers | | | | | | 1235 +---------+-------+------------+-------------+-------------+--------+ 1236 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1237 | headers | | | | | | 1238 +---------+-------+------------+-------------+-------------+--------+ 1239 |Untouched| -- | -- | -- | -- | -- | 1240 | headers | | | | | | 1241 +---------+-------+------------+-------------+-------------+--------+ 1243 Figure 16: SM: Summary of the use of headers from RUL to Internet. 1245 7.2.4. SM: Example of Flow from Internet to RUL. 1247 In this case the flow comprises: 1249 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1251 For example, a communication flow could be: Internet --> Node A 1252 root(6LBR) --> Node B (6LR_i)--> Node E (6LR_n) --> Node G (RUL) 1254 The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The 1255 IPv6-in-IPv6 is addressed to the 6LR parent of the RUL. 1257 Further details about this are mentioned in 1258 [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN 1259 acting as a plain host and not being aware of RPL. 1261 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1262 zero in order to aid in compression [RFC8138][RFC6437]. 1264 The Figure 17 shows the table that summarizes what headers are needed 1265 for this use case. 1267 +---------+-------+------------+--------------+-------------+-------+ 1268 | Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL | 1269 | | net | |[i=1,..,n-1] | | dst | 1270 | | src | | | | | 1271 | | | | | | | 1272 +---------+-------+------------+--------------+-------------+-------+ 1273 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1274 | headers | | | | | | 1275 +---------+-------+------------+--------------+-------------+-------+ 1276 | Modified| -- | -- | RPI | -- | -- | 1277 | headers | | | | | | 1278 +---------+-------+------------+--------------+-------------+-------+ 1279 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1280 | headers | | | | | | 1281 +---------+-------+------------+--------------+-------------+-------+ 1282 |Untouched| -- | -- | -- | -- | -- | 1283 | headers | | | | | | 1284 +---------+-------+------------+--------------+-------------+-------+ 1286 Figure 17: SM: Summary of the use of headers from Internet to RUL. 1288 7.3. SM: Interaction between Leaf and Leaf 1290 In this section is described the communication flow in storing mode 1291 (SM) between, 1293 RAL to RAL 1295 RAL to RUL 1297 RUL to RAL 1299 RUL to RUL 1301 7.3.1. SM: Example of Flow from RAL to RAL 1303 In [RFC6550] RPL allows a simple one-hop optimization for both 1304 storing and non-storing networks. A node may send a packet destined 1305 to a one-hop neighbor directly to that node. See section 9 in 1306 [RFC6550]. 1308 When the nodes are not directly connected, then in storing mode, the 1309 flow comprises: 1311 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL 1312 dst (6LN) 1313 For example, a communication flow could be: Node F (RAL src)--> Node 1314 D (6LR_ia)--> Node B (6LR_x) --> Node E (6LR_id) --> Node H (RAL dst) 1316 6LR_ia (Node D) represents the intermediate routers from source to 1317 the common parent (6LR_x) (Node B), 1 <= ia <= n, where n is the 1318 total number of routers (6LR) that the packet goes through from RAL 1319 (Node F) to the common parent 6LR_x (Node B). 1321 6LR_id (Node E) represents the intermediate routers from the common 1322 parent (6LR_x) (Node B) to destination RAL (Node H), 1 <= id <= m, 1323 where m is the total number of routers (6LR) that the packet goes 1324 through from the common parent (6LR_x) to destination RAL (Node H). 1326 It is assumed that the two nodes are in the same RPL domain (that 1327 they share the same DODAG root). At the common parent (Node B), the 1328 direction flag ('O' flag) of the RPI is changed (from decreasing 1329 ranks to increasing ranks). 1331 While the 6LR nodes will update the RPI, no node needs to add or 1332 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1334 The Figure 18 summarizes what headers are needed for this use case. 1336 +-----------+-----+--------+---------+--------+-----+ 1337 | Header | RAL | 6LR_ia | 6LR_x | 6LR_id | RAL | 1338 | | src | | (common | | dst | 1339 | | | | parent) | | | 1340 +-----------+-----+--------+---------+--------+-----+ 1341 | Added | RPI | -- | -- | -- | -- | 1342 | headers | | | | | | 1343 +-----------+-----+--------+---------+--------+-----+ 1344 | Modified | -- | RPI | RPI | RPI | -- | 1345 | headers | | | | | | 1346 +-----------+-----+--------+---------+--------+-----+ 1347 | Removed | -- | -- | -- | -- | RPI | 1348 | headers | | | | | | 1349 +-----------+-----+--------+---------+--------+-----+ 1350 | Untouched | -- | -- | -- | -- | -- | 1351 | headers | | | | | | 1352 +-----------+-----+--------+---------+--------+-----+ 1354 Figure 18: SM: Summary of the Use of Headers from RAL to RAL 1356 7.3.2. SM: Example of Flow from RAL to RUL 1358 In this case the flow comprises: 1360 RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) --> 1361 6LR_id --> RUL (IPv6 dst node) 1363 For example, a communication flow could be: Node F (RAL)--> Node D 1364 --> Node B--> Node A -->Node B --> Node E --> Node G (RUL) 1366 6LR_ia represents the intermediate routers from source (RAL) to the 1367 common parent (the Root), 1 <= ia <= n, where n is the total number 1368 of routers (6LR) that the packet goes through from RAL to the Root. 1370 6LR_id (Node E) represents the intermediate routers from the Root 1371 (Node B) to destination RUL (Node G). In this case, 1 <= id <= m, 1372 where m is the total number of routers (6LR) that the packet goes 1373 through from the Root down to the destination RUL. 1375 In this case, the packet from the RAL goes to 6LBR because the route 1376 to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an 1377 RPI (RPI1) addressed to the root(6LBR). The root does not removes 1378 the RPI1 (the root cannot remove an RPI if there is no 1379 encapsulation). The root inserts an RPI2 encapsulated to the 6LR 1380 parent of the RUL, which removes the RPI2 before pasing the packet to 1381 the RUL. 1383 The Figure 19 summarizes what headers are needed for this use case. 1385 +----------+-------+-------+---------+---------+---------+---------+ 1386 | Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 1387 | | src | | | | | dst | 1388 | | node | | | | | node | 1389 +----------+-------+-------+---------+---------+---------+---------+ 1390 | Added | | | IP6-IP6 | -- | -- | -- | 1391 | headers | RPI1 | -- | (RPI2) | | | | 1392 | | | | | | | | 1393 +----------+-------+-------+---------+---------+---------+---------+ 1394 | Modified | -- | | -- | | | -- | 1395 | headers | | RPI1 | | RPI2 | -- | | 1396 | | | | | | | | 1397 +----------+-------+-------+---------+---------+---------+---------+ 1398 | Removed | -- | -- | | -- | IP6-IP6 | -- | 1399 | headers | | | -- | | (RPI2) | | 1400 | | | | | | | | 1401 +----------+-------+-------+---------+---------+---------+---------+ 1402 |Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 1403 | headers | | | | | |(Ignored)| 1404 | | | | | | | | 1405 +----------+-------+-------+---------+---------+---------+---------+ 1407 Figure 19: SM: Summary of the Use of Headers from RAL to RUL 1409 7.3.3. SM: Example of Flow from RUL to RAL 1411 In this case the flow comprises: 1413 RUL (IPv6 src node) --> 6LR_ia --> 6LBR --> 6LR_id --> RAL dst (6LN) 1415 For example, a communication flow could be: Node G (RUL)--> Node E 1416 --> Node B --> Node A --> Node B --> Node D --> Node F (RAL) 1418 6LR_ia (Node E) represents the intermediate routers from source (RUL) 1419 (Node G) to the root (Node A). In this case, 1 <= ia <= n, where n 1420 is the total number of routers (6LR) that the packet goes through 1421 from source to the root. 1423 6LR_id represents the intermediate routers from the root (Node A) to 1424 destination RAL (Node F). In this case, 1 <= id <= m, where m is the 1425 total number of routers (6LR) that the packet goes through from the 1426 root to the destination RAL. 1428 The 6LR_ia (ia=1) (Node E) receives the packet from the RUL (Node G) 1429 and inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to 1430 the root. The root removes the outer header including the RPI (RPI1) 1431 and inserts a new RPI (RPI2) addressed to the destination RAL (Node 1432 F). 1434 The Figure 20 shows the table that summarizes what headers are needed 1435 for this use case. 1437 +-----------+------+---------+---------+---------+---------+---------+ 1438 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 1439 | | src | | | | | dst | 1440 | | node | | | | | node | 1441 +-----------+------+---------+---------+---------+---------+---------+ 1442 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1443 | headers | | (RPI1) | | (RPI2) | | | 1444 | | | | | | | | 1445 +-----------+------+---------+---------+---------+---------+---------+ 1446 | Modified | -- | | | -- | | -- | 1447 | headers | | -- | RPI1 | | RPI2 | | 1448 | | | | | | | | 1449 +-----------+------+---------+---------+---------+---------+---------+ 1450 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1451 | headers | | -- | | (RPI1) | | (RPI2) | 1452 | | | | | | | | 1453 +-----------+------+---------+---------+---------+---------+---------+ 1454 | Untouched | -- | -- | -- | -- | -- | -- | 1455 | headers | | | | | | | 1456 +-----------+------+---------+---------+---------+---------+---------+ 1458 Figure 20: SM: Summary of the use of headers from RUL to RAL. 1460 7.3.4. SM: Example of Flow from RUL to RUL 1462 In this case the flow comprises: 1464 RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> RUL 1465 (IPv6 dst node) 1467 For example, a communication flow could be: Node G (RUL src)--> Node 1468 E --> Node B --> Node A (root) --> Node C --> Node J (RUL dst) 1470 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1471 router from the RUL source (Node G) to the root (6LBR) (Node A). In 1472 this case, 1 <= ia <= n, where n is the total number of routers (6LR) 1473 that the packet goes through from the RUL to the root. 6LR_1 refers 1474 when ia=1. 1476 6LR_id (Node C) represents the intermediate routers from the root 1477 (Node A) to the destination RUL dst node (Node J). In this case, 1 1478 <= id <= m, where m is the total number of routers (6LR) that the 1479 packet goes through from the root to destination RUL. 1481 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1482 inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header 1483 directed to the root. The root removes the outer header including 1484 the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR 1485 father of the RUL. 1487 The Figure 21 shows the table that summarizes what headers are needed 1488 for this use case. 1490 +---------+----+-------------+--------+---------+--------+-------+---+ 1491 | Header |RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id |6LR_n |RUL| 1492 | |src | | | | | |dst| 1493 | | | | | | | | | 1494 +---------+----+-------------+--------+---------+--------+-------+---+ 1495 | Added | -- |IP6-IP6(RPI1)| -- | IP6-IP6 | -- | -- | --| 1496 | Headers | | | | (RPI2) | | | | 1497 +---------+----+-------------+--------+---------+--------+-------+---+ 1498 |Modified | -- | -- | | -- | | -- | --| 1499 |headers | | | RPI1 | | RPI2 | | | 1500 +---------+----+-------------+--------+---------+--------+-------+---+ 1501 | Removed | -- | -- | -- | IP6-IP6 | -- |IP6-IP6| --| 1502 | headers | | | | (RPI1) | | (RPI2)| | 1503 +---------+----+-------------+--------+---------+--------+-------+---+ 1504 |Untouched| -- | -- | -- | -- | -- | -- | --| 1505 | headers | | | | | | | | 1506 +---------+----+-------------+--------+---------+--------+-------+---+ 1508 Figure 21: SM: Summary of the use of headers from RUL to RUL 1510 8. Non Storing mode 1512 In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG 1513 root) has complete knowledge about the connectivity of all DODAG 1514 nodes, and all traffic flows through the root node. Thus, there is 1515 no need for all nodes to know about the existence of RPL-unaware 1516 nodes. Only the 6LBR needs to act if compensation is necessary for 1517 not-RPL aware receivers. 1519 The table (Figure 22) summarizes what headers are needed in the 1520 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 1521 header are to be inserted. The last column depicts the target 1522 destination of the IPv6-in-IPv6 header: 6LN (indicated by "RAL"), 6LR 1523 (parent of a RUL) or the root. In cases where no IPv6-in-IPv6 header 1524 is needed, the column indicates "No". There is no expectation on RPL 1525 that RPI can be omitted, because it is needed for routing, quality of 1526 service and compression. This specification expects that an RPI is 1527 always present. The term "may(up)" means that the IPv6-in-IPv6 1528 header may be necessary in the upwards direction. The term 1529 "must(up)" means that the IPv6-in-IPv6 header must be present in the 1530 upwards direction. The term "must(down)" means that the IPv6-in-IPv6 1531 header must be present in the downward direction. 1533 The leaf can be a router 6LR or a host, both indicated as 6LN 1534 (Figure 6). In the table (Figure 22) the (1) indicates a 6tisch case 1535 [RFC8180], where the RPI may still be needed for the RPLInstanceID to 1536 be available for priority/channel selection at each hop. 1538 The root always have to encapuslate on the way down 1540 +--- ------------+-------------+-----+-----+--------------+----------+ 1541 | Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP | 1542 | between | | | | | dst | 1543 +----------------+-------------+-----+-----+--------------+----------+ 1544 | | RAL to root | Yes | No | No | No | 1545 | +-------------+-----+-----+--------------+----------+ 1546 | Leaf - Root | root to RAL | Yes | Yes | No | No | 1547 | +-------------+-----+-----+--------------+----------+ 1548 | | root to RUL | Yes | Yes | must | 6LR | 1549 | | | (1) | | | | 1550 | +-------------+-----+-----+--------------+----------+ 1551 | | RUL to root | Yes | No | must | root | 1552 +----------------+-------------+-----+-----+--------------+----------+ 1553 | | RAL to Int | Yes | No | may(up) | root | 1554 | +-------------+-----+-----+--------------+----------+ 1555 |Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | 1556 | +-------------+-----+-----+--------------+----------+ 1557 | | RUL to Int | Yes | No | must | root | 1558 | +-------------+-----+-----+--------------+----------+ 1559 | | Int to RUL | Yes | Yes | must | 6LR | 1560 +----------------+-------------+-----+-----+--------------+----------+ 1561 | | RAL to RAL | Yes | Yes | may(up) | root | 1562 | | | | +--------------+----------+ 1563 | | | | | must(down) | RAL | 1564 | Leaf - Leaf +-------------+-----+-----+--------------+----------+ 1565 | | RAL to RUL | Yes | Yes | may(up) | root | 1566 | | | | +--------------+----------+ 1567 | | | | | must(down) | 6LR | 1568 | +-------------+-----+-----+--------------+----------+ 1569 | | RUL to RAL | Yes | Yes | must(up) | root | 1570 | | | | +--------------+----------+ 1571 | | | | | must(down) | RAL | 1572 | +-------------+-----+-----+--------------+----------+ 1573 | | RUL to RUL | Yes | Yes | must(up) | root | 1574 | | | | +--------------+----------+ 1575 | | | | | must(down) | 6LR | 1576 +----------------+-------------+-----+-----+--------------+----------+ 1578 Figure 22: Table that shows headers needed in Non-Storing mode: RPI, 1579 RH3, IPv6-in-IPv6 encapsulation. 1581 8.1. Non-Storing Mode: Interaction between Leaf and Root 1583 In this section is described the communication flow in Non Storing 1584 Mode (Non-SM) between, 1586 RAL to root 1588 root to RAL 1590 RUL to root 1592 root to RUL 1594 8.1.1. Non-SM: Example of Flow from RAL to root 1596 In non-storing mode the leaf node uses default routing to send 1597 traffic to the root. The RPI must be included since it contains the 1598 rank information, which is used to avoid/detect loops. 1600 RAL (6LN) --> 6LR_i --> root(6LBR) 1602 For example, a communication flow could be: Node F --> Node D --> 1603 Node B --> Node A (root) 1605 6LR_i represents the intermediate routers from source to destination. 1606 In this case, 1 <= i <= n, where n is the total number of routers 1607 (6LR) that the packet goes through from source (RAL) to destination 1608 (6LBR). 1610 This situation is the same case as storing mode. 1612 The Figure 23 summarizes what headers are needed for this use case. 1614 +-----------+-----+-------+------+ 1615 | Header | RAL | 6LR_i | 6LBR | 1616 | | src | | dst | 1617 +-----------+-----+-------+------+ 1618 | Added | RPI | -- | -- | 1619 | headers | | | | 1620 +-----------+-----+-------+------+ 1621 | Modified | -- | RPI | -- | 1622 | headers | | | | 1623 +-----------+-----+-------+------+ 1624 | Removed | -- | -- | RPI | 1625 | headers | | | | 1626 +-----------+-----+-------+------+ 1627 | Untouched | -- | -- | -- | 1628 | headers | | | | 1629 +-----------+-----+-------+------+ 1631 Figure 23: Non-SM: Summary of the use of headers from RAL to root 1633 8.1.2. Non-SM: Example of Flow from root to RAL 1635 In this case the flow comprises: 1637 root (6LBR) --> 6LR_i --> RAL (6LN) 1639 For example, a communication flow could be: Node A (root) --> Node B 1640 --> Node D --> Node F 1642 6LR_i represents the intermediate routers from source to destination. 1643 In this case, 1 <= i <= n, where n is the total number of routers 1644 (6LR) that the packet goes through from source (6LBR) to destination 1645 (RAL). 1647 The 6LBR inserts an RH3, and an RPI. No IPv6-in-IPv6 header is 1648 necessary as the traffic originates with a RPL aware node, the 6LBR. 1649 The destination is known to be RPL-aware because the root knows the 1650 whole topology in non-storing mode. 1652 The Figure 24 summarizes what headers are needed for this use case. 1654 +-----------+----------+----------+----------+ 1655 | Header | 6LBR | 6LR_i | RAL | 1656 | | src | | dst | 1657 +-----------+----------+----------+----------+ 1658 | Added | RPI, RH3 | -- | -- | 1659 | headers | | | | 1660 +-----------+----------+----------+----------+ 1661 | Modified | -- | RPI, RH3 | -- | 1662 | headers | | | | 1663 +-----------+----------+----------+----------+ 1664 | Removed | -- | -- | RPI, RH3 | 1665 | headers | | | | 1666 +-----------+----------+----------+----------+ 1667 | Untouched | -- | -- | -- | 1668 | headers | | | | 1669 +-----------+----------+----------+----------+ 1671 Figure 24: Non-SM: Summary of the use of headers from root to RAL 1673 8.1.3. Non-SM: Example of Flow from root to RUL 1675 In this case the flow comprises: 1677 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1679 For example, a communication flow could be: Node A (root) --> Node B 1680 --> Node E --> Node G (RUL) 1682 6LR_i represents the intermediate routers from source to destination. 1683 In this case, 1 <= i <= n, where n is the total number of routers 1684 (6LR) that the packet goes through from source (6LBR) to destination 1685 (RUL). 1687 In the 6LBR, the RH3 is added; it is then modified at each 1688 intermediate 6LR (6LR_1 and so on), and it is fully consumed in the 1689 last 6LR (6LR_n) but is left in place. When the RPI is added, the 1690 RUL, which does not understand the RPI, will ignore it (per 1691 [RFC8200]); thus, encapsulation is not necessary. 1693 The Figure 25 depicts the table that summarizes what headers are 1694 needed for this use case. 1696 +-----------+----------+--------------+----------------+----------+ 1697 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1698 | | src | i=(1,..,n-1) | | dst | 1699 | | | | | | 1700 +-----------+----------+--------------+----------------+----------+ 1701 | Added | RPI, RH3 | -- | -- | -- | 1702 | headers | | | | | 1703 +-----------+----------+--------------+----------------+----------+ 1704 | Modified | -- | RPI, RH3 | RPI, | -- | 1705 | headers | | | RH3(consumed) | | 1706 +-----------+----------+--------------+----------------+----------+ 1707 | Removed | -- | -- | -- | -- | 1708 | headers | | | | | 1709 +-----------+----------+--------------+----------------+----------+ 1710 | Untouched | -- | -- | -- | RPI, RH3 | 1711 | headers | | | | (both | 1712 | | | | | ignored) | 1713 +-----------+----------+--------------+----------------+----------+ 1715 Figure 25: Non-SM: Summary of the use of headers from root to RUL 1717 8.1.4. Non-SM: Example of Flow from RUL to root 1719 In this case the flow comprises: 1721 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst 1723 For example, a communication flow could be: Node G --> Node E --> 1724 Node B --> Node A (root) 1726 6LR_i represents the intermediate routers from source to destination. 1727 In this case, 1 <= i <= n, where n is the total number of routers 1728 (6LR) that the packet goes through from source (RUL) to destination 1729 (6LBR). For example, 6LR_1 (i=1) is the router that receives the 1730 packets from the RUL. 1732 In this case, the RPI is added by the first 6LR (6LR_1) (Node E), 1733 encapsulated in an IPv6-in-IPv6 header, and modified in the 1734 subsequent 6LRs in the flow. The RPI and the entire packet are 1735 consumed by the root. 1737 The Figure 26 shows the table that summarizes what headers are needed 1738 for this use case. 1740 +---------+----+-----------------+-----------------+-----------------+ 1741 | |RUL | | | | 1742 | Header |src | 6LR_1 | 6LR_i | 6LBR dst | 1743 | |node| | | | 1744 +---------+----+-----------------+-----------------+-----------------+ 1745 | Added | -- |IPv6-in-IPv6(RPI)| -- | -- | 1746 | headers | | | | | 1747 +---------+----+-----------------+-----------------+-----------------+ 1748 | Modified| -- | -- | RPI | -- | 1749 | headers | | | | | 1750 +---------+----+-----------------+-----------------+-----------------+ 1751 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1752 | headers | | | | | 1753 +---------+----+-----------------+-----------------+-----------------+ 1754 |Untouched| -- | -- | -- | -- | 1755 | headers | | | | | 1756 +---------+----+-----------------+-----------------+-----------------+ 1758 Figure 26: Non-SM: Summary of the use of headers from RUL to root 1760 8.2. Non-Storing Mode: Interaction between Leaf and Internet 1762 This section will describe the communication flow in Non Storing Mode 1763 (Non-SM) between: 1765 RAL to Internet 1767 Internet to RAL 1769 RUL to Internet 1771 Internet to RUL 1773 8.2.1. Non-SM: Example of Flow from RAL to Internet 1775 In this case the flow comprises: 1777 RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst 1779 For example, a communication flow could be: Node F (RAL) --> Node D 1780 --> Node B --> Node A --> Internet 1782 6LR_i represents the intermediate routers from source to destination, 1783 1 <= i <= n, where n is the total number of routers (6LR) that the 1784 packet goes through from source (RAL) to 6LBR. 1786 In this case, the encapsulation from the RAL to the root is optional. 1787 The simplest case is when the RPI gets to the Internet (as the 1788 Figure 27 shows it), knowing that the Internet is going to ignore it. 1790 The IPv6 flow label should be set to zero to aid in compression 1791 [RFC8138], and the 6LBR will set it to a non-zero value when sending 1792 towards the Internet [RFC6437]. 1794 The Figure 27 summarizes what headers are needed for this use case 1795 when no encapsulation is used. The Figure 28 summarizes what headers 1796 are needed for this use case when encapsulation to the root is used. 1798 +-----------+-----+-------+------+-----------+ 1799 | Header | RAL | 6LR_i | 6LBR | Internet | 1800 | | src | | | dst | 1801 +-----------+-----+-------+------+-----------+ 1802 | Added | RPI | -- | -- | -- | 1803 | headers | | | | | 1804 +-----------+-----+-------+------+-----------+ 1805 | Modified | -- | RPI | RPI | -- | 1806 | headers | | | | | 1807 +-----------+-----+-------+------+-----------+ 1808 | Removed | -- | -- | -- | -- | 1809 | headers | | | | | 1810 +-----------+-----+-------+------+-----------+ 1811 | Untouched | -- | -- | -- | RPI | 1812 | headers | | | | (Ignored) | 1813 +-----------+-----+-------+------+-----------+ 1815 Figure 27: Non-SM: Summary of the use of headers from RAL to Internet 1816 with no encapsulation 1818 +-----------+--------------+--------------+--------------+----------+ 1819 | Header | RAL | 6LR_i | 6LBR | Internet | 1820 | | src | | | dst | 1821 +-----------+--------------+--------------+--------------+----------+ 1822 | Added | IPv6-in-IPv6 | -- | -- | -- | 1823 | headers | (RPI) | | | | 1824 +-----------+--------------+--------------+--------------+----------+ 1825 | Modified | -- | | -- | -- | 1826 | headers | | RPI | | | 1827 +-----------+--------------+--------------+--------------+----------+ 1828 | Removed | -- | -- | IPv6-in-IPv6 | -- | 1829 | headers | | | (RPI) | | 1830 +-----------+--------------+--------------+--------------+----------+ 1831 | Untouched | -- | -- | -- | -- | 1832 | headers | | | | | 1833 +-----------+--------------+--------------+--------------+----------+ 1835 Figure 28: Non-SM: Summary of the use of headers from RAL to Internet 1836 with encapsulation to the root 1838 8.2.2. Non-SM: Example of Flow from Internet to RAL 1840 In this case the flow comprises: 1842 Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN) 1844 For example, a communication flow could be: Internet --> Node A 1845 (root) --> Node B --> Node D --> Node F (RAL) 1847 6LR_i represents the intermediate routers from source to destination, 1848 1 <= i <= n, where n is the total number of routers (6LR) that the 1849 packet goes through from 6LBR to destination (RAL). 1851 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1852 address of the target node, it can address the IPv6-in-IPv6 header to 1853 that node. The 6LBR will zero the flow label upon entry in order to 1854 aid compression [RFC8138]. 1856 The Figure 29 summarizes what headers are needed for this use case. 1858 +-----------+----------+--------------+--------------+--------------+ 1859 | Header | Internet | 6LBR | 6LR_i | RAL | 1860 | | src | | | dst | 1861 +-----------+----------+--------------+--------------+--------------+ 1862 | Added | -- | IPv6-in-IPv6 | -- | -- | 1863 | headers | | (RH3, RPI) | | | 1864 +-----------+----------+--------------+--------------+--------------+ 1865 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1866 | headers | | | (RH3, RPI) | | 1867 +-----------+----------+--------------+--------------+--------------+ 1868 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1869 | headers | | | | (RH3, RPI) | 1870 +-----------+----------+--------------+--------------+--------------+ 1871 | Untouched | -- | -- | -- | -- | 1872 | headers | | | | | 1873 +-----------+----------+--------------+--------------+--------------+ 1875 Figure 29: Non-SM: Summary of the use of headers from Internet to RAL 1877 8.2.3. Non-SM: Example of Flow from RUL to Internet 1879 In this case the flow comprises: 1881 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1882 dst 1884 For example, a communication flow could be: Node G --> Node E --> 1885 Node B --> Node A --> Internet 1887 6LR_i represents the intermediate routers from source to destination, 1888 1 <= i <= n, where n is the total number of routers (6LRs) that the 1889 packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1 1890 (i=1). 1892 In this case the flow label is recommended to be zero in the RUL. As 1893 RPL headers are added in the RUL packet, the first 6LR (6LR_1) will 1894 add an RPI inside a new IPv6-in-IPv6 header. The IPv6-in-IPv6 header 1895 will be addressed to the root. This case is identical to the 1896 storing-mode case (see Section 7.2.3). 1898 The Figure 30 shows the table that summarizes what headers are needed 1899 for this use case. 1901 +---------+----+-------------+--------------+--------------+--------+ 1902 | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| 1903 | |src | | [i=2,..,n] | | dst | 1904 | |node| | | | | 1905 +---------+----+-------------+--------------+--------------+--------+ 1906 | Added | -- |IP6-IP6(RPI) | -- | -- | -- | 1907 | headers | | | | | | 1908 +---------+----+-------------+--------------+--------------+--------+ 1909 | Modified| -- | -- | RPI | -- | -- | 1910 | headers | | | | | | 1911 +---------+----+-------------+--------------+--------------+--------+ 1912 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1913 | headers | | | | | | 1914 +---------+----+-------------+--------------+--------------+--------+ 1915 |Untouched| -- | -- | -- | -- | -- | 1916 | headers | | | | | | 1917 +---------+----+-------------+--------------+--------------+--------+ 1919 Figure 30: Non-SM: Summary of the use of headers from RUL to Internet 1921 8.2.4. Non-SM: Example of Flow from Internet to RUL 1923 In this case the flow comprises: 1925 Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1927 For example, a communication flow could be: Internet --> Node A 1928 (root) --> Node B --> Node E --> Node G 1930 6LR_i represents the intermediate routers from source to destination, 1931 1 <= i <= n, where n is the total number of routers (6LR) that the 1932 packet goes through from 6LBR to RUL. 1934 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1935 6LBR will know the path, and will recognize that the final node is 1936 not a RPL capable node as it will have received the connectivity DAO 1937 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1938 header destination be the last 6LR. The 6LBR will set to zero the 1939 flow label upon entry in order to aid compression [RFC8138]. 1941 The Figure 31 shows the table that summarizes what headers are needed 1942 for this use case. 1944 +----------+--------+------------------+-----------+-----------+-----+ 1945 | Header |Internet| 6LBR | 6LR_i | 6LR_n | RUL | 1946 | | src | | | | dst | 1947 +----------+--------+------------------+-----------+-----------+-----+ 1948 | Added | -- | IP6-IP6(RH3,RPI) | -- | -- | -- | 1949 | headers | | | | | | 1950 +----------+--------+------------------+-----------+-----------+-----+ 1951 | Modified | -- | -- | IP6-IP6 | -- | -- | 1952 | headers | | | (RH3,RPI) | | | 1953 +----------+--------+------------------+-----------+-----------+-----+ 1954 | Removed | -- | -- | -- | IP6-IP6 | -- | 1955 | headers | | | | (RH3,RPI) | | 1956 +----------+--------+------------------+-----------+-----------+-----+ 1957 |Untouched | -- | -- | -- | -- | -- | 1958 | headers | | | | | | 1959 +----------+--------+------------------+-----------+-----------+-----+ 1961 Figure 31: Non-SM: Summary of the use of headers from Internet to 1962 RUL. 1964 8.3. Non-SM: Interaction between leaves 1966 In this section is described the communication flow in Non Storing 1967 Mode (Non-SM) between, 1969 RAL to RAL 1971 RAL to RUL 1973 RUL to RAL 1975 RUL to RUL 1977 8.3.1. Non-SM: Example of Flow from RAL to RAL 1979 In this case the flow comprises: 1981 RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst 1983 For example, a communication flow could be: Node F (RAL src)--> Node 1984 D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL 1985 dst) 1987 6LR_ia represents the intermediate routers from source to the root, 1 1988 <= ia <= n, where n is the total number of routers (6LR) that the 1989 packet goes through from RAL to the root. 1991 6LR_id represents the intermediate routers from the root to the 1992 destination, 1 <= id <= m, where m is the total number of the 1993 intermediate routers (6LR). 1995 This case involves only nodes in same RPL domain. The originating 1996 node will add an RPI to the original packet, and send the packet 1997 upwards. 1999 The originating node may put the RPI (RPI1) into an IPv6-in-IPv6 2000 header addressed to the root, so that the 6LBR can remove that 2001 header. If it does not, then the RPI1 is forwarded down from the 2002 root in the inner header to no avail. 2004 The 6LBR will need to insert an RH3 header, which requires that it 2005 add an IPv6-in-IPv6 header. It removes the RPI(RPI1), as it was 2006 contained in an IPv6-in-IPv6 header addressed to it. Otherwise, 2007 there may be an RPI buried inside the inner IP header, which should 2008 get ignored. The root inserts an RPI (RPI2) alongside the RH3. 2010 Networks that use the RPL P2P extension [RFC6997] are essentially 2011 non-storing DODAGs and fall into this scenario or scenario 2012 Section 8.1.2, with the originating node acting as 6LBR. 2014 The Figure 32 shows the table that summarizes what headers are needed 2015 for this use case when encapsulation to the root takes place. 2017 The Figure 33 shows the table that summarizes what headers are needed 2018 for this use case when there is no encapsulation to the root. Note 2019 that in the Modified headers row, going up in each 6LR_ia only the 2020 RPI1 is changed. Going down, in each 6LR_id the IPv6 header is 2021 swapped with the RH3 so both are changed alongside with the RPI2. 2023 +---------+-------+----------+------------+----------+------------+ 2024 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 2025 | | src | | | | dst | 2026 +---------+-------+----------+------------+----------+------------+ 2027 | Added |IP6-IP6| | IP6-IP6 | -- | -- | 2028 | headers |(RPI1) | -- |(RH3-> RAL, | | | 2029 | | | | RPI2) | | | 2030 +---------+-------+----------+------------+----------+------------+ 2031 | Modified| -- | | -- | IP6-IP6 | -- | 2032 | headers | | RPI1 | |(RH3,RPI2)| | 2033 +---------+-------+----------+------------+----------+------------+ 2034 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | 2035 | headers | | | (RPI1) | | (RH3, | 2036 | | | | | | RPI2) | 2037 +---------+-------+----------+------------+----------+------------+ 2038 |Untouched| -- | -- | -- | -- | -- | 2039 | headers | | | | | | 2040 +---------+-------+----------+------------+----------+------------+ 2042 Figure 32: Non-SM: Summary of the Use of Headers from RAL to RAL with 2043 encapsulation to the root. 2045 +-----------+------+--------+---------+---------+---------+ 2046 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 2047 +-----------+------+--------+---------+---------+---------+ 2048 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | 2049 | headers | | | (RH3, | | | 2050 | | | | RPI2) | | | 2051 +-----------+------+--------+---------+---------+---------+ 2052 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | 2053 | headers | | | | (RH3, | | 2054 | | | | | RPI2) | | 2055 +-----------+------+--------+---------+---------+---------+ 2056 | Removed | -- | -- | -- | -- | IP6-IP6 | 2057 | headers | | | | | (RH3, | 2058 | | | | | | RPI2) | 2059 | | | | | | | 2060 +-----------+------+--------+---------+---------+---------+ 2061 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | 2062 | headers | | | | |(Ignored)| 2063 +-----------+------+--------+---------+---------+---------+ 2065 Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL 2066 without encapsulation to the root. 2068 8.3.2. Non-SM: Example of Flow from RAL to RUL 2070 In this case the flow comprises: 2072 RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node) 2074 For example, a communication flow could be: Node F (RAL) --> Node D 2075 --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL) 2077 6LR_ia represents the intermediate routers from source to the root, 1 2078 <= ia <= n, where n is the total number of intermediate routers (6LR) 2080 6LR_id represents the intermediate routers from the root to the 2081 destination, 1 <= id <= m, where m is the total number of the 2082 intermediate routers (6LRs). 2084 As in the previous case, the RAL (6LN) may insert an RPI (RPI1) 2085 header which must be in an IPv6-in-IPv6 header addressed to the root 2086 so that the 6LBR can remove this RPI. The 6LBR will then insert an 2087 RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id 2088 (6LR_id = m) alongside the insertion of RPI2. 2090 If the originating node does not not put the RPI (RPI1) into an IPv6- 2091 in-IPv6 header addressed to the root. Then, the RPI1 is forwarded 2092 down from the root in the inner header to no avail. 2094 The Figure 34 shows the table that summarizes what headers are needed 2095 for this use case when encapsulation to the root takes place. The 2096 Figure 35 shows the table that summarizes what headers are needed for 2097 this use case when no encapsulation to the root takes place. 2099 +-----------+---------+---------+---------+---------+---------+------+ 2100 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 2101 | | src | | | | | dst | 2102 | | node | | | | | node | 2103 +-----------+---------+---------+---------+---------+---------+------+ 2104 | Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 2105 | headers | (RPI1) | -- | (RH3, | | | | 2106 | | | | RPI2) | | | | 2107 +-----------+---------+---------+---------+---------+---------+------+ 2108 | Modified | -- | | -- | IP6-IP6 | | -- | 2109 | headers | | RPI1 | | (RH3, | -- | | 2110 | | | | | RPI2) | | | 2111 +-----------+---------+---------+---------+---------+---------+------+ 2112 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2113 | headers | | | (RPI1) | | (RH3, | | 2114 | | | | | | RPI2) | | 2115 +-----------+---------+---------+---------+---------+---------+------+ 2116 | Untouched | -- | -- | -- | -- | -- | -- | 2117 | headers | | | | | | | 2118 +-----------+---------+---------+---------+---------+---------+------+ 2120 Figure 34: Non-SM: Summary of the use of headers from RAL to RUL with 2121 encapsulation to the root. 2123 +-----------+------+--------+---------+---------+---------+---------+ 2124 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL | 2125 | | src | | | | | dst | 2126 | | node | | | | | node | 2127 +-----------+------+--------+---------+---------+---------+---------+ 2128 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | -- | 2129 | headers | | | (RH3, | | | | 2130 | | | | RPI2) | | | | 2131 +-----------+------+--------+---------+---------+---------+---------+ 2132 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- | 2133 | headers | | | | (RH3, | | | 2134 | | | | | RPI2) | | | 2135 +-----------+------+--------+---------+---------+---------+---------+ 2136 | Removed | -- | -- | -- | -- | IP6-IP6 | -- | 2137 | headers | | | | | (RH3, | | 2138 | | | | | | RPI2) | | 2139 +-----------+------+--------+---------+---------+---------+---------+ 2140 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 2141 | headers | | | | | |(Ignored)| 2142 +-----------+------+--------+---------+---------+---------+---------+ 2144 Figure 35: Non-SM: Summary of the use of headers from RAL to RUL 2145 without encapsulation to the root. 2147 8.3.3. Non-SM: Example of Flow from RUL to RAL 2149 In this case the flow comprises: 2151 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2152 --> RAL dst (6LN) 2154 For example, a communication flow could be: Node G (RUL)--> Node E 2155 --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL) 2157 6LR_ia represents the intermediate routers from source to the root, 1 2158 <= ia <= n, where n is the total number of intermediate routers (6LR) 2160 6LR_id represents the intermediate routers from the root to the 2161 destination, 1 <= id <= m, where m is the total number of the 2162 intermediate routers (6LR). 2164 In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1) 2165 inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will 2166 remove this RPI, and add it's own IPv6-in-IPv6 header containing an 2167 RH3 header and an RPI (RPI2). 2169 The Figure 36 shows the table that summarizes what headers are needed 2170 for this use case. 2172 +----------+------+---------+---------+---------+---------+---------+ 2173 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 2174 | | src | | | | | dst | 2175 | | node | | | | | node | 2176 +----------+------+---------+---------+---------+---------+---------+ 2177 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 2178 | headers | | (RPI1) | | (RH3, | | | 2179 | | | | | RPI2) | | | 2180 +----------+------+---------+---------+---------+---------+---------+ 2181 | Modified | -- | | | -- | IP6-IP6 | -- | 2182 | headers | | -- | RPI1 | | (RH3, | | 2183 | | | | | | RPI2) | | 2184 +----------+------+---------+---------+---------+---------+---------+ 2185 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 2186 | headers | | -- | | (RPI1) | | (RH3, | 2187 | | | | | | | RPI2) | 2188 +----------+------+---------+---------+---------+---------+---------+ 2189 |Untouched | -- | -- | -- | -- | -- | -- | 2190 | headers | | | | | | | 2191 +----------+------+---------+---------+---------+---------+---------+ 2193 Figure 36: Non-SM: Summary of the use of headers from RUL to RAL. 2195 8.3.4. Non-SM: Example of Flow from RUL to RUL 2197 In this case the flow comprises: 2199 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2200 --> RUL (IPv6 dst node) 2202 For example, a communication flow could be: Node G --> Node E --> 2203 Node B --> Node A (root) --> Node C --> Node J 2205 6LR_ia represents the intermediate routers from source to the root, 1 2206 <= ia <= n, where n is the total number of intermediate routers (6LR) 2208 6LR_id represents the intermediate routers from the root to the 2209 destination, 1 <= id <= m, where m is the total number of the 2210 intermediate routers (6LR). 2212 This scenario is the combination of the previous two cases. 2214 The Figure 37 shows the table that summarizes what headers are needed 2215 for this use case. 2217 +---------+------+-------+-------+---------+-------+---------+------+ 2218 | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL | 2219 | | src | | | | | | dst | 2220 | | node | | | | | | node | 2221 +---------+------+-------+-------+---------+-------+---------+------+ 2222 | Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 2223 | headers | | (RPI1)| | (RH3, | | | | 2224 | | | | | RPI2) | | | | 2225 +---------+------+-------+-------+---------+-------+---------+------+ 2226 | Modified| -- | -- | | -- |IP6-IP6| -- | -- | 2227 | headers | | | RPI1 | | (RH3, | | | 2228 | | | | | | RPI2)| | | 2229 +---------+------+-------+-------+---------+-------+---------+------+ 2230 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2231 | headers | | | | (RPI1) | | (RH3, | | 2232 | | | | | | | RPI2) | | 2233 +---------+------+-------+-------+---------+-------+---------+------+ 2234 |Untouched| -- | -- | -- | -- | -- | -- | -- | 2235 | headers | | | | | | | | 2236 +---------+------+-------+-------+---------+-------+---------+------+ 2238 Figure 37: Non-SM: Summary of the use of headers from RUL to RUL 2240 9. Operational Considerations of supporting RUL-leaves 2242 Roughly half of the situations described in this document involve 2243 leaf ("host") nodes that do not speak RPL. These nodes fall into two 2244 further categories: ones that drop a packet that have RPI or RH3 2245 headers, and ones that continue to process a packet that has RPI and/ 2246 or RH3 headers. 2248 [RFC8200] provides for new rules that suggest that nodes that have 2249 not been configured (explicitly) to examine Hop-by-Hop headers, 2250 should ignore those headers, and continue processing the packet. 2251 Despite this, and despite the switch from 0x63 to 0x23, there may be 2252 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 2253 drop packets that continue to have RPL artifacts in them. In 2254 general, such hosts can not be easily supported in RPL LLNs. 2256 There are some specific cases where it is possible to remove the RPL 2257 artifacts prior to forwarding the packet to the leaf host. The 2258 critical thing is that the artifacts have been inserted by the RPL 2259 root inside an IPv6-in-IPv6 header, and that the header has been 2260 addressed to the 6LR immediately prior to the leaf node. In that 2261 case, in the process of removing the IPv6-in-IPv6 header, the 2262 artifacts can also be removed. 2264 The above case occurs whenever traffic originates from the outside 2265 the LLN (the "Internet" cases above), and non-storing mode is used. 2266 In non-storing mode, the RPL root knows the exact topology (as it 2267 must create the RH3 header) and therefore knows which 6LR is prior to 2268 the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf 2269 Node G, or Node C is the 6LR prior to leaf Node J. 2271 traffic originating from the RPL root (such as when the data 2272 collection system is co-located on the RPL root), does not require an 2273 IPv6-in-IPv6 header (in storing or non-storing mode), as the packet 2274 is originating at the root, and the root can insert the RPI and RH3 2275 headers directly into the packet, as it is formed. Such a packet is 2276 slightly smaller, but only can be sent to nodes (whether RPL aware or 2277 not), that will tolerate the RPL artifacts. 2279 An operator that finds itself with a high amount of traffic from the 2280 RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 2281 encapsulation if the leaf is not tolerant of the RPL artifacts. Such 2282 an operator could otherwise omit this unnecessary header if it was 2283 certain of the properties of the leaf. 2285 As storing mode can not know the final path of the traffic, 2286 intolerant (that drop packets with RPL artifacts) leaf nodes can not 2287 be supported. 2289 10. Operational considerations of introducing 0x23 2291 This section describes the operational considerations of introducing 2292 the new RPI Option Type of 0x23. 2294 During bootstrapping the node gets the DIO with the information of 2295 RPI Option Type, indicating the new RPI in the DODAG Configuration 2296 option Flag. The DODAG root is in charge to configure the current 2297 network to the new value, through DIO messages and when all the nodes 2298 are set with the new value. The DODAG should change to a new DODAG 2299 version. In case of rebooting, the node does not remember the RPI 2300 Option Type. Thus, the DIO is sent with a flag indicating the new 2301 RPI Option Type. 2303 The DODAG Configuration option is contained in a RPL DIO message, 2304 which contains a unique DTSN counter. The leaf nodes respond to this 2305 message with DAO messages containing the same DTSN. This is a normal 2306 part of RPL routing; the RPL root therefore knows when the updated 2307 DODAG Configuration option has been seen by all nodes. 2309 Before the migration happens, all the RPL-aware nodes should support 2310 both values . The migration procedure it is triggered when the DIO 2311 is sent with the flag indicating the new RPI Option Type. Namely, it 2312 remains at 0x63 until it is sure that the network is capable of 0x23, 2313 then it abruptly change to 0x23. This options allows to send packets 2314 to not-RPL nodes, which should ignore the option and continue 2315 processing the packets. 2317 As mentioned previously, indicating the new RPI in the DODAG 2318 Configuration option flag is a way to avoid the flag day (lack of 2319 interoperation) in a network using 0x63 as the RPI Option Type value. 2320 It is suggested that RPL implementations accept both 0x63 and 0x23 2321 RPI Option type values when processing the header to enable 2322 interoperability. 2324 11. IANA Considerations 2326 This document updates the registration made in [RFC6553] Destination 2327 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2328 Figure 38. 2330 +-------+-------------------+------------------------+---------- -+ 2331 | Hex | Binary Value | Description | Reference | 2332 + Value +-------------------+ + + 2333 | | act | chg | rest | | | 2334 +-------+-----+-----+-------+------------------------+------------+ 2335 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2336 +-------+-----+-----+-------+------------------------+------------+ 2337 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2338 | | | | | |[RFCXXXX](*)| 2339 +-------+-----+-----+-------+------------------------+------------+ 2341 Figure 38: Option Type in RPL Option.(*)represents this document 2343 DODAG Configuration option is updated as follows (Figure 39): 2345 +------------+-----------------+---------------+ 2346 | Bit number | Description | Reference | 2347 +------------+-----------------+---------------+ 2348 | 3 | RPI 0x23 enable | This document | 2349 +------------+-----------------+---------------+ 2351 Figure 39: DODAG Configuration option Flag to indicate the RPI-flag- 2352 day. 2354 12. Security Considerations 2356 The security considerations covered in [RFC6553] and [RFC6554] apply 2357 when the packets are in the RPL Domain. 2359 The IPv6-in-IPv6 mechanism described in this document is much more 2360 limited than the general mechanism described in [RFC2473]. The 2361 willingness of each node in the LLN to decapsulate packets and 2362 forward them could be exploited by nodes to disguise the origin of an 2363 attack. 2365 While a typical LLN may be a very poor origin for attack traffic (as 2366 the networks tend to be very slow, and the nodes often have very low 2367 duty cycles), given enough nodes, LLNs could still have a significant 2368 impact, particularly if attack is targeting another LLN. 2369 Additionally, some uses of RPL involve large backbone ISP scale 2370 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2371 equipped with multiple 100Gb/s interfaces. 2373 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2374 LLN as described above will make sure that any attack that is mounted 2375 must originate from compromised nodes within the LLN. The use of 2376 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2377 alert the operator to the existence of the attack, as well as drop 2378 the attack traffic. As the RPL network is typically numbered from a 2379 single prefix, which is itself assigned by RPL, BCP38 filtering 2380 involves a single prefix comparison and should be trivial to 2381 automatically configure. 2383 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2384 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2385 communications between a new Pledge and the Join Registrar/ 2386 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2387 and [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. This is the case 2388 for the RPL root to do careful filtering: it occurs only when the 2389 Join Coordinator is not co-located inside the RPL root. 2391 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2392 only be by a node within the LLN on another node within the LLN. 2393 Such an attack could, of course, be done directly. An attack of this 2394 kind is meaningful only if the source addresses are either fake or if 2395 the point is to amplify return traffic. Such an attack, could also 2396 be done without the use of IPv6-in-IPv6 headers using forged source 2397 addresses. If the attack requires bi-directional communication, then 2398 IPv6-in-IPv6 provides no advantages. 2400 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2401 about creating security issues. In the Security Considerations 2402 section of [RFC2473], it was suggested that tunnel entry and exit 2403 points can be secured by securing the IPv6 path between them. This 2404 recommendation is not practical for RPL networks. [RFC5406] goes 2405 into some detail on what additional details would be needed in order 2406 to "Use IPsec". Use of ESP would prevent [RFC8138] compression 2407 (compression must occur before encryption), and [RFC8138] compression 2408 is lossy in a way that prevents use of AH. These are minor issues. 2409 The major issue is how to establish trust enough such that IKEv2 2410 could be used. This would require a system of certificates to be 2411 present in every single node, including any Internet nodes that might 2412 need to communicate with the LLN. Thus, using IPsec requires a 2413 global PKI in the general case. 2415 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2416 IPv6 headers would in the general case scale with the square of the 2417 number of nodes. This is a lot of resource for a constrained nodes 2418 on a constrained network. In the end, the IPsec tunnels would be 2419 providing only BCP38-like origin authentication! That is, IPsec 2420 provides a transitive guarantee to the tunnel exit point that the 2421 tunnel entry point did BCP38 on traffic going in. Just doing origin 2422 filtering per BCP 38 at the entry and exit of the LLN provides a 2423 similar level of security without all the scaling and trust problems 2424 related to IPv6 tunnels as discussed in RFC 2473. IPsec is not 2425 recommended. 2427 An LLN with hostile nodes within it would not be protected against 2428 impersonation with the LLN by entry/exit filtering. 2430 The RH3 header usage described here can be abused in equivalent ways 2431 (to disguise the origin of traffic and attack other nodes) with an 2432 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2433 attacker's RH3 header will not be seen by the network until it 2434 reaches the end host, which will decapsulate it. An end-host should 2435 be suspicious about an RH3 header which has additional hops which 2436 have not yet been processed, and SHOULD ignore such a second RH3 2437 header. 2439 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2440 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2441 will see the second RH3 header and MAY choose to discard the packet 2442 if the RH3 header has not been completely consumed. A consumed 2443 (inert) RH3 header could be present in a packet that flows from one 2444 LLN, crosses the Internet, and enters another LLN. As per the 2445 discussion in this document, such headers do not need to be removed. 2446 However, there is no case described in this document where an RH3 is 2447 inserted in a non-storing network on traffic that is leaving the LLN, 2448 but this document should not preclude such a future innovation. It 2449 should just be noted that an incoming RH3 must be fully consumed, or 2450 very carefully inspected. 2452 The RPI, if permitted to enter the LLN, could be used by an attacker 2453 to change the priority of a packet by selecting a different 2454 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2455 It could also be that not all nodes are reachable in an LLN using the 2456 default RPLInstanceID, but a change of RPLInstanceID would permit an 2457 attacker to bypass such filtering. Like the RH3, an RPI is to be 2458 inserted by the RPL root on traffic entering the LLN by first 2459 inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will 2460 not be seen by the network. Upon reaching the destination node the 2461 RPI has no further meaning and is just skipped; the presence of a 2462 second RPI will have no meaning to the end node as the packet has 2463 already been identified as being at it's final destination. 2465 The RH3 and RPIs could be abused by an attacker inside of the network 2466 to route packets on non-obvious ways, perhaps eluding observation. 2467 This usage appears consistent with a normal operation of [RFC6997] 2468 and can not be restricted at all. This is a feature, not a bug. 2470 [RFC7416] deals with many other threats to LLNs not directly related 2471 to the use of IPv6-in-IPv6 headers, and this document does not change 2472 that analysis. 2474 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2475 attack on another part of the LLN, while disguising the origin of the 2476 attack. The mechanism can even be abused to make it appear that the 2477 attack is coming from outside the LLN, and unless countered, this 2478 could be used to mount a Distributed Denial Of Service attack upon 2479 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2480 such attacks already seen in the real world. 2482 If an attack comes from inside of LLN, it can be alleviated with SAVI 2483 (Source Address Validation Improvement) using [RFC8505] with 2484 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2485 traffic with an address that is not registered, and the registration 2486 process checks for topological correctness. Notice that there is an 2487 L2 authentication in most of the cases. If an attack comes from 2488 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2489 but by construction, the RH3 can typically only address nodes within 2490 the LLN. That is, an RH3 with a CmprI less than 8 , should be 2491 considered an attack (see RFC6554, section 3). 2493 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2494 through the RPL root to perform this attack. To counter, the RPL 2495 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2496 simpler solution), or it SHOULD walk the IP header extension chain 2497 until it can inspect the upper-layer-payload as described in 2498 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2499 on the source addresses of all IP headers that it examines in both 2500 directions. 2502 Note: there are some situations where a prefix will spread across 2503 multiple LLNs via mechanisms such as the one described in 2504 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2505 needs to take this into account, either by exchanging detailed 2506 routing information on each LLN, or by moving the BCP38 filtering 2507 further towards the Internet, so that the details of the multiple 2508 LLNs do not matter. 2510 13. Acknowledgments 2512 This work is done thanks to the grant given by the StandICT.eu 2513 project. 2515 A special BIG thanks to C. M. Heard for the help with the 2516 Section 4. Much of the redaction in that section is based on his 2517 comments. 2519 Additionally, the authors would like to acknowledge the review, 2520 feedback, and comments of (alphabetical order): Dominique Barthel, 2521 Robert Cragie, Simon Duquennoy, Ralph Droms, Cenk Guendogan, Rahul 2522 Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Mercado, 2523 Subramanian Moonesamy, Marcela Orbiscay, Charlie Perkins, Cristian 2524 Perez, Alvaro Retana, Peter van der Stok, Xavier Vilajosana, Eric 2525 Vyncke and Thomas Watteyne. 2527 14. References 2529 14.1. Normative References 2531 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2532 Defeating Denial of Service Attacks which employ IP Source 2533 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2534 May 2000, . 2536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2537 Requirement Levels", BCP 14, RFC 2119, 2538 DOI 10.17487/RFC2119, March 1997, 2539 . 2541 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2542 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2543 2010, . 2545 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2546 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2547 DOI 10.17487/RFC6282, September 2011, 2548 . 2550 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2551 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2552 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2553 Low-Power and Lossy Networks", RFC 6550, 2554 DOI 10.17487/RFC6550, March 2012, 2555 . 2557 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2558 Power and Lossy Networks (RPL) Option for Carrying RPL 2559 Information in Data-Plane Datagrams", RFC 6553, 2560 DOI 10.17487/RFC6553, March 2012, 2561 . 2563 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2564 Routing Header for Source Routes with the Routing Protocol 2565 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2566 DOI 10.17487/RFC6554, March 2012, 2567 . 2569 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2570 of IPv6 Extension Headers", RFC 7045, 2571 DOI 10.17487/RFC7045, December 2013, 2572 . 2574 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2575 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2576 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2577 . 2579 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2580 "IPv6 over Low-Power Wireless Personal Area Network 2581 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2582 April 2017, . 2584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2586 May 2017, . 2588 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2589 (IPv6) Specification", STD 86, RFC 8200, 2590 DOI 10.17487/RFC8200, July 2017, 2591 . 2593 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2594 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2595 January 2019, . 2597 14.2. Informative References 2599 [DDOS-KREBS] 2600 Goodin, D., "Record-breaking DDoS reportedly delivered by 2601 >145k hacked cameras", September 2016, 2602 . 2605 [I-D.ietf-6lo-ap-nd] 2606 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2607 "Address Protected Neighbor Discovery for Low-power and 2608 Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in 2609 progress), April 2020. 2611 [I-D.ietf-6lo-backbone-router] 2612 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2613 Backbone Router", draft-ietf-6lo-backbone-router-20 (work 2614 in progress), March 2020. 2616 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2617 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2618 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 2619 progress), July 2019. 2621 [I-D.ietf-anima-autonomic-control-plane] 2622 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2623 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2624 plane-24 (work in progress), March 2020. 2626 [I-D.ietf-anima-bootstrapping-keyinfra] 2627 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2628 and K. Watsen, "Bootstrapping Remote Secure Key 2629 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2630 keyinfra-41 (work in progress), April 2020. 2632 [I-D.ietf-intarea-tunnels] 2633 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2634 Architecture", draft-ietf-intarea-tunnels-10 (work in 2635 progress), September 2019. 2637 [I-D.ietf-roll-unaware-leaves] 2638 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 2639 draft-ietf-roll-unaware-leaves-15 (work in progress), 2640 April 2020. 2642 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2643 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2644 December 1998, . 2646 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2647 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2648 December 1998, . 2650 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2651 Control Message Protocol (ICMPv6) for the Internet 2652 Protocol Version 6 (IPv6) Specification", STD 89, 2653 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2654 . 2656 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2657 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2658 February 2009, . 2660 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2661 "IPv6 Flow Label Specification", RFC 6437, 2662 DOI 10.17487/RFC6437, November 2011, 2663 . 2665 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2666 Bormann, "Neighbor Discovery Optimization for IPv6 over 2667 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2668 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2669 . 2671 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2672 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2673 in Low-Power and Lossy Networks", RFC 6997, 2674 DOI 10.17487/RFC6997, August 2013, 2675 . 2677 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2678 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2679 2014, . 2681 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2682 and M. Richardson, Ed., "A Security Threat Analysis for 2683 the Routing Protocol for Low-Power and Lossy Networks 2684 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2685 . 2687 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2688 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2689 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2690 May 2017, . 2692 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2693 Perkins, "Registration Extensions for IPv6 over Low-Power 2694 Wireless Personal Area Network (6LoWPAN) Neighbor 2695 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2696 . 2698 Authors' Addresses 2700 Maria Ines Robles 2701 Universidad Tecno. Nac.(UTN)-FRM, Argentina / Aalto University, Finland 2703 Email: mariainesrobles@gmail.com 2704 Michael C. Richardson 2705 Sandelman Software Works 2706 470 Dawson Avenue 2707 Ottawa, ON K1Z 5V7 2708 CA 2710 Email: mcr+ietf@sandelman.ca 2711 URI: http://www.sandelman.ca/mcr/ 2713 Pascal Thubert 2714 Cisco Systems, Inc 2715 Building D 2716 45 Allee des Ormes - BP1200 2717 MOUGINS - Sophia Antipolis 06254 2718 FRANCE 2720 Phone: +33 497 23 26 34 2721 Email: pthubert@cisco.com