idnits 2.17.1 draft-ietf-roll-useofrplinfo-42.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2020) is 1255 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-23 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 3 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: May 16, 2021 P. Thubert 7 Cisco 8 November 12, 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-42 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 May 16, 2021. 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 RFC6550, RFC6553 and RFC8138 . . . . . . . . . . . 7 67 4.1. Updates to RFC6550 . . . . . . . . . . . . . . . . . . . 7 68 4.1.1. Advertising External Routes with Non-Storing Mode 69 Signaling. . . . . . . . . . . . . . . . . . . . . . 7 70 4.1.2. Configuration Options and Mode 71 of Operation . . . . . . . . . . . . . . . . . . . . 8 72 4.1.3. Indicating the new RPI in the 73 DODAG Configuration option Flag. . . . . . . . . . . 9 74 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 10 75 4.3. Updates to RFC8138: Indicating the way to decompress with 76 the new RPI Option Type. . . . . . . . . . . . . . . . . 13 77 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14 78 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19 80 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20 81 7.1.1. SM: Example of Flow from RAL to Root . . . . . . . . 21 82 7.1.2. SM: Example of Flow from Root to RAL . . . . . . . . 22 83 7.1.3. SM: Example of Flow from Root to RUL . . . . . . . . 22 84 7.1.4. SM: Example of Flow from RUL to Root . . . . . . . . 24 85 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 25 86 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 25 87 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 27 88 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 28 89 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 29 90 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 30 91 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 30 92 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 31 93 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 33 94 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 34 95 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 35 96 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 37 97 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 37 98 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 38 99 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 39 100 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 40 101 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 41 102 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 41 103 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 43 104 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 44 105 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 45 106 8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 46 107 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 46 108 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 49 109 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 51 110 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 52 111 9. Operational Considerations of supporting 112 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 53 113 10. Operational considerations of introducing 0x23 . . . . . . . 54 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 115 11.1. Option Type in RPL Option . . . . . . . . . . . . . . . 54 116 11.2. Change to the DODAG Configuration Options Flags registry 55 117 11.3. Change MOP value 7 to Reserved . . . . . . . . . . . . . 55 118 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 119 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 121 14.1. Normative References . . . . . . . . . . . . . . . . . . 59 122 14.2. Informative References . . . . . . . . . . . . . . . . . 61 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 125 1. Introduction 127 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 128 [RFC6550] is a routing protocol for constrained networks. [RFC6553] 129 defines the RPL Option carried within the IPv6 Hop-by-Hop Header to 130 carry the RPLInstanceID and quickly identify inconsistencies (loops) 131 in the routing topology. The RPL Option is commonly referred to as 132 the RPL Packet Information (RPI) though the RPI is really the 133 abstract information that is defined in [RFC6550] and transported in 134 the RPL Option. RFC6554 [RFC6554] defines the "RPL Source Route 135 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 136 RPL routing domain, particularly in non-storing mode. 138 These various items are referred to as RPL artifacts, and they are 139 seen on all of the data-plane traffic that occurs in RPL routed 140 networks; they do not in general appear on the RPL control plane 141 traffic at all which is mostly Hop-by-Hop traffic (one exception 142 being DAO messages in non-storing mode). 144 It has become clear from attempts to do multi-vendor 145 interoperability, and from a desire to compress as many of the above 146 artifacts as possible that not all implementers agree when artifacts 147 are necessary, or when they can be safely omitted, or removed. 149 The ROLL WG analyzed how [RFC2460] rules apply to storing and non- 150 storing use of RPL. The result was 24 data plane use cases. They 151 are exhaustively outlined here in order to be completely unambiguous. 152 During the processing of this document, new rules were published as 153 [RFC8200], and this document was updated to reflect the normative 154 changes in that document. 156 This document updates [RFC6553], changing the value of the Option 157 Type of the RPL Option to make [RFC8200] routers ignore this option 158 when not recognized. 160 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 161 mechanism for compressing RPL Option information and Routing Header 162 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 163 technique. 165 Most of the use cases described therein require the use of IPv6-in- 166 IPv6 packet encapsulation. When encapsulating and decapsulating 167 packets, RFC 6040 [RFC6040] MUST be applied to map the setting of the 168 explicit congestion notification (ECN) field between inner and outer 169 headers. Additionally, it is recommended the reading of 170 [I-D.ietf-intarea-tunnels] that explains the relationship of IP 171 tunnels to existing protocol layers and the challenges in supporting 172 IP tunneling. 174 Non-constrained uses of RPL are not in scope of this document, and 175 applicability statements for those uses may provide different advice, 176 E.g. [I-D.ietf-anima-autonomic-control-plane]. 178 1.1. Overview 180 The rest of the document is organized as follows: Section 2 describes 181 the used terminology. Section 3 provides a RPL Overview. Section 4 182 describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5 183 provides the reference topology used for the uses cases. Section 6 184 describes the uses cases included. Section 7 describes the storing 185 mode cases and section 8 the non-storing mode cases. Section 9 186 describes the operational considerations of supporting RPL-unaware- 187 leaves. Section 10 depicts operational considerations for the 188 proposed change on RPI Option Type, section 11 the IANA 189 considerations and then section 12 describes the security aspects. 191 2. Terminology and Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 Terminology defined in [RFC7102] applies to this document: LLN, RPL, 200 RPL domain and ROLL. 202 RPL Leaf: An IPv6 host that is attached to a RPL router and obtains 203 connectivity through a RPL Destination Oriented Directed Acyclic 204 Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a 205 consumed Routing Header and as an IPv6 host, it is expected to ignore 206 a Hop-by-Hop header. It results that a RPL Leaf can correctly 207 receive a packet with RPL artifacts. On the other hand, a RPL Leaf 208 is not expected to generate RPL artifacts or to support IP-in-IP 209 encapsulation. For simplification, this document uses the standalone 210 term leaf to mean a RPL leaf. 212 RPL Packet Information (RPI): The abstract information that [RFC6550] 213 places in IP packets. The term is commonly used, including in this 214 document, to refer to the RPL Option [RFC6553] that transports that 215 abstract information in an IPv6 Hop-by-Hop Header. 217 RPL-aware-node (RAN): A device which implements RPL. Please note 218 that the device can be found inside the LLN or outside LLN. 220 RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. 222 RPL-unaware-node: A device which does not implement RPL, thus the 223 device is not-RPL-aware. Please note that the device can be found 224 inside the LLN. 226 RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. 228 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any 229 host or router participating in a LoWPAN. This term is used when 230 referring to situations in which either a host or router can play the 231 role described.". In this document, a 6LN acts as a leaf. 233 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate 234 router in the LoWPAN that is able to send and receive Router 235 Advertisements (RAs) and Router Solicitations (RSs) as well as 236 forward and route IPv6 packets. 6LoWPAN routers are present only in 237 route-over topologies." 239 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 240 router located at the junction of separate 6LoWPAN networks or 241 between a 6LoWPAN network and another IP network. There may be one 242 or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the 243 responsible authority for IPv6 prefix propagation for the 6LoWPAN 244 network it is serving. An isolated LoWPAN also contains a 6LBR in 245 the network, which provides the prefix(es) for the isolated network." 247 Flag Day: In this document, refers to a transition that involves 248 having a network with different values of RPI Option Type. 250 Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- 251 aware-nodes send information to the root about their parents. Thus, 252 the root knows the topology. Because the root knows the topology, 253 the intermediate 6LRs do not maintain routing state and source 254 routing is needed. 256 Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes 257 (6LRs) maintain routing state (of the children) so that source 258 routing is not needed. 260 Note: Due to lack of space in some figures (tables) we refer to IPv6- 261 in-IPv6 as IP6-IP6. 263 3. RPL Overview 265 RPL defines the RPL Control messages (control plane), a new ICMPv6 266 [RFC4443] message with Type 155. DIS (DODAG Information 267 Solicitation), DIO (DODAG Information Object) and DAO (Destination 268 Advertisement Object) messages are all RPL Control messages but with 269 different Code values. A RPL Stack is shown in Figure 1. 271 +--------------+ 272 | Upper Layers | 273 | | 274 +--------------+ 275 | RPL | 276 | | 277 +--------------+ 278 | ICMPv6 | 279 | | 280 +--------------+ 281 | IPv6 | 282 | | 283 +--------------+ 284 | 6LoWPAN | 285 | | 286 +--------------+ 287 | PHY-MAC | 288 | | 289 +--------------+ 291 Figure 1: RPL Stack. 293 RPL supports two modes of Downward traffic: in storing mode (SM), it 294 is fully stateful; in non-storing mode (Non-SM), it is fully source 295 routed. A RPL Instance is either fully storing or fully non-storing, 296 i.e. a RPL Instance with a combination of storing and non-storing 297 nodes is not supported with the current specifications at the time of 298 writing this document. 300 4. Updates to RFC6550, RFC6553 and RFC8138 302 4.1. Updates to RFC6550 304 4.1.1. Advertising External Routes with Non-Storing Mode Signaling. 306 Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to 307 indicate that the 6LR that generates the DAO redistributes external 308 targets into the RPL network. An external Target is a Target that 309 has been learned through an alternate protocol, for instance a route 310 to a prefix that is outside the RPL domain but reachable via a 6LR. 311 Being outside of the RPL domain, a node that is reached via an 312 external target cannot be guaranteed to ignore the RPL artifacts and 313 cannot be expected to process the [RFC8138] compression correctly. 314 This means that the RPL artifacts should be contained in an IP-in-IP 315 encapsulation that is removed by the 6LR, and that any remaining 316 compression should be expanded by the 6LR before it forwards a packet 317 outside the RPL domain. 319 This specification updates [RFC6550] to RECOMMEND that external 320 targets are advertised using Non-Storing Mode DAO messaging even in a 321 Storing-Mode network. This way, external routes are not advertised 322 within the DODAG and all packets to an external target reach the Root 323 like normal Non-Storing Mode traffic. The Non-Storing Mode DAO 324 informs the Root of the address of the 6LR that injects the external 325 route, and the root uses IP-in-IP encapsulation to that 6LR, which 326 terminates the IP-in-IP tunnel and forwards the original packet 327 outside the RPL domain free of RPL artifacts. In the other 328 direction, for traffic coming from an external target into the LLN, 329 the parent (6LR) that injects the traffic always encapsulates to the 330 root. This whole operation is transparent to intermediate routers 331 that only see traffic between the 6LR and the Root, and only the Root 332 and the 6LRs that inject external routes in the network need to be 333 upgraded to add this function to the network. 335 A RUL is a special case of external target when the target is 336 actually a host and it is known to support a consumed Routing Header 337 and to ignore a Hop-by-Hop header as prescribed by [RFC8200]. The 338 target may have been learned through an external routing protocol or 339 may have been registered to the 6LR using [RFC8505]. 341 In order to enable IP-in-IP all the way to a 6LN, it is beneficial 342 that the 6LN supports decapsulating IP-in-IP, but that is not assumed 343 by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a 344 packet SHOULD terminate the tunnel at a parent 6LR unless it is aware 345 that the RUL supports IP-in-IP decapsulation. 347 A node that is reachable over an external route is not expected to 348 support [RFC8138]. Whether a decapsulation took place or not and 349 even when the 6LR is delivering the packet to a RUL, the 6LR that 350 injected an external route MUST uncompress the packet before 351 forwarding over that external route. 353 4.1.2. Configuration Options and Mode of Operation 355 Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as 356 containing a series of Flags in the first octet of the payload. 358 Anticipating future work to revise RPL relating to how the LLN and 359 DODAG are configured, this document renames the DODAG Configuration 360 Option Flags registry so that it applies to Mode of Operation (MOP) 361 values zero (0) to six (6) only, leaving the flags unassigned for MOP 362 value seven (7).The MOP is described in RFC6550 section 6.3.1. 364 In addition, this document reserves MOP value 7 for future expansion. 366 See Sections 11.2 and 11.3. 368 4.1.3. Indicating the new RPI in the DODAG Configuration option Flag. 370 In order to avoid a Flag Day caused by lack of interoperation between 371 new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this 372 section defines a flag in the DIO Configuration option, to indicate 373 when the new RPI Option Type can be safely used. This means, the 374 flag is going to indicate the value of Option Type that the network 375 will be using for the RPL Option. Thus, when a node joins to a 376 network will know which value to use. With this, RPL-capable nodes 377 know if it is safe to use 0x23 when creating a new RPL Option. A 378 node that forwards a packet with an RPI MUST NOT modify the Option 379 Type of the RPL Option. 381 This is done using a DODAG Configuration option flag which will 382 signal "RPI 0x23 enable" and propagate through the network. 383 Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) 384 in the DIO Base Object. The flag is defined only for MOP value 385 between 0 to 6. 387 For a MOP value of 7, a node MUST use the RPI 0x23 option. 389 As stated in [RFC6550] the DODAG Configuration option is present in 390 DIO messages. The DODAG Configuration option distributes 391 configuration information. It is generally static, and does not 392 change within the DODAG. This information is configured at the DODAG 393 root and distributed throughout the DODAG with the DODAG 394 Configuration option. Nodes other than the DODAG root do not modify 395 this information when propagating the DODAG Configuration option. 397 Currently, the DODAG Configuration option in [RFC6550] states: "the 398 unused bits MUST be initialize to zero by the sender and MUST be 399 ignored by the receiver". If the flag is received with a value zero 400 (which is the default), then new nodes will remain in RFC6553 401 Compatible Mode; originating traffic with the old-RPI Option Type 402 (0x63) value. If the flag is received with a value of 1, then the 403 value for the RPL Option MUST be set to 0x23. 405 Bit number three of the flag field in the DODAG Configuration option 406 is to be used as shown in Figure 2 (which is the same as Figure 39 in 407 Section 11 and is shown here for convenience): 409 +------------+-----------------+---------------+ 410 | Bit number | Description | Reference | 411 +------------+-----------------+---------------+ 412 | 3 | RPI 0x23 enable | This document | 413 +------------+-----------------+---------------+ 415 Figure 2: DODAG Configuration option Flag to indicate the RPI-flag- 416 day. 418 In the case of reboot, the node (6LN or 6LR) does not remember the 419 RPI Option Type (i.e., whether or not the flag is set), so the node 420 will not trigger DIO messages until a DIO message is received 421 indicating the RPI value to be used. The node will use the value 422 0x23 if the network supports this feature. 424 4.2. Updates to RFC6553: Indicating the new RPI Option Type. 426 This modification is required in order to be able to send, for 427 example, IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node 428 through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 429 encapsulation. 431 [RFC6553] (Section 6, Page 7) states as shown in Figure 3, that in 432 the Option Type field of the RPL Option, the two high order bits must 433 be set to '01' and the third bit is equal to '1'. The first two bits 434 indicate that the IPv6 node must discard the packet if it doesn't 435 recognize the Option Type, and the third bit indicates that the 436 Option Data may change in route. The remaining bits serve as the 437 Option Type. 439 +-------+-------------------+----------------+-----------+ 440 | Hex | Binary Value | Description | Reference | 441 + Value +-------------------+ + + 442 | | act | chg | rest | | | 443 +-------+-----+-----+-------+----------------+-----------+ 444 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 445 +-------+-----+-----+-------+----------------+-----------+ 447 Figure 3: Option Type in RPL Option. 449 This document illustrates that it is not always possible to know for 450 sure at the source that a packet will only travel within the RPL 451 domain or may leave it. 453 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 454 the outer IPv6 header chain could potentially impact core routers in 455 the internet. So at that time, it was decided to encapsulate any 456 packet with a RPL Option using IPv6-in-IPv6 in all cases where it was 457 unclear whether the packet would remain within the RPL domain. In 458 the exception case where a packet would still leak, the Option Type 459 would ensure that the first router in the Internet that does not 460 recognize the option would drop the packet and protect the rest of 461 the network. 463 Even with [RFC8138], where the IPv6-in-IPv6 header is compressed, 464 this approach yields extra bytes in a packet; this means consuming 465 more energy, more bandwidth, incurring higher chances of loss and 466 possibly causing a fragmentation at the 6LoWPAN level. This impacts 467 the daily operation of constrained devices for a case that generally 468 does not happen and would not heavily impact the core anyway. 470 While intention was and remains that the Hop-by-Hop header with a RPL 471 Option should be confined within the RPL domain, this specification 472 modifies this behavior in order to reduce the dependency on IPv6-in- 473 IPv6 and protect the constrained devices. Section 4 of [RFC8200] 474 clarifies the behaviour of routers in the Internet as follows: "it is 475 now expected that nodes along a packet's delivery path only examine 476 and process the Hop-by-Hop Options header if explicitly configured to 477 do so". 479 When unclear about the travel of a packet, it becomes preferable for 480 a source not to encapsulate, accepting the fact that the packet may 481 leave the RPL domain on its way to its destination. In that event, 482 the packet should reach its destination and should not be discarded 483 by the first node that does not recognize the RPL Option. But with 484 the current value of the Option Type, if a node in the Internet is 485 configured to process the Hop-by-Hop header, and if such node 486 encounters an option with the first two bits set to 01 and conforms 487 to [RFC8200], it will drop the packet. Host systems should do the 488 same, irrespective of the configuration. 490 Thus, this document updates the Option Type of the RPL Option 491 [RFC6553], abusively naming it RPI Option Type for simplicity, to 492 (Figure 4): the two high order bits MUST be set to '00' and the third 493 bit is equal to '1'. The first two bits indicate that the IPv6 node 494 MUST skip over this option and continue processing the header 495 ([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and 496 the third bit continues to be set to indicate that the Option Data 497 may change en route. The rightmost five bits remain at 0x3(00011). 498 This ensures that a packet that leaves the RPL domain of an LLN (or 499 that leaves the LLN entirely) will not be discarded when it contains 500 the RPL Option. 502 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 503 capable) receives a packet with a RPL Option, it should ignore the 504 Hop-by-Hop RPL Option (skip over this option and continue processing 505 the header). This is relevant, as it was mentioned previously, in 506 the case that there is a flow from RAL to Internet (see 507 Section 7.2.1). 509 This is a significant update to [RFC6553]. 511 +-------+-------------------+-------------+------------+ 512 | Hex | Binary Value | Description | Reference | 513 + Value +-------------------+ + + 514 | | act | chg | rest | | | 515 +-------+-----+-----+-------+-------------+------------+ 516 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 517 +-------+-----+-----+-------+-------------+------------+ 519 Figure 4: Revised Option Type in RPL Option. (*)represents this 520 document 522 Without the signaling described below, this change would otherwise 523 create a lack of interoperation (flag day) for existing networks 524 which are currently using 0x63 as the RPI Option Type value. A move 525 to 0x23 will not be understood by those networks. It is suggested 526 that RPL implementations accept both 0x63 and 0x23 when processing 527 the header. 529 When forwarding packets, implementations SHOULD use the same value of 530 RPI Type as was received. This is required because the RPI Option 531 Type does not change en route ([RFC8200] - Section 4.2). It allows 532 the network to be incrementally upgraded and allows the DODAG root to 533 know which parts of the network have been upgraded. 535 When originating new packets, implementations SHOULD have an option 536 to determine which value to originate with, this option is controlled 537 by the DIO option described below. 539 The change of RPI Option Type from 0x63 to 0x23, makes all [RFC8200] 540 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 541 therefore no longer a necessity to remove the artifacts when sending 542 traffic to the Internet. This change clarifies when to use IPv6-in- 543 IPv6 headers, and how to address them: The Hop-by-Hop Options header 544 containing the RPI MUST always be added when 6LRs originate packets 545 (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST always 546 be added when a 6LR finds that it needs to insert a Hop-by-Hop 547 Options header containing the RPL Option. The IPv6-in-IPv6 header is 548 to be addressed to the RPL root when on the way up, and to the end- 549 host when on the way down. 551 In the non-storing case, dealing with not-RPL aware leaf nodes is 552 much easier as the 6LBR (DODAG root) has complete knowledge about the 553 connectivity of all DODAG nodes, and all traffic flows through the 554 root node. 556 The 6LBR can recognize not-RPL aware leaf nodes because it will 557 receive a DAO about that node from the 6LR immediately above that 558 not-RPL aware node. 560 The non-storing mode case does not require the type change from 0x63 561 to 0x23, as the root can always create the right packet. The type 562 change does not adversely affect the non-storing case.(see 563 Section 4.1.3) 565 4.3. Updates to RFC8138: Indicating the way to decompress with the new 566 RPI Option Type. 568 This modification is required in order to be able to decompress the 569 RPL Option with the new Option Type of 0x23. 571 RPI-6LoRH header provides a compressed form for the RPL RPI; see 572 [RFC8138], Section 6. A node that is decompressing this header MUST 573 decompress using the RPI Option Type that is currently active: that 574 is, a choice between 0x23 (new) and 0x63 (old). The node will know 575 which to use based upon the presence of the flag in the DODAG 576 Configuration option defined in Section 4.1.3. E.g. If the network 577 is in 0x23 mode (by DIO option), then it should be decompressed to 578 0x23. 580 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 581 header. 583 There are potential significant advantages to having a single code 584 path that always processes IPv6-in-IPv6 headers with no conditional 585 branches. 587 In Storing Mode, the scenarios where the flow goes from RAL to RUL 588 and RUL to RUL include compression of the IPv6-in-IPv6 and RPI 589 headers. The use of the IPv6-in-IPv6 header is MANDATORY in this 590 case, and it SHOULD be compressed with [RFC8138] section 7. Figure 5 591 illustrates the case in Storing mode where the packet is received 592 from the Internet, then the root encapsulates the packet to insert 593 the RPI. In that example, the leaf is not known to support RFC 8138, 594 and the packet is encapsulated to the 6LR that is the parent and last 595 hop to the final destination. 597 +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... 598 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 599 |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 600 +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-... 601 <-4bytes-> <- RFC 6282 -> 602 No RPL artifact 604 Figure 5: RPI Inserted by the Root in Storing Mode 606 In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the 607 Root, so it is elided in the IP-in-IP 6LoRH. The destination is the 608 parent 6LR of the destination of the inner packet so it cannot be 609 elided. It is placed as the single entry in an SRH-6LoRH as the 610 first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In 611 that example, the type is 1 so the 6LR address is compressed to 2 612 bytes. It results that the total length of the SRH-6LoRH is 4 bytes. 613 Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 614 6LoRH is removed, all the router headers that precede it are also 615 removed. The Paging Dispatch [RFC8025] may also be removed if there 616 was no previous Page change to a Page other than 0 or 1, since the 617 LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and 618 in Page 1. The resulting packet to the destination is the inner 619 packet compressed with [RFC6282]. 621 5. Sample/reference topology 623 A RPL network in general is composed of a 6LBR, a Backbone Router 624 (6BBR), a 6LR and a 6LN as a leaf logically organized in a DODAG 625 structure. 627 Figure 6 shows the reference RPL Topology for this document. The 628 letters above the nodes are there so that they may be referenced in 629 subsequent sections. In the figure, 6LR represents a full router 630 node. The 6LN is a RPL aware router, or host (as a leaf). 631 Additionally, for simplification purposes, it is supposed that the 632 6LBR has direct access to Internet and is the root of the DODAG, thus 633 the 6BBR is not present in the figure. 635 The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no 636 children hosts. 638 The leaves marked as RUL (G and J) are devices that do not speak RPL 639 at all (not-RPL-aware), but use Router-Advertisements, 6LowPAN DAR/ 640 DAC and 6LoWPAN ND only to participate in the network [RFC8505]. In 641 the document these leaves (G and J) are also referred to as a RUL. 643 The 6LBR ("A") in the figure is the root of the Global DODAG. 645 +------------+ 646 | INTERNET ----------+ 647 | | | 648 +------------+ | 649 | 650 | 651 | 652 A | 653 +-------+ 654 |6LBR | 655 +-----------|(root) |-------+ 656 | +-------+ | 657 | | 658 | | 659 | | 660 | | 661 | B |C 662 +---|---+ +---|---+ 663 | 6LR | | 6LR | 664 +---------| |--+ +--- ---+ 665 | +-------+ | | +-------+ | 666 | | | | 667 | | | | 668 | | | | 669 | | | | 670 | D | E | | 671 +-|-----+ +---|---+ | | 672 | 6LR | | 6LR | | | 673 | | +------ | | | 674 +---|---+ | +---|---+ | | 675 | | | | | 676 | | +--+ | | 677 | | | | | 678 | | | | | 679 | | | I | J | 680 F | | G | H | | 681 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 682 | RAL | | RUL | | RAL | | RAL | | RUL | 683 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 684 +-------+ +-------+ +------+ +-------+ +-------+ 686 Figure 6: A reference RPL Topology. 688 6. Use cases 690 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 691 encapsulation are going to be analyzed for a number of representative 692 traffic flows. 694 The use cases describe the communication in the following cases: - 695 Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- 696 nodes with the Internet - Between RUL nodes within the LLN (e.g. see 697 Section 7.1.4) - Inside of the LLN when the final destination address 698 resides outside of the LLN (e.g. see Section 7.2.3). 700 The uses cases are as follows: 702 Interaction between Leaf and Root: 704 RAL to root 706 root to RAL 708 RUL to root 710 root to RUL 712 Interaction between Leaf and Internet: 714 RAL to Internet 716 Internet to RAL 718 RUL to Internet 720 Internet to RUL 722 Interaction between leaves: 724 RAL to RAL 726 RAL to RUL 728 RUL to RAL 730 RUL to RUL 732 This document is consistent with the rule that a Header cannot be 733 inserted or removed on the fly inside an IPv6 packet that is being 734 routed. This is a fundamental precept of the IPv6 architecture as 735 outlined in [RFC8200]. 737 As the rank information in the RPI artifact is changed at each hop, 738 it will typically be zero when it arrives at the DODAG root. The 739 DODAG root MUST force it to zero when passing the packet out to the 740 Internet. The Internet will therefore not see any SenderRank 741 information. 743 Despite being legal to leave the RPI artifact in place, an 744 intermediate router that needs to add an extension header (e.g. RH3 745 or RPL Option) MUST still encapsulate the packet in an (additional) 746 outer IP header. The new header is placed after this new outer IP 747 header. 749 A corollary is that an intermediate router can remove an RH3 or RPL 750 Option only if it is placed in an encapsulating IPv6 Header that is 751 addressed TO this intermediate router. When doing the above, the 752 whole encapsulating header must be removed. (A replacement may be 753 added). This sometimes can result in outer IP headers being 754 addressed to the next hop router using link-local address. 756 Both the RPL Option and the RH3 headers may be modified in very 757 specific ways by routers on the path of the packet without the need 758 to add and remove an encapsulating header. Both headers were 759 designed with this modification in mind, and both the RPL RH3 and the 760 RPL Option are marked mutable but recoverable: so an IPsec AH 761 security header can be applied across these headers, but it can not 762 secure the values which mutate. 764 The RPI MUST be present in every single RPL data packet. 766 Prior to [RFC8138], there was significant interest in creating an 767 exception to this rule and removing the RPI for downward flows in 768 non-storing mode. This exception covered a very small number of 769 cases, and caused significant interoperability challenges while 770 adding significant in the code and tests. The ability to compress 771 the RPI down to three bytes or less removes much of the pressure to 772 optimize this any further [I-D.ietf-anima-autonomic-control-plane]. 774 Throughout the following subsections, the examples are described in 775 more details in the first subsections, and more concisely in the 776 later ones. 778 The uses cases are delineated based on the following IPV6 and RPL 779 mandates: 781 The RPI has to be in every packet that traverses the LLN. 783 - Because of the above requirement, packets from the Internet have 784 to be encapsulated. 786 - A Header cannot be inserted or removed on the fly inside an IPv6 787 packet that is being routed. 789 - Extension headers may not be added or removed except by the 790 sender or the receiver. 792 - RPI and RH3 headers may be modified by routers on the path of 793 the packet without the need to add and remove an encapsulating 794 header. 796 - an RH3 or RPL Option can only be removed by an intermediate 797 router if it is placed in an encapsulating IPv6 Header, which is 798 addressed to the intermediate router. 800 - Non-storing mode requires downstream encapsulation by root for 801 RH3. 803 The uses cases are delineated based on the following assumptions: 805 This document assumes that the LLN is using the no-drop RPI Option 806 Type (0x23). 808 - Each IPv6 node (including Internet routers) obeys [RFC8200], so 809 that 0x23 RPI Option Type can be safely inserted. 811 - All 6LRs obey [RFC8200]. 813 - The RPI is ignored at the IPv6 dst node (RUL). 815 - In the uses cases, we assume that the RAL supports IP-in-IP 816 encapsulation. 818 - In the uses cases, we don't assume that the RUL supports IP-in- 819 IP encapsulation. 821 - For traffic leaving a RUL, if the RUL adds an opaque RPI then 822 the description of the RAL applies. The 6LR as a RPL border 823 router SHOULD rewrite the RPI to indicate the selected Instance 824 and set the flags. 826 - The description for RALs applies to RAN in general. 828 - Non-constrained uses of RPL are not in scope of this document. 830 - Compression is based on [RFC8138]. 832 - The flow label [RFC6437] is not needed in RPL. 834 7. Storing mode 836 In storing mode (SM) (fully stateful), the sender can determine if 837 the destination is inside the LLN by looking if the destination 838 address is matched by the DIO's Prefix Information Option (PIO) 839 option. 841 The following table (Figure 7) itemizes which headers are needed in 842 each of the following scenarios. It indicates whether an IPv6-in- 843 IPv6 header must be added and what destination it must be addressed 844 to: (1) the final destination (the RAL node that is the target 845 (tgt)), (2) the "root", or (3) the 6LR parent of a RUL. 847 In cases where no IPv6-in-IPv6 header is needed, the column states 848 "No", and the destination is N/A (Not Applicable). If the IPv6-in- 849 IPv6 header is needed, the column shows "must". 851 In all cases, the RPI is needed, since it identifies inconsistencies 852 (loops) in the routing topology. In general, the RH3 is not needed 853 because it is not used in storing mode. However, there is one 854 scenario (from the root to the RUL in SM) where the RH3 can be used 855 to point at the RUL (Figure 11). 857 The leaf can be a router 6LR or a host, both indicated as 6LN. The 858 root refers to the 6LBR (see Figure 6). 860 +---------------------+--------------+------------+----------------+ 861 | Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst| 862 +---------------------+--------------+------------+----------------+ 863 | | RAL to root | No | N/A | 864 + +--------------+------------+----------------+ 865 | Leaf - Root | root to RAL | No | N/A | 866 + +--------------+------------+----------------+ 867 | | root to RUL | must | 6LR | 868 + +--------------+------------+----------------+ 869 | | RUL to root | must | root | 870 +---------------------+--------------+------------+----------------+ 871 | | RAL to Int | may | root | 872 + +--------------+------------+----------------+ 873 | Leaf - Internet | Int to RAL | must | RAL (tgt) | 874 + +--------------+------------+----------------+ 875 | | RUL to Int | must | root | 876 + +--------------+------------+----------------+ 877 | | Int to RUL | must | 6LR | 878 +---------------------+--------------+------------+----------------+ 879 | | RAL to RAL | No | N/A | 880 | Leaf - Leaf +--------------+------------+----------------+ 881 | | RAL to RUL | No(up) | N/A | 882 | + +------------+----------------+ 883 | | | must(down) | 6LR | 884 | +--------------+------------+----------------+ 885 | | RUL to RAL | must(up) | root | 886 | | +------------+----------------+ 887 | | | must(down) | RAL | 888 | +--------------+------------+----------------+ 889 | | RUL to RUL | must(up) | root | 890 | | +------------+----------------+ 891 | | | must(down) | 6LR | 892 |---------------------+--------------+------------+----------------+ 894 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 896 7.1. Storing Mode: Interaction between Leaf and Root 898 In this section is described the communication flow in storing mode 899 (SM) between, 901 RAL to root 903 root to RAL 905 RUL to root 907 root to RUL 909 7.1.1. SM: Example of Flow from RAL to Root 911 In storing mode, RFC 6553 (RPI) is used to send RPL Information 912 instanceID and rank information. 914 In this case the flow comprises: 916 RAL (6LN) --> 6LR_i --> root(6LBR) 918 For example, a communication flow could be: Node F (6LN) --> Node D 919 (6LR_i) --> Node B (6LR_i)--> Node A root(6LBR) 921 The RAL (Node F) inserts the RPI, and sends the packet to 6LR (Node 922 D) which decrements the rank in the RPI and sends the packet up. 923 When the packet arrives at 6LBR (Node A), the RPI is removed and the 924 packet is processed. 926 No IPv6-in-IPv6 header is required. 928 The RPI can be removed by the 6LBR because the packet is addressed to 929 the 6LBR. The RAL must know that it is communicating with the 6LBR 930 to make use of this scenario. The RAL can know the address of the 931 6LBR because it knows the address of the root via the DODAGID in the 932 DIO messages. 934 The Figure 8 summarizes what headers are needed for this use case. 936 +-----------+-----+-------+------+ 937 | Header | RAL | 6LR_i | 6LBR | 938 | | src | | dst | 939 +-----------+-----+-------+------+ 940 | Added | RPI | -- | -- | 941 | headers | | | | 942 +-----------+-----+-------+------+ 943 | Modified | -- | RPI | -- | 944 | headers | | | | 945 +-----------+-----+-------+------+ 946 | Removed | -- | -- | RPI | 947 | headers | | | | 948 +-----------+-----+-------+------+ 949 | Untouched | -- | -- | -- | 950 | headers | | | | 951 +-----------+-----+-------+------+ 953 Figure 8: SM: Summary of the use of headers from RAL to root 955 7.1.2. SM: Example of Flow from Root to RAL 957 In this case the flow comprises: 959 root (6LBR) --> 6LR_i --> RAL (6LN) 961 For example, a communication flow could be: Node A root(6LBR) --> 962 Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN) 964 In this case the 6LBR inserts RPI and sends the packet down, the 6LR 965 is going to increment the rank in RPI (it examines the RPLInstanceID 966 to identify the right forwarding table), the packet is processed in 967 the RAL and the RPI removed. 969 No IPv6-in-IPv6 header is required. 971 The Figure 9 summarizes what headers are needed for this use case. 973 +-----------+------+-------+-----+ 974 | Header | 6LBR | 6LR_i | RAL | 975 | | src | | dst | 976 +-----------+------+-------+-----+ 977 | Added | RPI | -- | -- | 978 | headers | | | | 979 +-----------+------+-------+-----+ 980 | Modified | -- | RPI | -- | 981 | headers | | | | 982 +-----------+------+-------+-----+ 983 | Removed | -- | -- | RPI | 984 | headers | | | | 985 +-----------+------+-------+-----+ 986 | Untouched | -- | -- | -- | 987 | headers | | | | 988 +-----------+------+-------+-----+ 990 Figure 9: SM: Summary of the use of headers from root to RAL 992 7.1.3. SM: Example of Flow from Root to RUL 994 In this case the flow comprises: 996 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 998 For example, a communication flow could be: Node A (6LBR) --> Node B 999 (6LR_i) --> Node E (6LR_n) --> Node G (RUL) 1001 6LR_i (Node B) represents the intermediate routers from the source 1002 (6LBR) to the destination (RUL), 1 <= i <= n, where n is the total 1003 number of routers (6LR) that the packet goes through from the 6LBR 1004 (Node A) to the RUL (Node G). 1006 The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and 1007 prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR 1008 parent of the RUL (6LR_n). The 6LR parent of the RUL removes the 1009 header and sends the packet to the RUL. 1011 The Figure 10 summarizes what headers are needed for this use case. 1013 +-----------+---------+---------+---------+-----+ 1014 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1015 | | src | | | dst | 1016 +-----------+---------+---------+---------+-----+ 1017 | Added | IP6-IP6 | -- | -- | -- | 1018 | headers | RPI | | | | 1019 +-----------+---------+---------+---------+-----+ 1020 | Modified | -- | | -- | -- | 1021 | headers | | RPI | | | 1022 +-----------+---------+---------+---------+-----+ 1023 | Removed | -- | -- | IP6-IP6 | -- | 1024 | headers | | | RPI | | 1025 +-----------+---------+---------+---------+-----+ 1026 | Untouched | -- | IP6-IP6 | -- | -- | 1027 | headers | | | | | 1028 +-----------+---------+---------+---------+-----+ 1030 Figure 10: SM: Summary of the use of headers from root to RUL 1032 IP-in-IP encapsulation may be avoided for Root to RUL communication. 1033 In SM, it can be replaced by a loose RH3 header that indicates the 1034 RUL, in which case the packet is routed to the 6LR as a normal SM 1035 operation, then the 6LR forwards to the RUL based on the RH3, and the 1036 RUL ignores both the consumed RH3 and the RPI, as in Non-Storing 1037 Mode. 1039 The Figure 11 summarizes what headers are needed for this scenario. 1041 +-----------+----------+--------------+----------------+----------+ 1042 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1043 | | src | i=(1,..,n-1) | | dst | 1044 | | | | | | 1045 +-----------+----------+--------------+----------------+----------+ 1046 | Added | RPI, RH3 | -- | -- | -- | 1047 | headers | | | | | 1048 +-----------+----------+--------------+----------------+----------+ 1049 | Modified | -- | RPI | RPI | -- | 1050 | headers | | | RH3(consumed) | | 1051 +-----------+----------+--------------+----------------+----------+ 1052 | Removed | -- | -- | -- | -- | 1053 | headers | | | | | 1054 +-----------+----------+--------------+----------------+----------+ 1055 | Untouched | -- | RH3 | -- | RPI, RH3 | 1056 | headers | | | | (both | 1057 | | | | | ignored) | 1058 +-----------+----------+--------------+----------------+----------+ 1060 Figure 11: SM: Summary of the use of headers from root to RUL without 1061 encapsulation 1063 7.1.4. SM: Example of Flow from RUL to Root 1065 In this case the flow comprises: 1067 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) 1069 For example, a communication flow could be: Node G (RUL) --> Node E 1070 (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) 1072 6LR_i represents the intermediate routers from the source (RUL) to 1073 the destination (6LBR), 1 <= i <= n, where n is the total number of 1074 routers (6LR) that the packet goes through from the RUL to the 6LBR. 1076 When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the 1077 6LR_1 will encapsulate the packet in an IPv6-in-IPv6 header with an 1078 RPI. The IPv6-in-IPv6 header is addressed to the root (Node A). The 1079 root removes the header and processes the packet. 1081 The Figure 12 shows the table that summarizes what headers are needed 1082 for this use case where the IPv6-in-IPv6 header is addressed to the 1083 root (Node A). 1085 +-----------+------+--------------+----------------+-----------------+ 1086 | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | 1087 | | src | | | | 1088 | | node | | | | 1089 +-----------+------+--------------+----------------+-----------------+ 1090 | Added | -- | IP6-IP6 | | -- | 1091 | headers | | RPI | -- | | 1092 +-----------+------+--------------+----------------+-----------------+ 1093 | Modified | -- | -- | RPI | -- | 1094 | headers | | | | | 1095 +-----------+------+--------------+----------------+-----------------+ 1096 | Removed | -- | -- | --- | IP6-IP6 | 1097 | headers | | | | RPI | 1098 +-----------+------+--------------+----------------+-----------------+ 1099 | Untouched | -- | -- | IP6-IP6 | -- | 1100 | headers | | | | | 1101 +-----------+------+--------------+----------------+-----------------+ 1103 Figure 12: SM: Summary of the use of headers from RUL to root. 1105 7.2. SM: Interaction between Leaf and Internet. 1107 In this section is described the communication flow in storing mode 1108 (SM) between, 1110 RAL to Internet 1112 Internet to RAL 1114 RUL to Internet 1116 Internet to RUL 1118 7.2.1. SM: Example of Flow from RAL to Internet 1120 In this case the flow comprises: 1122 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 1124 For example, the communication flow could be: Node F (RAL) --> Node D 1125 (6LR_i)--> Node B (6LR_i)--> Node A root(6LBR) --> Internet 1127 6LR_i represents the intermediate routers from the source (RAL) to 1128 the root (6LBR), 1 <= i <= n, where n is the total number of routers 1129 (6LR) that the packet goes through from the RAL to the 6LBR. 1131 RPL information from RFC 6553 may go out to Internet as it will be 1132 ignored by nodes which have not been configured to be RPI aware. No 1133 IPv6-in-IPv6 header is required. 1135 On the other hand, the RAL may insert the RPI encapsulated in a IPv6- 1136 in-IPv6 header to the root. Thus, the root removes the RPI and send 1137 the packet to the Internet. 1139 Note: In this use case, it is used a node as a leaf, but this use 1140 case can be also applicable to any RPL-aware-node type (e.g. 6LR) 1142 The Figure 13 summarizes what headers are needed for this use case 1143 when there is no encapsulation. Note that the RPI is modified by 1144 6LBR to set the SenderRank to zero in case that it is not already 1145 zero. The Figure 14 summarizes what headers are needed when 1146 encapsulation to the root takes place. 1148 +-----------+-----+-------+------+-----------+ 1149 | Header | RAL | 6LR_i | 6LBR | Internet | 1150 | | src | | | dst | 1151 +-----------+-----+-------+------+-----------+ 1152 | Added | RPI | -- | -- | -- | 1153 | headers | | | | | 1154 +-----------+-----+-------+------+-----------+ 1155 | Modified | -- | RPI | RPI | -- | 1156 | headers | | | | | 1157 +-----------+-----+-------+------+-----------+ 1158 | Removed | -- | -- | -- | -- | 1159 | headers | | | | | 1160 +-----------+-----+-------+------+-----------+ 1161 | Untouched | -- | -- | -- | RPI | 1162 | headers | | | | (Ignored) | 1163 +-----------+-----+-------+------+-----------+ 1165 Figure 13: SM: Summary of the use of headers from RAL to Internet 1166 with no encapsulation 1168 +-----------+----------+--------------+--------------+--------------+ 1169 | Header | RAL | 6LR_i | 6LBR | Internet dst | 1170 | | src | | | | 1171 +-----------+----------+--------------+--------------+--------------+ 1172 | Added | IP6-IP6 | -- | -- | -- | 1173 | headers | RPI | | | | 1174 +-----------+----------+--------------+--------------+--------------+ 1175 | Modified | -- | RPI | -- | -- | 1176 | headers | | | | | 1177 +-----------+----------+--------------+--------------+--------------+ 1178 | Removed | -- | -- | IP6-IP6 | -- | 1179 | headers | | | RPI | | 1180 +-----------+----------+--------------+--------------+--------------+ 1181 | Untouched | -- | IP6-IP6 | -- | -- | 1182 | headers | | | | | 1183 +-----------+----------+--------------+--------------+--------------+ 1185 Figure 14: SM: Summary of the use of headers from RAL to Internet 1186 with encapsulation to the root (6LBR). 1188 7.2.2. SM: Example of Flow from Internet to RAL 1190 In this case the flow comprises: 1192 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 1194 For example, a communication flow could be: Internet --> Node A 1195 root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) 1197 When the packet arrives from Internet to 6LBR the RPI is added in a 1198 outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address 1199 set to the RAL) and sent to 6LR, which modifies the rank in the RPI. 1200 When the packet arrives at the RAL the RPI is removed and the packet 1201 processed. 1203 The Figure 15 shows the table that summarizes what headers are needed 1204 for this use case. 1206 +-----------+----------+--------------+--------------+--------------+ 1207 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1208 | | src | | | | 1209 +-----------+----------+--------------+--------------+--------------+ 1210 | Added | -- | IP6-IP6(RPI) | -- | -- | 1211 | headers | | | | | 1212 +-----------+----------+--------------+--------------+--------------+ 1213 | Modified | -- | -- | RPI | -- | 1214 | headers | | | | | 1215 +-----------+----------+--------------+--------------+--------------+ 1216 | Removed | -- | -- | -- | IP6-IP6(RPI) | 1217 | headers | | | | | 1218 +-----------+----------+--------------+--------------+--------------+ 1219 | Untouched | -- | -- | -- | -- | 1220 | headers | | | | | 1221 +-----------+----------+--------------+--------------+--------------+ 1223 Figure 15: SM: Summary of the use of headers from Internet to RAL. 1225 7.2.3. SM: Example of Flow from RUL to Internet 1227 In this case the flow comprises: 1229 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1231 For example, a communication flow could be: Node G (RUL)--> Node E 1232 (6LR_1)--> Node B (6lR_i) --> Node A root(6LBR) --> Internet 1234 The node 6LR_1 (i=1) will add an IPv6-in-IPv6(RPI) header addressed 1235 to the root such that the root can remove the RPI before passing 1236 upwards. In the intermediate 6LR, the rank in the RPI is modified. 1238 The originating node will ideally leave the IPv6 flow label as zero 1239 so that the packet can be better compressed through the LLN. The 1240 6LBR will set the flow label of the packet to a non-zero value when 1241 sending to the Internet, for details check [RFC6437]. 1243 The Figure 16 shows the table that summarizes what headers are needed 1244 for this use case. 1246 +---------+-------+------------+-------------+-------------+--------+ 1247 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1248 | | src | | [i=2,...,n] | | dst | 1249 | | node | | | | | 1250 | | (RUL) | | | | | 1251 +---------+-------+------------+-------------+-------------+--------+ 1252 | Added | -- |IP6-IP6(RPI)| -- | -- | -- | 1253 | headers | | | | | | 1254 +---------+-------+------------+-------------+-------------+--------+ 1255 | Modified| -- | -- | RPI | -- | -- | 1256 | headers | | | | | | 1257 +---------+-------+------------+-------------+-------------+--------+ 1258 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1259 | headers | | | | | | 1260 +---------+-------+------------+-------------+-------------+--------+ 1261 |Untouched| -- | -- | -- | -- | -- | 1262 | headers | | | | | | 1263 +---------+-------+------------+-------------+-------------+--------+ 1265 Figure 16: SM: Summary of the use of headers from RUL to Internet. 1267 7.2.4. SM: Example of Flow from Internet to RUL. 1269 In this case the flow comprises: 1271 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1273 For example, a communication flow could be: Internet --> Node A 1274 root(6LBR) --> Node B (6LR_i)--> Node E (6LR_n) --> Node G (RUL) 1276 The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The 1277 IPv6-in-IPv6 is addressed to the 6LR parent of the RUL. 1279 Further details about this are mentioned in 1280 [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN 1281 acting as a plain host and not being aware of RPL. 1283 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1284 zero in order to aid in compression [RFC8138][RFC6437]. 1286 The Figure 17 shows the table that summarizes what headers are needed 1287 for this use case. 1289 +---------+-------+------------+--------------+-------------+-------+ 1290 | Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL | 1291 | | net | |[i=1,..,n-1] | | dst | 1292 | | src | | | | | 1293 | | | | | | | 1294 +---------+-------+------------+--------------+-------------+-------+ 1295 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1296 | headers | | | | | | 1297 +---------+-------+------------+--------------+-------------+-------+ 1298 | Modified| -- | -- | RPI | -- | -- | 1299 | headers | | | | | | 1300 +---------+-------+------------+--------------+-------------+-------+ 1301 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1302 | headers | | | | | | 1303 +---------+-------+------------+--------------+-------------+-------+ 1304 |Untouched| -- | -- | -- | -- | -- | 1305 | headers | | | | | | 1306 +---------+-------+------------+--------------+-------------+-------+ 1308 Figure 17: SM: Summary of the use of headers from Internet to RUL. 1310 7.3. SM: Interaction between Leaf and Leaf 1312 In this section is described the communication flow in storing mode 1313 (SM) between, 1315 RAL to RAL 1317 RAL to RUL 1319 RUL to RAL 1321 RUL to RUL 1323 7.3.1. SM: Example of Flow from RAL to RAL 1325 In [RFC6550] RPL allows a simple one-hop optimization for both 1326 storing and non-storing networks. A node may send a packet destined 1327 to a one-hop neighbor directly to that node. See section 9 in 1328 [RFC6550]. 1330 When the nodes are not directly connected, then in storing mode, the 1331 flow comprises: 1333 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL 1334 dst (6LN) 1335 For example, a communication flow could be: Node F (RAL src)--> Node 1336 D (6LR_ia)--> Node B (6LR_x) --> Node E (6LR_id) --> Node H (RAL dst) 1338 6LR_ia (Node D) represents the intermediate routers from source to 1339 the common parent (6LR_x) (Node B), 1 <= ia <= n, where n is the 1340 total number of routers (6LR) that the packet goes through from RAL 1341 (Node F) to the common parent 6LR_x (Node B). 1343 6LR_id (Node E) represents the intermediate routers from the common 1344 parent (6LR_x) (Node B) to destination RAL (Node H), 1 <= id <= m, 1345 where m is the total number of routers (6LR) that the packet goes 1346 through from the common parent (6LR_x) to destination RAL (Node H). 1348 It is assumed that the two nodes are in the same RPL domain (that 1349 they share the same DODAG root). At the common parent (Node B), the 1350 direction flag ('O' flag) of the RPI is changed (from decreasing 1351 ranks to increasing ranks). 1353 While the 6LR nodes will update the RPI, no node needs to add or 1354 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1356 The Figure 18 summarizes what headers are needed for this use case. 1358 +-----------+-----+--------+---------+--------+-----+ 1359 | Header | RAL | 6LR_ia | 6LR_x | 6LR_id | RAL | 1360 | | src | | (common | | dst | 1361 | | | | parent) | | | 1362 +-----------+-----+--------+---------+--------+-----+ 1363 | Added | RPI | -- | -- | -- | -- | 1364 | headers | | | | | | 1365 +-----------+-----+--------+---------+--------+-----+ 1366 | Modified | -- | RPI | RPI | RPI | -- | 1367 | headers | | | | | | 1368 +-----------+-----+--------+---------+--------+-----+ 1369 | Removed | -- | -- | -- | -- | RPI | 1370 | headers | | | | | | 1371 +-----------+-----+--------+---------+--------+-----+ 1372 | Untouched | -- | -- | -- | -- | -- | 1373 | headers | | | | | | 1374 +-----------+-----+--------+---------+--------+-----+ 1376 Figure 18: SM: Summary of the Use of Headers from RAL to RAL 1378 7.3.2. SM: Example of Flow from RAL to RUL 1380 In this case the flow comprises: 1382 RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) --> 1383 6LR_id --> RUL (IPv6 dst node) 1385 For example, a communication flow could be: Node F (RAL)--> Node D 1386 --> Node B--> Node A -->Node B --> Node E --> Node G (RUL) 1388 6LR_ia represents the intermediate routers from source (RAL) to the 1389 common parent (the Root), 1 <= ia <= n, where n is the total number 1390 of routers (6LR) that the packet goes through from RAL to the Root. 1392 6LR_id (Node E) represents the intermediate routers from the Root 1393 (Node B) to destination RUL (Node G). In this case, 1 <= id <= m, 1394 where m is the total number of routers (6LR) that the packet goes 1395 through from the Root down to the destination RUL. 1397 In this case, the packet from the RAL goes to 6LBR because the route 1398 to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an 1399 RPI (RPI1) addressed to the root(6LBR). The root does not remove the 1400 RPI1 (the root cannot remove an RPI if there is no encapsulation). 1401 The root inserts an IPv6-IPv6 encapsulation with an RPI2 and sends it 1402 to the 6LR parent of the RUL, which removes the encapsulation and 1403 RPI2 before passing the packet to the RUL. 1405 The Figure 19 summarizes what headers are needed for this use case. 1407 +----------+-------+-------+---------+---------+---------+---------+ 1408 | Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 1409 | | src | | | | | dst | 1410 | | node | | | | | node | 1411 +----------+-------+-------+---------+---------+---------+---------+ 1412 | Added | | | IP6-IP6 | -- | -- | -- | 1413 | headers | RPI1 | -- | (RPI2) | | | | 1414 | | | | | | | | 1415 +----------+-------+-------+---------+---------+---------+---------+ 1416 | Modified | -- | | -- | | | -- | 1417 | headers | | RPI1 | | RPI2 | -- | | 1418 | | | | | | | | 1419 +----------+-------+-------+---------+---------+---------+---------+ 1420 | Removed | -- | -- | | -- | IP6-IP6 | -- | 1421 | headers | | | -- | | (RPI2) | | 1422 | | | | | | | | 1423 +----------+-------+-------+---------+---------+---------+---------+ 1424 |Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 1425 | headers | | | | | |(Ignored)| 1426 | | | | | | | | 1427 +----------+-------+-------+---------+---------+---------+---------+ 1429 Figure 19: SM: Summary of the Use of Headers from RAL to RUL 1431 7.3.3. SM: Example of Flow from RUL to RAL 1433 In this case the flow comprises: 1435 RUL (IPv6 src node) --> 6LR_ia --> 6LBR --> 6LR_id --> RAL dst (6LN) 1437 For example, a communication flow could be: Node G (RUL)--> Node E 1438 --> Node B --> Node A --> Node B --> Node D --> Node F (RAL) 1440 6LR_ia (Node E) represents the intermediate routers from source (RUL) 1441 (Node G) to the root (Node A). In this case, 1 <= ia <= n, where n 1442 is the total number of routers (6LR) that the packet goes through 1443 from source to the root. 1445 6LR_id represents the intermediate routers from the root (Node A) to 1446 destination RAL (Node F). In this case, 1 <= id <= m, where m is the 1447 total number of routers (6LR) that the packet goes through from the 1448 root to the destination RAL. 1450 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1451 inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to the 1452 root. The root removes the outer header including the RPI (RPI1) and 1453 inserts a new RPI (RPI2) addressed to the destination RAL (Node F). 1455 The Figure 20 shows the table that summarizes what headers are needed 1456 for this use case. 1458 +-----------+------+---------+---------+---------+---------+---------+ 1459 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 1460 | | src | | | | | dst | 1461 | | node | | | | | node | 1462 +-----------+------+---------+---------+---------+---------+---------+ 1463 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1464 | headers | | (RPI1) | | (RPI2) | | | 1465 | | | | | | | | 1466 +-----------+------+---------+---------+---------+---------+---------+ 1467 | Modified | -- | | | -- | | -- | 1468 | headers | | -- | RPI1 | | RPI2 | | 1469 | | | | | | | | 1470 +-----------+------+---------+---------+---------+---------+---------+ 1471 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1472 | headers | | -- | | (RPI1) | | (RPI2) | 1473 | | | | | | | | 1474 +-----------+------+---------+---------+---------+---------+---------+ 1475 | Untouched | -- | -- | -- | -- | -- | -- | 1476 | headers | | | | | | | 1477 +-----------+------+---------+---------+---------+---------+---------+ 1479 Figure 20: SM: Summary of the use of headers from RUL to RAL. 1481 7.3.4. SM: Example of Flow from RUL to RUL 1483 In this case the flow comprises: 1485 RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> RUL 1486 (IPv6 dst node) 1488 For example, a communication flow could be: Node G (RUL src)--> Node 1489 E --> Node B --> Node A (root) --> Node C --> Node J (RUL dst) 1491 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1492 router from the RUL source (Node G) to the root (6LBR) (Node A). In 1493 this case, 1 <= ia <= n, where n is the total number of routers (6LR) 1494 that the packet goes through from the RUL to the root. 6LR_1 refers 1495 when ia=1. 1497 6LR_id (Node C) represents the intermediate routers from the root 1498 (Node A) to the destination RUL dst node (Node J). In this case, 1 1499 <= id <= m, where m is the total number of routers (6LR) that the 1500 packet goes through from the root to destination RUL. 1502 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1503 inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header 1504 directed to the root. The root removes the outer header including 1505 the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR 1506 father of the RUL. 1508 The Figure 21 shows the table that summarizes what headers are needed 1509 for this use case. 1511 +---------+----+-------------+--------+---------+--------+-------+---+ 1512 | Header |RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id |6LR_n |RUL| 1513 | |src | | | | | |dst| 1514 | | | | | | | | | 1515 +---------+----+-------------+--------+---------+--------+-------+---+ 1516 | Added | -- |IP6-IP6(RPI1)| -- | IP6-IP6 | -- | -- | --| 1517 | Headers | | | | (RPI2) | | | | 1518 +---------+----+-------------+--------+---------+--------+-------+---+ 1519 |Modified | -- | -- | | -- | | -- | --| 1520 |headers | | | RPI1 | | RPI2 | | | 1521 +---------+----+-------------+--------+---------+--------+-------+---+ 1522 | Removed | -- | -- | -- | IP6-IP6 | -- |IP6-IP6| --| 1523 | headers | | | | (RPI1) | | (RPI2)| | 1524 +---------+----+-------------+--------+---------+--------+-------+---+ 1525 |Untouched| -- | -- | -- | -- | -- | -- | --| 1526 | headers | | | | | | | | 1527 +---------+----+-------------+--------+---------+--------+-------+---+ 1529 Figure 21: SM: Summary of the use of headers from RUL to RUL 1531 8. Non Storing mode 1533 In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG 1534 root) has complete knowledge about the connectivity of all DODAG 1535 nodes, and all traffic flows through the root node. Thus, there is 1536 no need for all nodes to know about the existence of RPL-unaware 1537 nodes. Only the 6LBR needs to act if compensation is necessary for 1538 not-RPL aware receivers. 1540 The table (Figure 22) summarizes what headers are needed in the 1541 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 1542 header are to be inserted. The last column depicts the target 1543 destination of the IPv6-in-IPv6 header: 6LN (indicated by "RAL"), 6LR 1544 (parent of a RUL) or the root. In cases where no IPv6-in-IPv6 header 1545 is needed, the column indicates "No". There is no expectation on RPL 1546 that RPI can be omitted, because it is needed for routing, quality of 1547 service and compression. This specification expects that an RPI is 1548 always present. The term "may(up)" means that the IPv6-in-IPv6 1549 header may be necessary in the upwards direction. The term 1550 "must(up)" means that the IPv6-in-IPv6 header must be present in the 1551 upwards direction. The term "must(down)" means that the IPv6-in-IPv6 1552 header must be present in the downward direction. 1554 The leaf can be a router 6LR or a host, both indicated as 6LN 1555 (Figure 6). In the table (Figure 22) the (1) indicates a 6tisch case 1556 [RFC8180], where the RPI may still be needed for the RPLInstanceID to 1557 be available for priority/channel selection at each hop. 1559 +--- ------------+-------------+-----+-----+--------------+----------+ 1560 | Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP | 1561 | between | | | | | dst | 1562 +----------------+-------------+-----+-----+--------------+----------+ 1563 | | RAL to root | Yes | No | No | No | 1564 | +-------------+-----+-----+--------------+----------+ 1565 | Leaf - Root | root to RAL | Yes | Yes | No | No | 1566 | +-------------+-----+-----+--------------+----------+ 1567 | | root to RUL | Yes | Yes | No | 6LR | 1568 | | | (1) | | | | 1569 | +-------------+-----+-----+--------------+----------+ 1570 | | RUL to root | Yes | No | must | root | 1571 +----------------+-------------+-----+-----+--------------+----------+ 1572 | | RAL to Int | Yes | No | may(up) | root | 1573 | +-------------+-----+-----+--------------+----------+ 1574 |Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | 1575 | +-------------+-----+-----+--------------+----------+ 1576 | | RUL to Int | Yes | No | must | root | 1577 | +-------------+-----+-----+--------------+----------+ 1578 | | Int to RUL | Yes | Yes | must | 6LR | 1579 +----------------+-------------+-----+-----+--------------+----------+ 1580 | | RAL to RAL | Yes | Yes | may(up) | root | 1581 | | | | +--------------+----------+ 1582 | | | | | must(down) | RAL | 1583 | Leaf - Leaf +-------------+-----+-----+--------------+----------+ 1584 | | RAL to RUL | Yes | Yes | may(up) | root | 1585 | | | | +--------------+----------+ 1586 | | | | | must(down) | 6LR | 1587 | +-------------+-----+-----+--------------+----------+ 1588 | | RUL to RAL | Yes | Yes | must(up) | root | 1589 | | | | +--------------+----------+ 1590 | | | | | must(down) | RAL | 1591 | +-------------+-----+-----+--------------+----------+ 1592 | | RUL to RUL | Yes | Yes | must(up) | root | 1593 | | | | +--------------+----------+ 1594 | | | | | must(down) | 6LR | 1595 +----------------+-------------+-----+-----+--------------+----------+ 1597 Figure 22: Table that shows headers needed in Non-Storing mode: RPI, 1598 RH3, IPv6-in-IPv6 encapsulation. 1600 8.1. Non-Storing Mode: Interaction between Leaf and Root 1602 In this section is described the communication flow in Non Storing 1603 Mode (Non-SM) between, 1605 RAL to root 1607 root to RAL 1609 RUL to root 1611 root to RUL 1613 8.1.1. Non-SM: Example of Flow from RAL to root 1615 In non-storing mode the leaf node uses default routing to send 1616 traffic to the root. The RPI must be included since it contains the 1617 rank information, which is used to avoid/detect loops. 1619 RAL (6LN) --> 6LR_i --> root(6LBR) 1621 For example, a communication flow could be: Node F --> Node D --> 1622 Node B --> Node A (root) 1624 6LR_i represents the intermediate routers from source to destination. 1625 In this case, 1 <= i <= n, where n is the total number of routers 1626 (6LR) that the packet goes through from source (RAL) to destination 1627 (6LBR). 1629 This situation is the same case as storing mode. 1631 The Figure 23 summarizes what headers are needed for this use case. 1633 +-----------+-----+-------+------+ 1634 | Header | RAL | 6LR_i | 6LBR | 1635 | | src | | dst | 1636 +-----------+-----+-------+------+ 1637 | Added | RPI | -- | -- | 1638 | headers | | | | 1639 +-----------+-----+-------+------+ 1640 | Modified | -- | RPI | -- | 1641 | headers | | | | 1642 +-----------+-----+-------+------+ 1643 | Removed | -- | -- | RPI | 1644 | headers | | | | 1645 +-----------+-----+-------+------+ 1646 | Untouched | -- | -- | -- | 1647 | headers | | | | 1648 +-----------+-----+-------+------+ 1650 Figure 23: Non-SM: Summary of the use of headers from RAL to root 1652 8.1.2. Non-SM: Example of Flow from root to RAL 1654 In this case the flow comprises: 1656 root (6LBR) --> 6LR_i --> RAL (6LN) 1658 For example, a communication flow could be: Node A (root) --> Node B 1659 --> Node D --> Node F 1661 6LR_i represents the intermediate routers from source to destination. 1662 In this case, 1 <= i <= n, where n is the total number of routers 1663 (6LR) that the packet goes through from source (6LBR) to destination 1664 (RAL). 1666 The 6LBR inserts an RH3, and an RPI. No IPv6-in-IPv6 header is 1667 necessary as the traffic originates with a RPL aware node, the 6LBR. 1668 The destination is known to be RPL-aware because the root knows the 1669 whole topology in non-storing mode. 1671 The Figure 24 summarizes what headers are needed for this use case. 1673 +-----------+----------+----------+----------+ 1674 | Header | 6LBR | 6LR_i | RAL | 1675 | | src | | dst | 1676 +-----------+----------+----------+----------+ 1677 | Added | RPI, RH3 | -- | -- | 1678 | headers | | | | 1679 +-----------+----------+----------+----------+ 1680 | Modified | -- | RPI, RH3 | -- | 1681 | headers | | | | 1682 +-----------+----------+----------+----------+ 1683 | Removed | -- | -- | RPI, RH3 | 1684 | headers | | | | 1685 +-----------+----------+----------+----------+ 1686 | Untouched | -- | -- | -- | 1687 | headers | | | | 1688 +-----------+----------+----------+----------+ 1690 Figure 24: Non-SM: Summary of the use of headers from root to RAL 1692 8.1.3. Non-SM: Example of Flow from root to RUL 1694 In this case the flow comprises: 1696 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1698 For example, a communication flow could be: Node A (root) --> Node B 1699 --> Node E --> Node G (RUL) 1701 6LR_i represents the intermediate routers from source to destination. 1702 In this case, 1 <= i <= n, where n is the total number of routers 1703 (6LR) that the packet goes through from source (6LBR) to destination 1704 (RUL). 1706 In the 6LBR, the RH3 is added; it is then modified at each 1707 intermediate 6LR (6LR_1 and so on), and it is fully consumed in the 1708 last 6LR (6LR_n) but is left in place. When the RPI is added, the 1709 RUL, which does not understand the RPI, will ignore it (per 1710 [RFC8200]); thus, encapsulation is not necessary. 1712 The Figure 25 depicts the table that summarizes what headers are 1713 needed for this use case. 1715 +-----------+----------+--------------+----------------+----------+ 1716 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1717 | | src | i=(1,..,n-1) | | dst | 1718 | | | | | | 1719 +-----------+----------+--------------+----------------+----------+ 1720 | Added | RPI, RH3 | -- | -- | -- | 1721 | headers | | | | | 1722 +-----------+----------+--------------+----------------+----------+ 1723 | Modified | -- | RPI, RH3 | RPI, | -- | 1724 | headers | | | RH3(consumed) | | 1725 +-----------+----------+--------------+----------------+----------+ 1726 | Removed | -- | -- | -- | -- | 1727 | headers | | | | | 1728 +-----------+----------+--------------+----------------+----------+ 1729 | Untouched | -- | -- | -- | RPI, RH3 | 1730 | headers | | | | (both | 1731 | | | | | ignored) | 1732 +-----------+----------+--------------+----------------+----------+ 1734 Figure 25: Non-SM: Summary of the use of headers from root to RUL 1736 8.1.4. Non-SM: Example of Flow from RUL to root 1738 In this case the flow comprises: 1740 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst 1742 For example, a communication flow could be: Node G --> Node E --> 1743 Node B --> Node A (root) 1745 6LR_i represents the intermediate routers from source to destination. 1746 In this case, 1 <= i <= n, where n is the total number of routers 1747 (6LR) that the packet goes through from source (RUL) to destination 1748 (6LBR). For example, 6LR_1 (i=1) is the router that receives the 1749 packets from the RUL. 1751 In this case, the RPI is added by the first 6LR (6LR_1) (Node E), 1752 encapsulated in an IPv6-in-IPv6 header, and modified in the 1753 subsequent 6LRs in the flow. The RPI and the entire packet are 1754 consumed by the root. 1756 The Figure 26 shows the table that summarizes what headers are needed 1757 for this use case. 1759 +---------+----+-----------------+-----------------+-----------------+ 1760 | |RUL | | | | 1761 | Header |src | 6LR_1 | 6LR_i | 6LBR dst | 1762 | |node| | | | 1763 +---------+----+-----------------+-----------------+-----------------+ 1764 | Added | -- |IPv6-in-IPv6(RPI)| -- | -- | 1765 | headers | | | | | 1766 +---------+----+-----------------+-----------------+-----------------+ 1767 | Modified| -- | -- | RPI | -- | 1768 | headers | | | | | 1769 +---------+----+-----------------+-----------------+-----------------+ 1770 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1771 | headers | | | | | 1772 +---------+----+-----------------+-----------------+-----------------+ 1773 |Untouched| -- | -- | -- | -- | 1774 | headers | | | | | 1775 +---------+----+-----------------+-----------------+-----------------+ 1777 Figure 26: Non-SM: Summary of the use of headers from RUL to root 1779 8.2. Non-Storing Mode: Interaction between Leaf and Internet 1781 This section will describe the communication flow in Non Storing Mode 1782 (Non-SM) between: 1784 RAL to Internet 1786 Internet to RAL 1788 RUL to Internet 1790 Internet to RUL 1792 8.2.1. Non-SM: Example of Flow from RAL to Internet 1794 In this case the flow comprises: 1796 RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst 1798 For example, a communication flow could be: Node F (RAL) --> Node D 1799 --> Node B --> Node A --> Internet. Having the RAL information about 1800 the RPL domain, the packet may be encapsulated to the root when the 1801 destination is not in the RPL domain of the RAL. 1803 6LR_i represents the intermediate routers from source to destination, 1804 1 <= i <= n, where n is the total number of routers (6LR) that the 1805 packet goes through from source (RAL) to 6LBR. 1807 In this case, the encapsulation from the RAL to the root is optional. 1808 The simplest case is when the RPI gets to the Internet (as the 1809 Figure 27 shows it), knowing that the Internet is going to ignore it. 1811 The IPv6 flow label should be set to zero to aid in compression 1812 [RFC8138], and the 6LBR will set it to a non-zero value when sending 1813 towards the Internet [RFC6437]. 1815 The Figure 27 summarizes what headers are needed for this use case 1816 when no encapsulation is used. The Figure 28 summarizes what headers 1817 are needed for this use case when encapsulation to the root is used. 1819 +-----------+-----+-------+------+-----------+ 1820 | Header | RAL | 6LR_i | 6LBR | Internet | 1821 | | src | | | dst | 1822 +-----------+-----+-------+------+-----------+ 1823 | Added | RPI | -- | -- | -- | 1824 | headers | | | | | 1825 +-----------+-----+-------+------+-----------+ 1826 | Modified | -- | RPI | RPI | -- | 1827 | headers | | | | | 1828 +-----------+-----+-------+------+-----------+ 1829 | Removed | -- | -- | -- | -- | 1830 | headers | | | | | 1831 +-----------+-----+-------+------+-----------+ 1832 | Untouched | -- | -- | -- | RPI | 1833 | headers | | | | (Ignored) | 1834 +-----------+-----+-------+------+-----------+ 1836 Figure 27: Non-SM: Summary of the use of headers from RAL to Internet 1837 with no encapsulation 1839 +-----------+--------------+--------------+--------------+----------+ 1840 | Header | RAL | 6LR_i | 6LBR | Internet | 1841 | | src | | | dst | 1842 +-----------+--------------+--------------+--------------+----------+ 1843 | Added | IPv6-in-IPv6 | -- | -- | -- | 1844 | headers | (RPI) | | | | 1845 +-----------+--------------+--------------+--------------+----------+ 1846 | Modified | -- | | -- | -- | 1847 | headers | | RPI | | | 1848 +-----------+--------------+--------------+--------------+----------+ 1849 | Removed | -- | -- | IPv6-in-IPv6 | -- | 1850 | headers | | | (RPI) | | 1851 +-----------+--------------+--------------+--------------+----------+ 1852 | Untouched | -- | -- | -- | -- | 1853 | headers | | | | | 1854 +-----------+--------------+--------------+--------------+----------+ 1856 Figure 28: Non-SM: Summary of the use of headers from RAL to Internet 1857 with encapsulation to the root 1859 8.2.2. Non-SM: Example of Flow from Internet to RAL 1861 In this case the flow comprises: 1863 Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN) 1865 For example, a communication flow could be: Internet --> Node A 1866 (root) --> Node B --> Node D --> Node F (RAL) 1868 6LR_i represents the intermediate routers from source to destination, 1869 1 <= i <= n, where n is the total number of routers (6LR) that the 1870 packet goes through from 6LBR to destination (RAL). 1872 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1873 address of the target node, it can address the IPv6-in-IPv6 header to 1874 that node. The 6LBR will zero the flow label upon entry in order to 1875 aid compression [RFC8138]. 1877 The Figure 29 summarizes what headers are needed for this use case. 1879 +-----------+----------+--------------+--------------+--------------+ 1880 | Header | Internet | 6LBR | 6LR_i | RAL | 1881 | | src | | | dst | 1882 +-----------+----------+--------------+--------------+--------------+ 1883 | Added | -- | IPv6-in-IPv6 | -- | -- | 1884 | headers | | (RH3, RPI) | | | 1885 +-----------+----------+--------------+--------------+--------------+ 1886 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1887 | headers | | | (RH3, RPI) | | 1888 +-----------+----------+--------------+--------------+--------------+ 1889 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1890 | headers | | | | (RH3, RPI) | 1891 +-----------+----------+--------------+--------------+--------------+ 1892 | Untouched | -- | -- | -- | -- | 1893 | headers | | | | | 1894 +-----------+----------+--------------+--------------+--------------+ 1896 Figure 29: Non-SM: Summary of the use of headers from Internet to RAL 1898 8.2.3. Non-SM: Example of Flow from RUL to Internet 1900 In this case the flow comprises: 1902 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1903 dst 1905 For example, a communication flow could be: Node G --> Node E --> 1906 Node B --> Node A --> Internet 1908 6LR_i represents the intermediate routers from source to destination, 1909 1 <= i <= n, where n is the total number of routers (6LRs) that the 1910 packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1 1911 (i=1). 1913 In this case the flow label is recommended to be zero in the RUL. As 1914 the RUL parent adds RPL headers in the RUL packet, the first 6LR 1915 (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6- 1916 in-IPv6 header will be addressed to the root. This case is identical 1917 to the storing-mode case (see Section 7.2.3). 1919 The Figure 30 shows the table that summarizes what headers are needed 1920 for this use case. 1922 +---------+----+-------------+--------------+--------------+--------+ 1923 | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| 1924 | |src | | [i=2,..,n] | | dst | 1925 | |node| | | | | 1926 +---------+----+-------------+--------------+--------------+--------+ 1927 | Added | -- |IP6-IP6(RPI) | -- | -- | -- | 1928 | headers | | | | | | 1929 +---------+----+-------------+--------------+--------------+--------+ 1930 | Modified| -- | -- | RPI | -- | -- | 1931 | headers | | | | | | 1932 +---------+----+-------------+--------------+--------------+--------+ 1933 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1934 | headers | | | | | | 1935 +---------+----+-------------+--------------+--------------+--------+ 1936 |Untouched| -- | -- | -- | -- | -- | 1937 | headers | | | | | | 1938 +---------+----+-------------+--------------+--------------+--------+ 1940 Figure 30: Non-SM: Summary of the use of headers from RUL to Internet 1942 8.2.4. Non-SM: Example of Flow from Internet to RUL 1944 In this case the flow comprises: 1946 Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1948 For example, a communication flow could be: Internet --> Node A 1949 (root) --> Node B --> Node E --> Node G 1951 6LR_i represents the intermediate routers from source to destination, 1952 1 <= i <= n, where n is the total number of routers (6LR) that the 1953 packet goes through from 6LBR to RUL. 1955 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1956 6LBR will know the path, and will recognize that the final node is 1957 not a RPL capable node as it will have received the connectivity DAO 1958 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1959 header destination be the last 6LR. The 6LBR will set to zero the 1960 flow label upon entry in order to aid compression [RFC8138]. 1962 The Figure 31 shows the table that summarizes what headers are needed 1963 for this use case. 1965 +----------+--------+------------------+-----------+-----------+-----+ 1966 | Header |Internet| 6LBR | 6LR_i | 6LR_n | RUL | 1967 | | src | | | | dst | 1968 +----------+--------+------------------+-----------+-----------+-----+ 1969 | Added | -- | IP6-IP6(RH3,RPI) | -- | -- | -- | 1970 | headers | | | | | | 1971 +----------+--------+------------------+-----------+-----------+-----+ 1972 | Modified | -- | -- | IP6-IP6 | -- | -- | 1973 | headers | | | (RH3,RPI) | | | 1974 +----------+--------+------------------+-----------+-----------+-----+ 1975 | Removed | -- | -- | -- | IP6-IP6 | -- | 1976 | headers | | | | (RH3,RPI) | | 1977 +----------+--------+------------------+-----------+-----------+-----+ 1978 |Untouched | -- | -- | -- | -- | -- | 1979 | headers | | | | | | 1980 +----------+--------+------------------+-----------+-----------+-----+ 1982 Figure 31: Non-SM: Summary of the use of headers from Internet to 1983 RUL. 1985 8.3. Non-SM: Interaction between leaves 1987 In this section is described the communication flow in Non Storing 1988 Mode (Non-SM) between, 1990 RAL to RAL 1992 RAL to RUL 1994 RUL to RAL 1996 RUL to RUL 1998 8.3.1. Non-SM: Example of Flow from RAL to RAL 2000 In this case the flow comprises: 2002 RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst 2004 For example, a communication flow could be: Node F (RAL src)--> Node 2005 D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL 2006 dst) 2008 6LR_ia represents the intermediate routers from source to the root, 1 2009 <= ia <= n, where n is the total number of routers (6LR) that the 2010 packet goes through from RAL to the root. 2012 6LR_id represents the intermediate routers from the root to the 2013 destination, 1 <= id <= m, where m is the total number of the 2014 intermediate routers (6LR). 2016 This case involves only nodes in same RPL domain. The originating 2017 node will add an RPI to the original packet, and send the packet 2018 upwards. 2020 The originating node may put the RPI (RPI1) into an IPv6-in-IPv6 2021 header addressed to the root, so that the 6LBR can remove that 2022 header. If it does not, then the RPI1 is forwarded down from the 2023 root in the inner header to no avail. 2025 The 6LBR will need to insert an RH3 header, which requires that it 2026 add an IPv6-in-IPv6 header. It removes the RPI(RPI1), as it was 2027 contained in an IPv6-in-IPv6 header addressed to it. Otherwise, 2028 there may be an RPI buried inside the inner IP header, which should 2029 get ignored. The root inserts an RPI (RPI2) alongside the RH3. 2031 Networks that use the RPL P2P extension [RFC6997] are essentially 2032 non-storing DODAGs and fall into this scenario or scenario 2033 Section 8.1.2, with the originating node acting as 6LBR. 2035 The Figure 32 shows the table that summarizes what headers are needed 2036 for this use case when encapsulation to the root takes place. 2038 The Figure 33 shows the table that summarizes what headers are needed 2039 for this use case when there is no encapsulation to the root. Note 2040 that in the Modified headers row, going up in each 6LR_ia only the 2041 RPI1 is changed. Going down, in each 6LR_id the IPv6 header is 2042 swapped with the RH3 so both are changed alongside with the RPI2. 2044 +---------+-------+----------+------------+----------+------------+ 2045 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 2046 | | src | | | | dst | 2047 +---------+-------+----------+------------+----------+------------+ 2048 | Added |IP6-IP6| | IP6-IP6 | -- | -- | 2049 | headers |(RPI1) | -- |(RH3-> RAL, | | | 2050 | | | | RPI2) | | | 2051 +---------+-------+----------+------------+----------+------------+ 2052 | Modified| -- | | -- | IP6-IP6 | -- | 2053 | headers | | RPI1 | |(RH3,RPI2)| | 2054 +---------+-------+----------+------------+----------+------------+ 2055 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | 2056 | headers | | | (RPI1) | | (RH3, | 2057 | | | | | | RPI2) | 2058 +---------+-------+----------+------------+----------+------------+ 2059 |Untouched| -- | -- | -- | -- | -- | 2060 | headers | | | | | | 2061 +---------+-------+----------+------------+----------+------------+ 2063 Figure 32: Non-SM: Summary of the Use of Headers from RAL to RAL with 2064 encapsulation to the root. 2066 +-----------+------+--------+---------+---------+---------+ 2067 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 2068 +-----------+------+--------+---------+---------+---------+ 2069 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | 2070 | headers | | | (RH3, | | | 2071 | | | | RPI2) | | | 2072 +-----------+------+--------+---------+---------+---------+ 2073 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | 2074 | headers | | | | (RH3, | | 2075 | | | | | RPI2) | | 2076 +-----------+------+--------+---------+---------+---------+ 2077 | Removed | -- | -- | -- | -- | IP6-IP6 | 2078 | headers | | | | | (RH3, | 2079 | | | | | | RPI2) | 2080 | | | | | | | 2081 +-----------+------+--------+---------+---------+---------+ 2082 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | 2083 | headers | | | | |(Ignored)| 2084 +-----------+------+--------+---------+---------+---------+ 2086 Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL 2087 without encapsulation to the root. 2089 8.3.2. Non-SM: Example of Flow from RAL to RUL 2091 In this case the flow comprises: 2093 RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node) 2095 For example, a communication flow could be: Node F (RAL) --> Node D 2096 --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL) 2098 6LR_ia represents the intermediate routers from source to the root, 1 2099 <= ia <= n, where n is the total number of intermediate routers (6LR) 2101 6LR_id represents the intermediate routers from the root to the 2102 destination, 1 <= id <= m, where m is the total number of the 2103 intermediate routers (6LRs). 2105 As in the previous case, the RAL (6LN) may insert an RPI (RPI1) 2106 header which must be in an IPv6-in-IPv6 header addressed to the root 2107 so that the 6LBR can remove this RPI. The 6LBR will then insert an 2108 RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id 2109 (6LR_id = m) alongside the insertion of RPI2. 2111 If the originating node does not put the RPI (RPI1) into an IPv6-in- 2112 IPv6 header addressed to the root. Then, the RPI1 is forwarded down 2113 from the root in the inner header to no avail. 2115 The Figure 34 shows the table that summarizes what headers are needed 2116 for this use case when encapsulation to the root takes place. The 2117 Figure 35 shows the table that summarizes what headers are needed for 2118 this use case when no encapsulation to the root takes place. 2120 +-----------+---------+---------+---------+---------+---------+------+ 2121 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 2122 | | src | | | | | dst | 2123 | | node | | | | | node | 2124 +-----------+---------+---------+---------+---------+---------+------+ 2125 | Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 2126 | headers | (RPI1) | -- | (RH3, | | | | 2127 | | | | RPI2) | | | | 2128 +-----------+---------+---------+---------+---------+---------+------+ 2129 | Modified | -- | | -- | IP6-IP6 | | -- | 2130 | headers | | RPI1 | | (RH3, | -- | | 2131 | | | | | RPI2) | | | 2132 +-----------+---------+---------+---------+---------+---------+------+ 2133 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2134 | headers | | | (RPI1) | | (RH3, | | 2135 | | | | | | RPI2) | | 2136 +-----------+---------+---------+---------+---------+---------+------+ 2137 | Untouched | -- | -- | -- | -- | -- | -- | 2138 | headers | | | | | | | 2139 +-----------+---------+---------+---------+---------+---------+------+ 2141 Figure 34: Non-SM: Summary of the use of headers from RAL to RUL with 2142 encapsulation to the root. 2144 +-----------+------+--------+---------+---------+---------+---------+ 2145 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL | 2146 | | src | | | | | dst | 2147 | | node | | | | | node | 2148 +-----------+------+--------+---------+---------+---------+---------+ 2149 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | -- | 2150 | headers | | | (RH3, | | | | 2151 | | | | RPI2) | | | | 2152 +-----------+------+--------+---------+---------+---------+---------+ 2153 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- | 2154 | headers | | | | (RH3, | | | 2155 | | | | | RPI2) | | | 2156 +-----------+------+--------+---------+---------+---------+---------+ 2157 | Removed | -- | -- | -- | -- | IP6-IP6 | -- | 2158 | headers | | | | | (RH3, | | 2159 | | | | | | RPI2) | | 2160 +-----------+------+--------+---------+---------+---------+---------+ 2161 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 2162 | headers | | | | | |(Ignored)| 2163 +-----------+------+--------+---------+---------+---------+---------+ 2165 Figure 35: Non-SM: Summary of the use of headers from RAL to RUL 2166 without encapsulation to the root. 2168 8.3.3. Non-SM: Example of Flow from RUL to RAL 2170 In this case the flow comprises: 2172 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2173 --> RAL dst (6LN) 2175 For example, a communication flow could be: Node G (RUL)--> Node E 2176 --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL) 2178 6LR_ia represents the intermediate routers from source to the root, 1 2179 <= ia <= n, where n is the total number of intermediate routers (6LR) 2181 6LR_id represents the intermediate routers from the root to the 2182 destination, 1 <= id <= m, where m is the total number of the 2183 intermediate routers (6LR). 2185 In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1) 2186 inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will 2187 remove this RPI, and add its own IPv6-in-IPv6 header containing an 2188 RH3 header and an RPI (RPI2). 2190 The Figure 36 shows the table that summarizes what headers are needed 2191 for this use case. 2193 +----------+------+---------+---------+---------+---------+---------+ 2194 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 2195 | | src | | | | | dst | 2196 | | node | | | | | node | 2197 +----------+------+---------+---------+---------+---------+---------+ 2198 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 2199 | headers | | (RPI1) | | (RH3, | | | 2200 | | | | | RPI2) | | | 2201 +----------+------+---------+---------+---------+---------+---------+ 2202 | Modified | -- | | | -- | IP6-IP6 | -- | 2203 | headers | | -- | RPI1 | | (RH3, | | 2204 | | | | | | RPI2) | | 2205 +----------+------+---------+---------+---------+---------+---------+ 2206 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 2207 | headers | | -- | | (RPI1) | | (RH3, | 2208 | | | | | | | RPI2) | 2209 +----------+------+---------+---------+---------+---------+---------+ 2210 |Untouched | -- | -- | -- | -- | -- | -- | 2211 | headers | | | | | | | 2212 +----------+------+---------+---------+---------+---------+---------+ 2214 Figure 36: Non-SM: Summary of the use of headers from RUL to RAL. 2216 8.3.4. Non-SM: Example of Flow from RUL to RUL 2218 In this case the flow comprises: 2220 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2221 --> RUL (IPv6 dst node) 2223 For example, a communication flow could be: Node G --> Node E --> 2224 Node B --> Node A (root) --> Node C --> Node J 2226 6LR_ia represents the intermediate routers from source to the root, 1 2227 <= ia <= n, where n is the total number of intermediate routers (6LR) 2229 6LR_id represents the intermediate routers from the root to the 2230 destination, 1 <= id <= m, where m is the total number of the 2231 intermediate routers (6LR). 2233 This scenario is the combination of the previous two cases. 2235 The Figure 37 shows the table that summarizes what headers are needed 2236 for this use case. 2238 +---------+------+-------+-------+---------+-------+---------+------+ 2239 | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL | 2240 | | src | | | | | | dst | 2241 | | node | | | | | | node | 2242 +---------+------+-------+-------+---------+-------+---------+------+ 2243 | Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 2244 | headers | | (RPI1)| | (RH3, | | | | 2245 | | | | | RPI2) | | | | 2246 +---------+------+-------+-------+---------+-------+---------+------+ 2247 | Modified| -- | -- | | -- |IP6-IP6| -- | -- | 2248 | headers | | | RPI1 | | (RH3, | | | 2249 | | | | | | RPI2)| | | 2250 +---------+------+-------+-------+---------+-------+---------+------+ 2251 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2252 | headers | | | | (RPI1) | | (RH3, | | 2253 | | | | | | | RPI2) | | 2254 +---------+------+-------+-------+---------+-------+---------+------+ 2255 |Untouched| -- | -- | -- | -- | -- | -- | -- | 2256 | headers | | | | | | | | 2257 +---------+------+-------+-------+---------+-------+---------+------+ 2259 Figure 37: Non-SM: Summary of the use of headers from RUL to RUL 2261 9. Operational Considerations of supporting RUL-leaves 2263 Roughly half of the situations described in this document involve 2264 leaf ("host") nodes that do not speak RPL. These nodes fall into two 2265 further categories: ones that drop a packet that have RPI or RH3 2266 headers, and ones that continue to process a packet that has RPI and/ 2267 or RH3 headers. 2269 [RFC8200] provides for new rules that suggest that nodes that have 2270 not been configured (explicitly) to examine Hop-by-Hop headers, 2271 should ignore those headers, and continue processing the packet. 2272 Despite this, and despite the switch from 0x63 to 0x23, there may be 2273 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 2274 drop packets that continue to have RPL artifacts in them. In 2275 general, such hosts can not be easily supported in RPL LLNs. 2277 There are some specific cases where it is possible to remove the RPL 2278 artifacts prior to forwarding the packet to the leaf host. The 2279 critical thing is that the artifacts have been inserted by the RPL 2280 root inside an IPv6-in-IPv6 header, and that the header has been 2281 addressed to the 6LR immediately prior to the leaf node. In that 2282 case, in the process of removing the IPv6-in-IPv6 header, the 2283 artifacts can also be removed. 2285 The above case occurs whenever traffic originates from the outside 2286 the LLN (the "Internet" cases above), and non-storing mode is used. 2287 In non-storing mode, the RPL root knows the exact topology (as it 2288 must create the RH3 header) and therefore knows which 6LR is prior to 2289 the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf 2290 Node G, or Node C is the 6LR prior to leaf Node J. 2292 traffic originating from the RPL root (such as when the data 2293 collection system is co-located on the RPL root), does not require an 2294 IPv6-in-IPv6 header (in storing or non-storing mode), as the packet 2295 is originating at the root, and the root can insert the RPI and RH3 2296 headers directly into the packet, as it is formed. Such a packet is 2297 slightly smaller, but only can be sent to nodes (whether RPL aware or 2298 not), that will tolerate the RPL artifacts. 2300 An operator that finds itself with a high amount of traffic from the 2301 RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 2302 encapsulation if the leaf is not tolerant of the RPL artifacts. Such 2303 an operator could otherwise omit this unnecessary header if it was 2304 certain of the properties of the leaf. 2306 As storing mode can not know the final path of the traffic, 2307 intolerant (that drop packets with RPL artifacts) leaf nodes can not 2308 be supported. 2310 10. Operational considerations of introducing 0x23 2312 This section describes the operational considerations of introducing 2313 the new RPI Option Type of 0x23. 2315 During bootstrapping the node gets the DIO with the information of 2316 RPI Option Type, indicating the new RPI in the DODAG Configuration 2317 option Flag. The DODAG root is in charge to configure the current 2318 network to the new value, through DIO messages and when all the nodes 2319 are set with the new value. The DODAG should change to a new DODAG 2320 version. In case of rebooting, the node does not remember the RPI 2321 Option Type. Thus, the DIO is sent with a flag indicating the new 2322 RPI Option Type. 2324 The DODAG Configuration option is contained in a RPL DIO message, 2325 which contains a unique DTSN counter. The leaf nodes respond to this 2326 message with DAO messages containing the same DTSN. This is a normal 2327 part of RPL routing; the RPL root therefore knows when the updated 2328 DODAG Configuration option has been seen by all nodes. 2330 Before the migration happens, all the RPL-aware nodes should support 2331 both values . The migration procedure is triggered when the DIO is 2332 sent with the flag indicating the new RPI Option Type. Namely, it 2333 remains at 0x63 until it is sure that the network is capable of 0x23, 2334 then it abruptly changes to 0x23. This options allows to send 2335 packets to not-RPL nodes, which should ignore the option and continue 2336 processing the packets. 2338 As mentioned previously, indicating the new RPI in the DODAG 2339 Configuration option flag is a way to avoid the flag day (lack of 2340 interoperation) in a network using 0x63 as the RPI Option Type value. 2341 It is suggested that RPL implementations accept both 0x63 and 0x23 2342 RPI Option type values when processing the header to enable 2343 interoperability. 2345 11. IANA Considerations 2347 11.1. Option Type in RPL Option 2349 This document updates the registration made in [RFC6553] Destination 2350 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2351 Figure 38. 2353 +-------+-------------------+------------------------+---------- -+ 2354 | Hex | Binary Value | Description | Reference | 2355 + Value +-------------------+ + + 2356 | | act | chg | rest | | | 2357 +-------+-----+-----+-------+------------------------+------------+ 2358 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2359 +-------+-----+-----+-------+------------------------+------------+ 2360 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2361 | | | | | |[RFCXXXX](*)| 2362 +-------+-----+-----+-------+------------------------+------------+ 2364 Figure 38: Option Type in RPL Option.(*)represents this document 2366 DODAG Configuration option is updated as follows (Figure 39): 2368 +------------+-----------------+---------------+ 2369 | Bit number | Description | Reference | 2370 +------------+-----------------+---------------+ 2371 | 3 | RPI 0x23 enable | This document | 2372 +------------+-----------------+---------------+ 2374 Figure 39: DODAG Configuration option Flag to indicate the RPI-flag- 2375 day. 2377 11.2. Change to the DODAG Configuration Options Flags registry 2379 This document requests IANA to change the name of the "DODAG 2380 Configuration Option Flags" registry to "DODAG Configuration Option 2381 Flags for MOP 0..6". 2383 11.3. Change MOP value 7 to Reserved 2385 This document requests the changing the registration status of value 2386 7 in the Mode of Operation registry from Unassigned to Reserved. 2387 This change is in support of future work. 2389 12. Security Considerations 2391 The security considerations covered in [RFC6553] and [RFC6554] apply 2392 when the packets are in the RPL Domain. 2394 The IPv6-in-IPv6 mechanism described in this document is much more 2395 limited than the general mechanism described in [RFC2473]. The 2396 willingness of each node in the LLN to decapsulate packets and 2397 forward them could be exploited by nodes to disguise the origin of an 2398 attack. 2400 While a typical LLN may be a very poor origin for attack traffic (as 2401 the networks tend to be very slow, and the nodes often have very low 2402 duty cycles), given enough nodes, LLNs could still have a significant 2403 impact, particularly if attack is targeting another LLN. 2404 Additionally, some uses of RPL involve large backbone ISP scale 2405 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2406 equipped with multiple 100Gb/s interfaces. 2408 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2409 LLN as described above will make sure that any attack that is mounted 2410 must originate from compromised nodes within the LLN. The use of 2411 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2412 alert the operator to the existence of the attack, as well as drop 2413 the attack traffic. As the RPL network is typically numbered from a 2414 single prefix, which is itself assigned by RPL, BCP38 filtering 2415 involves a single prefix comparison and should be trivial to 2416 automatically configure. 2418 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2419 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2420 communications between a new Pledge and the Join Registrar/ 2421 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2422 and [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. This is the case 2423 for the RPL root to do careful filtering: it occurs only when the 2424 Join Coordinator is not co-located inside the RPL root. 2426 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2427 only be by a node within the LLN on another node within the LLN. 2428 Such an attack could, of course, be done directly. An attack of this 2429 kind is meaningful only if the source addresses are either fake or if 2430 the point is to amplify return traffic. Such an attack, could also 2431 be done without the use of IPv6-in-IPv6 headers using forged source 2432 addresses. If the attack requires bi-directional communication, then 2433 IPv6-in-IPv6 provides no advantages. 2435 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2436 about creating security issues. In the Security Considerations 2437 section of [RFC2473], it was suggested that tunnel entry and exit 2438 points can be secured by securing the IPv6 path between them. This 2439 recommendation is not practical for RPL networks. [RFC5406] goes 2440 into some detail on what additional details would be needed in order 2441 to "Use IPsec". Use of ESP would prevent [RFC8138] compression 2442 (compression must occur before encryption), and [RFC8138] compression 2443 is lossy in a way that prevents use of AH. These are minor issues. 2444 The major issue is how to establish trust enough such that IKEv2 2445 could be used. This would require a system of certificates to be 2446 present in every single node, including any Internet nodes that might 2447 need to communicate with the LLN. Thus, using IPsec requires a 2448 global PKI in the general case. 2450 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2451 IPv6 headers would in the general case scale with the square of the 2452 number of nodes. This is a lot of resource for a constrained nodes 2453 on a constrained network. In the end, the IPsec tunnels would be 2454 providing only BCP38-like origin authentication! That is, IPsec 2455 provides a transitive guarantee to the tunnel exit point that the 2456 tunnel entry point did BCP38 on traffic going in. Just doing origin 2457 filtering per BCP 38 at the entry and exit of the LLN provides a 2458 similar level of security without all the scaling and trust problems 2459 related to IPv6 tunnels as discussed in RFC 2473. IPsec is not 2460 recommended. 2462 An LLN with hostile nodes within it would not be protected against 2463 impersonation with the LLN by entry/exit filtering. 2465 The RH3 header usage described here can be abused in equivalent ways 2466 (to disguise the origin of traffic and attack other nodes) with an 2467 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2468 attacker's RH3 header will not be seen by the network until it 2469 reaches the end host, which will decapsulate it. An end-host should 2470 be suspicious about an RH3 header which has additional hops which 2471 have not yet been processed, and SHOULD ignore such a second RH3 2472 header. 2474 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2475 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2476 will see the second RH3 header and MAY choose to discard the packet 2477 if the RH3 header has not been completely consumed. A consumed 2478 (inert) RH3 header could be present in a packet that flows from one 2479 LLN, crosses the Internet, and enters another LLN. As per the 2480 discussion in this document, such headers do not need to be removed. 2481 However, there is no case described in this document where an RH3 is 2482 inserted in a non-storing network on traffic that is leaving the LLN, 2483 but this document should not preclude such a future innovation. It 2484 should just be noted that an incoming RH3 must be fully consumed, or 2485 very carefully inspected. 2487 The RPI, if permitted to enter the LLN, could be used by an attacker 2488 to change the priority of a packet by selecting a different 2489 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2490 It could also be that not all nodes are reachable in an LLN using the 2491 default RPLInstanceID, but a change of RPLInstanceID would permit an 2492 attacker to bypass such filtering. Like the RH3, an RPI is to be 2493 inserted by the RPL root on traffic entering the LLN by first 2494 inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will 2495 not be seen by the network. Upon reaching the destination node the 2496 RPI has no further meaning and is just skipped; the presence of a 2497 second RPI will have no meaning to the end node as the packet has 2498 already been identified as being at it's final destination. 2500 For traffic leaving a RUL, if the RUL adds an opaque RPI then the 2501 description of the RAL applies. The 6LR as a RPL border router 2502 SHOULD rewrite the RPI to indicate the selected Instance and set the 2503 flags. This is done in order to avoid: 1) The leaf is an external 2504 router that passes a packet that it did not generate and that carries 2505 an unrelated RPI and 2) The leaf is an attacker or presents 2506 misconfiguration and tries to inject traffic in a protected instance. 2507 Also, this applies in the case where the leaf is aware of the RPL 2508 instance and passes a correct RPI, the 6LR needs a configuration that 2509 allows that leaf to inject in that instance. 2511 The RH3 and RPIs could be abused by an attacker inside of the network 2512 to route packets on non-obvious ways, perhaps eluding observation. 2513 This usage appears consistent with a normal operation of [RFC6997] 2514 and can not be restricted at all. This is a feature, not a bug. 2516 [RFC7416] deals with many other threats to LLNs not directly related 2517 to the use of IPv6-in-IPv6 headers, and this document does not change 2518 that analysis. 2520 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2521 attack on another part of the LLN, while disguising the origin of the 2522 attack. The mechanism can even be abused to make it appear that the 2523 attack is coming from outside the LLN, and unless countered, this 2524 could be used to mount a Distributed Denial Of Service attack upon 2525 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2526 such attacks already seen in the real world. 2528 If an attack comes from inside of LLN, it can be alleviated with SAVI 2529 (Source Address Validation Improvement) using [RFC8505] with 2530 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2531 traffic with an address that is not registered, and the registration 2532 process checks for topological correctness. Notice that there is an 2533 L2 authentication in most of the cases. If an attack comes from 2534 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2535 but by construction, the RH3 can typically only address nodes within 2536 the LLN. That is, an RH3 with a CmprI less than 8 , should be 2537 considered an attack (see RFC6554, section 3). 2539 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2540 through the RPL root to perform this attack. To counter, the RPL 2541 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2542 simpler solution), or it SHOULD walk the IP header extension chain 2543 until it can inspect the upper-layer-payload as described in 2544 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2545 on the source addresses of all IP headers that it examines in both 2546 directions. 2548 Note: there are some situations where a prefix will spread across 2549 multiple LLNs via mechanisms such as the one described in 2550 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2551 needs to take this into account, either by exchanging detailed 2552 routing information on each LLN, or by moving the BCP38 filtering 2553 further towards the Internet, so that the details of the multiple 2554 LLNs do not matter. 2556 13. Acknowledgments 2558 This work is done thanks to the grant given by the StandICT.eu 2559 project. 2561 A special BIG thanks to C. M. Heard for the help with the 2562 Section 4. Much of the redaction in that section is based on his 2563 comments. 2565 Additionally, the authors would like to acknowledge the review, 2566 feedback, and comments of (alphabetical order): Dominique Barthel, 2567 Robert Cragie, Simon Duquennoy, Ralph Droms, Cenk Guendogan, Rahul 2568 Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Mercado, 2569 Subramanian Moonesamy, Marcela Orbiscay, Charlie Perkins, Cristian 2570 Perez, Alvaro Retana, Peter van der Stok, Xavier Vilajosana, Eric 2571 Vyncke and Thomas Watteyne. 2573 14. References 2575 14.1. Normative References 2577 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2578 Defeating Denial of Service Attacks which employ IP Source 2579 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2580 May 2000, . 2582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2583 Requirement Levels", BCP 14, RFC 2119, 2584 DOI 10.17487/RFC2119, March 1997, 2585 . 2587 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2588 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2589 2010, . 2591 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2592 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2593 DOI 10.17487/RFC6282, September 2011, 2594 . 2596 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2597 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2598 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2599 Low-Power and Lossy Networks", RFC 6550, 2600 DOI 10.17487/RFC6550, March 2012, 2601 . 2603 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2604 Power and Lossy Networks (RPL) Option for Carrying RPL 2605 Information in Data-Plane Datagrams", RFC 6553, 2606 DOI 10.17487/RFC6553, March 2012, 2607 . 2609 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2610 Routing Header for Source Routes with the Routing Protocol 2611 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2612 DOI 10.17487/RFC6554, March 2012, 2613 . 2615 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2616 of IPv6 Extension Headers", RFC 7045, 2617 DOI 10.17487/RFC7045, December 2013, 2618 . 2620 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2621 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2622 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2623 . 2625 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2626 "IPv6 over Low-Power Wireless Personal Area Network 2627 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2628 April 2017, . 2630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2631 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2632 May 2017, . 2634 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2635 (IPv6) Specification", STD 86, RFC 8200, 2636 DOI 10.17487/RFC8200, July 2017, 2637 . 2639 14.2. Informative References 2641 [DDOS-KREBS] 2642 Goodin, D., "Record-breaking DDoS reportedly delivered by 2643 >145k hacked cameras", September 2016, 2644 . 2647 [I-D.ietf-6lo-ap-nd] 2648 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2649 "Address Protected Neighbor Discovery for Low-power and 2650 Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in 2651 progress), April 2020. 2653 [I-D.ietf-6lo-backbone-router] 2654 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2655 Backbone Router", draft-ietf-6lo-backbone-router-20 (work 2656 in progress), March 2020. 2658 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2659 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2660 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 2661 progress), July 2019. 2663 [I-D.ietf-anima-autonomic-control-plane] 2664 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2665 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2666 plane-30 (work in progress), October 2020. 2668 [I-D.ietf-anima-bootstrapping-keyinfra] 2669 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2670 and K. Watsen, "Bootstrapping Remote Secure Key 2671 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2672 keyinfra-45 (work in progress), November 2020. 2674 [I-D.ietf-intarea-tunnels] 2675 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2676 Architecture", draft-ietf-intarea-tunnels-10 (work in 2677 progress), September 2019. 2679 [I-D.ietf-roll-unaware-leaves] 2680 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 2681 draft-ietf-roll-unaware-leaves-23 (work in progress), 2682 November 2020. 2684 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2685 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2686 December 1998, . 2688 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2689 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2690 December 1998, . 2692 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2693 Control Message Protocol (ICMPv6) for the Internet 2694 Protocol Version 6 (IPv6) Specification", STD 89, 2695 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2696 . 2698 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2699 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2700 February 2009, . 2702 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2703 "IPv6 Flow Label Specification", RFC 6437, 2704 DOI 10.17487/RFC6437, November 2011, 2705 . 2707 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2708 Bormann, "Neighbor Discovery Optimization for IPv6 over 2709 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2710 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2711 . 2713 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2714 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2715 in Low-Power and Lossy Networks", RFC 6997, 2716 DOI 10.17487/RFC6997, August 2013, 2717 . 2719 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2720 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2721 2014, . 2723 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2724 and M. Richardson, Ed., "A Security Threat Analysis for 2725 the Routing Protocol for Low-Power and Lossy Networks 2726 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2727 . 2729 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2730 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2731 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2732 May 2017, . 2734 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2735 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2736 January 2019, . 2738 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2739 Perkins, "Registration Extensions for IPv6 over Low-Power 2740 Wireless Personal Area Network (6LoWPAN) Neighbor 2741 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2742 . 2744 Authors' Addresses 2746 Maria Ines Robles 2747 Universidad Tecno. Nac.(UTN)-FRM, Argentina / Aalto University, Finland 2749 Email: mariainesrobles@gmail.com 2751 Michael C. Richardson 2752 Sandelman Software Works 2753 470 Dawson Avenue 2754 Ottawa, ON K1Z 5V7 2755 CA 2757 Email: mcr+ietf@sandelman.ca 2758 URI: http://www.sandelman.ca/mcr/ 2760 Pascal Thubert 2761 Cisco Systems, Inc 2762 Building D 2763 45 Allee des Ormes - BP1200 2764 MOUGINS - Sophia Antipolis 06254 2765 FRANCE 2767 Phone: +33 497 23 26 34 2768 Email: pthubert@cisco.com