idnits 2.17.00 (12 Aug 2021) /tmp/idnits37791/draft-ietf-roll-useofrplinfo-44.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 (January 15, 2021) is 484 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-6lo-ap-nd has been published as RFC 8928 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-anima-autonomic-control-plane has been published as RFC 8994 == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: draft-ietf-roll-unaware-leaves has been published as RFC 9010 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group M. Robles 3 Internet-Draft UTN-FRM/Aalto 4 Updates: 6553, 6550, 8138 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: July 19, 2021 P. Thubert 7 Cisco 8 January 15, 2021 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-44 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 July 19, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 56 119 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 121 14.1. Normative References . . . . . . . . . . . . . . . . . . 60 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 the routing 133 information that is defined in [RFC6550] and transported in the RPL 134 Option. RFC6554 [RFC6554] defines the "RPL Source Route Header" 135 (RH3), an IPv6 Extension Header to deliver datagrams within a RPL 136 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 herein require the use of IPv6-in- 166 IPv6 packet encapsulation. When encapsulating and decapsulating 167 packets, [RFC6040] MUST be applied to map the setting of the explicit 168 congestion notification (ECN) field between inner and outer headers. 169 Additionally, [I-D.ietf-intarea-tunnels] is recommended reading to 170 explain the relationship of IP tunnels to existing protocol layers 171 and the challenges in supporting IP tunneling. 173 Non-constrained uses of RPL are not in scope of this document, and 174 applicability statements for those uses may provide different advice, 175 E.g. [I-D.ietf-anima-autonomic-control-plane]. 177 1.1. Overview 179 The rest of the document is organized as follows: Section 2 describes 180 the used terminology. Section 3 provides a RPL Overview. Section 4 181 describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5 182 provides the reference topology used for the uses cases. Section 6 183 describes the use cases included. Section 7 describes the storing 184 mode cases and section 8 the non-storing mode cases. Section 9 185 describes the operational considerations of supporting RPL-unaware- 186 leaves. Section 10 depicts operational considerations for the 187 proposed change on RPI Option Type, section 11 the IANA 188 considerations and then section 12 describes the security aspects. 190 2. Terminology and Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 Terminology defined in [RFC7102] applies to this document: LLN, RPL, 199 RPL domain and ROLL. 201 Consumed: A Routing Header is consumed when the Segments Left field 202 is zero, which indicates that the destination in the IPv6 header is 203 the final destination of the packet and that the hops in the Routing 204 Header have been traversed. 206 RPL Leaf: An IPv6 host that is attached to a RPL router and obtains 207 connectivity through a RPL Destination Oriented Directed Acyclic 208 Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a 209 consumed Routing Header and as an IPv6 host, it is expected to ignore 210 a Hop-by-Hop header. It results that a RPL Leaf can correctly 211 receive a packet with RPL artifacts. On the other hand, a RPL Leaf 212 is not expected to generate RPL artifacts or to support IP-in-IP 213 encapsulation. For simplification, this document uses the standalone 214 term leaf to mean a RPL leaf. 216 RPL Packet Information (RPI): The information defined abstractly in 217 [RFC6550] to be placed in IP packets. The term is commonly used, 218 including in this document, to refer to the RPL Option [RFC6553] that 219 transports that abstract information in an IPv6 Hop-by-Hop Header. 220 [RFC8138] provides an alternate (more compressed) formating for the 221 same abstract information. 223 RPL-aware-node (RAN): A device which implements RPL. Please note 224 that the device can be found inside the LLN or outside LLN. 226 RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. 228 RPL-unaware-node: A device which does not implement RPL, thus the 229 device is not-RPL-aware. Please note that the device can be found 230 inside the LLN. 232 RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. 234 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any 235 host or router participating in a LoWPAN. This term is used when 236 referring to situations in which either a host or router can play the 237 role described.". In this document, a 6LN acts as a leaf. 239 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate 240 router in the LoWPAN that is able to send and receive Router 241 Advertisements (RAs) and Router Solicitations (RSs) as well as 242 forward and route IPv6 packets. 6LoWPAN routers are present only in 243 route-over topologies." 245 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 246 router located at the junction of separate 6LoWPAN networks or 247 between a 6LoWPAN network and another IP network. There may be one 248 or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the 249 responsible authority for IPv6 prefix propagation for the 6LoWPAN 250 network it is serving. An isolated LoWPAN also contains a 6LBR in 251 the network, which provides the prefix(es) for the isolated network." 253 Flag Day: A Flag Day is caused when a network is reconfigured in a 254 way that nodes running the older configuration can not communicate 255 with nodes running the new configuration. For instance, when the 256 ARPANET changed from IP version 3 to IP version 4 on January 1, 1983 257 ([RFC0801]). In the context of this document, a switch from RPI 258 Option Type (0x63) and Option Type (0x23) presents as a disruptive 259 changeover. In order to reduce the amount of time for such a 260 changeover, Section 4.1.3 provides a mechanism to allow nodes to be 261 incrementally upgraded. 263 Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- 264 aware-nodes send information to the root about their parents. Thus, 265 the root knows the topology. Because the root knows the topology, 266 the intermediate 6LRs do not maintain routing state and source 267 routing is needed. 269 Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes 270 (6LRs) maintain routing state (of the children) so that source 271 routing is not needed. 273 Note: Due to lack of space in some figures (tables) we refer to IPv6- 274 in-IPv6 as IP6-IP6. 276 3. RPL Overview 278 RPL defines the RPL Control messages (control plane), a new ICMPv6 279 [RFC4443] message with Type 155. DIS (DODAG Information 280 Solicitation), DIO (DODAG Information Object) and DAO (Destination 281 Advertisement Object) messages are all RPL Control messages but with 282 different Code values. A RPL Stack is shown in Figure 1. 284 +--------------+ 285 | Upper Layers | 286 | | 287 +--------------+ 288 | RPL | 289 | | 290 +--------------+ 291 | ICMPv6 | 292 | | 293 +--------------+ 294 | IPv6 | 295 | | 296 +--------------+ 297 | 6LoWPAN | 298 | | 299 +--------------+ 300 | PHY-MAC | 301 | | 302 +--------------+ 304 Figure 1: RPL Stack. 306 RPL supports two modes of Downward internal traffic: in storing mode 307 (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully 308 source routed. A RPL Instance is either fully storing or fully non- 309 storing, i.e. a RPL Instance with a combination of a fully storing 310 and non-storing nodes is not supported with the current 311 specifications at the time of writing this document. External routes 312 are advertised with non-storing-mode messaging even in a storing mode 313 network, see Section 4.1.1 315 4. Updates to RFC6550, RFC6553 and RFC8138 317 4.1. Updates to RFC6550 319 4.1.1. Advertising External Routes with Non-Storing Mode Signaling. 321 Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to 322 indicate that the 6LR that generates the DAO redistributes external 323 targets into the RPL network. An external Target is a Target that 324 has been learned through an alternate protocol, for instance a route 325 to a prefix that is outside the RPL domain but reachable via a 6LR. 326 Being outside of the RPL domain, a node that is reached via an 327 external target cannot be guaranteed to ignore the RPL artifacts and 328 cannot be expected to process the [RFC8138] compression correctly. 329 This means that the RPL artifacts should be contained in an IP-in-IP 330 encapsulation that is removed by the 6LR, and that any remaining 331 compression should be expanded by the 6LR before it forwards a packet 332 outside the RPL domain. 334 This specification updates [RFC6550] to RECOMMEND that external 335 targets are advertised using Non-Storing Mode DAO messaging even in a 336 Storing-Mode network. This way, external routes are not advertised 337 within the DODAG and all packets to an external target reach the Root 338 like normal Non-Storing Mode traffic. The Non-Storing Mode DAO 339 informs the Root of the address of the 6LR that injects the external 340 route, and the root uses IP-in-IP encapsulation to that 6LR, which 341 terminates the IP-in-IP tunnel and forwards the original packet 342 outside the RPL domain free of RPL artifacts. 344 In the other direction, for traffic coming from an external target 345 into the LLN, the parent (6LR) that injects the traffic always 346 encapsulates to the root. This whole operation is transparent to 347 intermediate routers that only see traffic between the 6LR and the 348 Root, and only the Root and the 6LRs that inject external routes in 349 the network need to be upgraded to add this function to the network. 351 A RUL is a special case of external target when the target is 352 actually a host and it is known to support a consumed Routing Header 353 and to ignore a Hop-by-Hop header as prescribed by [RFC8200]. The 354 target may have been learned through an external routing protocol or 355 may have been registered to the 6LR using [RFC8505]. 357 In order to enable IP-in-IP all the way to a 6LN, it is beneficial 358 that the 6LN supports decapsulating IP-in-IP, but that is not assumed 359 by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a 360 packet SHOULD terminate the tunnel at a parent 6LR unless it is aware 361 that the RUL supports IP-in-IP decapsulation. 363 A node that is reachable over an external route is not expected to 364 support [RFC8138]. Whether a decapsulation took place or not and 365 even when the 6LR is delivering the packet to a RUL, the 6LR that 366 injected an external route MUST uncompress the packet before 367 forwarding over that external route. 369 4.1.2. Configuration Options and Mode of Operation 371 Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as 372 containing a series of Flags in the first octet of the payload. 374 Anticipating future work to revise RPL relating to how the LLN and 375 DODAG are configured, this document renames the DODAG Configuration 376 Option Flags registry so that it applies to Mode of Operation (MOP) 377 values zero (0) to six (6) only, leaving the flags unassigned for MOP 378 value seven (7).The MOP is described in RFC6550 section 6.3.1. 380 In addition, this document reserves MOP value 7 for future expansion. 382 See Sections 11.2 and 11.3. 384 4.1.3. Indicating the new RPI in the DODAG Configuration option Flag. 386 In order to avoid a Flag Day caused by lack of interoperation between 387 new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this 388 section defines a flag in the DIO Configuration option, to indicate 389 when the new RPI Option Type can be safely used. This means, the 390 flag is going to indicate the value of Option Type that the network 391 will be using for the RPL Option. Thus, when a node joins to a 392 network it will know which value to use. With this, RPL-capable 393 nodes know if it is safe to use 0x23 when creating a new RPL Option. 394 A node that forwards a packet with an RPI MUST NOT modify the Option 395 Type of the RPL Option. 397 This is done using a DODAG Configuration option flag which will 398 signal "RPI 0x23 enable" and propagate through the network. 399 Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) 400 in the DIO Base Object. The flag is defined only for MOP value 401 between 0 to 6. 403 For a MOP value of 7, a node MUST use the RPI 0x23 option. 405 As stated in [RFC6550] the DODAG Configuration option is present in 406 DIO messages. The DODAG Configuration option distributes 407 configuration information. It is generally static, and does not 408 change within the DODAG. This information is configured at the DODAG 409 root and distributed throughout the DODAG with the DODAG 410 Configuration option. Nodes other than the DODAG root do not modify 411 this information when propagating the DODAG Configuration option. 413 Currently, the DODAG Configuration option in [RFC6550] states: "the 414 unused bits MUST be initialized to zero by the sender and MUST be 415 ignored by the receiver". If the flag is received with a value zero 416 (which is the default), then new nodes will remain in RFC6553 417 Compatible Mode; originating traffic with the old-RPI Option Type 418 (0x63) value. If the flag is received with a value of 1, then the 419 value for the RPL Option MUST be set to 0x23. 421 Bit number three of the flag field in the DODAG Configuration option 422 is to be used as shown in Figure 2 (which is the same as Figure 39 in 423 Section 11 and is shown here for convenience): 425 +------------+-----------------+---------------+ 426 | Bit number | Description | Reference | 427 +------------+-----------------+---------------+ 428 | 3 | RPI 0x23 enable | This document | 429 +------------+-----------------+---------------+ 431 Figure 2: DODAG Configuration option Flag to indicate the RPI-flag- 432 day. 434 In the case of reboot, the node (6LN or 6LR) does not remember the 435 RPI Option Type (i.e., whether or not the flag is set), so the node 436 will not trigger DIO messages until a DIO message is received 437 indicating the RPI value to be used. The node will use the value 438 0x23 if the network supports this feature. 440 4.2. Updates to RFC6553: Indicating the new RPI Option Type. 442 This modification is required in order to be able to send, for 443 example, IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node 444 through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 445 encapsulation. 447 [RFC6553] (Section 6, Page 7) states as shown in Figure 3, that in 448 the Option Type field of the RPL Option, the two high order bits must 449 be set to '01' and the third bit is equal to '1'. The first two bits 450 indicate that the IPv6 node must discard the packet if it doesn't 451 recognize the Option Type, and the third bit indicates that the 452 Option Data may change in route. The remaining bits serve as the 453 Option Type. 455 +-------+-------------------+----------------+-----------+ 456 | Hex | Binary Value | Description | Reference | 457 + Value +-------------------+ + + 458 | | act | chg | rest | | | 459 +-------+-----+-----+-------+----------------+-----------+ 460 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 461 +-------+-----+-----+-------+----------------+-----------+ 463 Figure 3: Option Type in RPL Option. 465 This document illustrates that it is not always possible to know for 466 sure at the source that a packet will only travel within the RPL 467 domain or may leave it. 469 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 470 the outer IPv6 header chain could potentially impact core routers in 471 the internet. So at that time, it was decided to encapsulate any 472 packet with a RPL Option using IPv6-in-IPv6 in all cases where it was 473 unclear whether the packet would remain within the RPL domain. In 474 the exception case where a packet would still leak, the Option Type 475 would ensure that the first router in the Internet that does not 476 recognize the option would drop the packet and protect the rest of 477 the network. 479 Even with [RFC8138], where the IPv6-in-IPv6 header is compressed, 480 this approach yields extra bytes in a packet; this means consuming 481 more energy, more bandwidth, incurring higher chances of loss and 482 possibly causing a fragmentation at the 6LoWPAN level. This impacts 483 the daily operation of constrained devices for a case that generally 484 does not happen and would not heavily impact the core anyway. 486 While intention was and remains that the Hop-by-Hop header with a RPL 487 Option should be confined within the RPL domain, this specification 488 modifies this behavior in order to reduce the dependency on IPv6-in- 489 IPv6 and protect the constrained devices. Section 4 of [RFC8200] 490 clarifies the behaviour of routers in the Internet as follows: "it is 491 now expected that nodes along a packet's delivery path only examine 492 and process the Hop-by-Hop Options header if explicitly configured to 493 do so". 495 When unclear about the travel of a packet, it becomes preferable for 496 a source not to encapsulate, accepting the fact that the packet may 497 leave the RPL domain on its way to its destination. In that event, 498 the packet should reach its destination and should not be discarded 499 by the first node that does not recognize the RPL Option. But with 500 the current value of the Option Type, if a node in the Internet is 501 configured to process the Hop-by-Hop header, and if such node 502 encounters an option with the first two bits set to 01 and conforms 503 to [RFC8200], it will drop the packet. Host systems should do the 504 same, irrespective of the configuration. 506 Thus, this document updates the Option Type of the RPL Option 507 [RFC6553], naming it RPI Option Type for simplicity, to (Figure 4): 508 the two high order bits MUST be set to '00' and the third bit is 509 equal to '1'. The first two bits indicate that the IPv6 node MUST 510 skip over this option and continue processing the header ([RFC8200] 511 Section 4.2) if it doesn't recognize the Option Type, and the third 512 bit continues to be set to indicate that the Option Data may change 513 en route. The rightmost five bits remain at 0x3(00011). This 514 ensures that a packet that leaves the RPL domain of an LLN (or that 515 leaves the LLN entirely) will not be discarded when it contains the 516 RPL Option. 518 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 519 capable) receives a packet with a RPL Option, it should ignore the 520 Hop-by-Hop RPL Option (skip over this option and continue processing 521 the header). This is relevant, as it was mentioned previously, in 522 the case that there is a flow from RAL to Internet (see 523 Section 7.2.1). 525 This is a significant update to [RFC6553]. 527 +-------+-------------------+-------------+------------+ 528 | Hex | Binary Value | Description | Reference | 529 + Value +-------------------+ + + 530 | | act | chg | rest | | | 531 +-------+-----+-----+-------+-------------+------------+ 532 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 533 +-------+-----+-----+-------+-------------+------------+ 535 Figure 4: Revised Option Type in RPL Option. (*)represents this 536 document 538 Without the signaling described below, this change would otherwise 539 create a lack of interoperation (flag day) for existing networks 540 which are currently using 0x63 as the RPI Option Type value. A move 541 to 0x23 will not be understood by those networks. It is suggested 542 that RPL implementations accept both 0x63 and 0x23 when processing 543 the header. 545 When forwarding packets, implementations SHOULD use the same value of 546 RPI Type as was received. This is required because the RPI Option 547 Type does not change en route ([RFC8200] - Section 4.2). It allows 548 the network to be incrementally upgraded and allows the DODAG root to 549 know which parts of the network have been upgraded. 551 When originating new packets, implementations should have an option 552 to determine which value to originate with, this option is controlled 553 by the DIO Configuration option (Section Section 4.1.3). 555 The change of RPI Option Type from 0x63 to 0x23, makes all [RFC8200] 556 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 557 no longer a need to remove the artifacts when sending traffic to the 558 Internet. This change clarifies when to use IPv6-in-IPv6 headers, 559 and how to address them: The Hop-by-Hop Options header containing the 560 RPI MUST always be added when 6LRs originate packets (without IPv6- 561 in-IPv6 headers), and IPv6-in-IPv6 headers MUST always be added when 562 a 6LR finds that it needs to insert a Hop-by-Hop Options header 563 containing the RPL Option. The IPv6-in-IPv6 header is to be 564 addressed to the RPL root when on the way up, and to the end-host 565 when on the way down. 567 In the non-storing case, dealing with not-RPL aware leaf nodes is 568 much easier as the 6LBR (DODAG root) has complete knowledge about the 569 connectivity of all DODAG nodes, and all traffic flows through the 570 root node. 572 The 6LBR can recognize not-RPL aware leaf nodes because it will 573 receive a DAO about that node from the 6LR immediately above that 574 not-RPL aware node. 576 The non-storing mode case does not require the type change from 0x63 577 to 0x23, as the root can always create the right packet. The type 578 change does not adversely affect the non-storing case.(see 579 Section 4.1.3) 581 4.3. Updates to RFC8138: Indicating the way to decompress with the new 582 RPI Option Type. 584 This modification is required in order to be able to decompress the 585 RPL Option with the new Option Type of 0x23. 587 RPI-6LoRH header provides a compressed form for the RPL RPI; see 588 [RFC8138], Section 6. A node that is decompressing this header MUST 589 decompress using the RPI Option Type that is currently active: that 590 is, a choice between 0x23 (new) and 0x63 (old). The node will know 591 which to use based upon the presence of the flag in the DODAG 592 Configuration option defined in Section 4.1.3. E.g. If the network 593 is in 0x23 mode (by DIO option), then it should be decompressed to 594 0x23. 596 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 597 header. 599 There are potential significant advantages to having a single code 600 path that always processes IPv6-in-IPv6 headers with no conditional 601 branches. 603 In Storing Mode, the scenarios where the flow goes from RAL to RUL 604 and RUL to RUL include compression of the IPv6-in-IPv6 and RPI 605 headers. The use of the IPv6-in-IPv6 header is MANDATORY in this 606 case, and it SHOULD be compressed with [RFC8138] section 7. Figure 5 607 illustrates the case in Storing mode where the packet is received 608 from the Internet, then the root encapsulates the packet to insert 609 the RPI. In that example, the leaf is not known to support RFC 8138, 610 and the packet is encapsulated to the 6LR that is the parent and last 611 hop to the final destination. 613 +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... 614 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 615 |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 616 +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-... 617 <-4bytes-> <- RFC 6282 -> 618 No RPL artifact 620 Figure 5: RPI Inserted by the Root in Storing Mode 622 In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the 623 Root, so it is elided in the IP-in-IP 6LoRH. The destination is the 624 parent 6LR of the destination of the inner packet so it cannot be 625 elided. It is placed as the single entry in an SRH-6LoRH as the 626 first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In 627 that example, the type is 1 so the 6LR address is compressed to 2 628 bytes. It results that the total length of the SRH-6LoRH is 4 bytes. 629 Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 630 6LoRH is removed, all the router headers that precede it are also 631 removed. The Paging Dispatch [RFC8025] may also be removed if there 632 was no previous Page change to a Page other than 0 or 1, since the 633 LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and 634 in Page 1. The resulting packet to the destination is the inner 635 packet compressed with [RFC6282]. 637 5. Sample/reference topology 639 A RPL network in general is composed of a 6LBR, a Backbone Router 640 (6BBR), a 6LR and a 6LN as a leaf logically organized in a DODAG 641 structure. 643 Figure 6 shows the reference RPL Topology for this document. The 644 letters above the nodes are there so that they may be referenced in 645 subsequent sections. In the figure, 6LR represents a full router 646 node. The 6LN is a RPL aware router, or host (as a leaf). 647 Additionally, for simplification purposes, it is supposed that the 648 6LBR has direct access to Internet and is the root of the DODAG, thus 649 the 6BBR is not present in the figure. 651 The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no 652 children hosts. 654 The leaves marked as RUL (G and J) are devices that do not speak RPL 655 at all (not-RPL-aware), but use Router-Advertisements, 6LowPAN DAR/ 656 DAC and 6LoWPAN ND only to participate in the network [RFC8505]. In 657 the document these leaves (G and J) are also referred to as a RUL. 659 The 6LBR ("A") in the figure is the root of the Global DODAG. 661 +------------+ 662 | INTERNET ----------+ 663 | | | 664 +------------+ | 665 | 666 | 667 | 668 A | 669 +-------+ 670 |6LBR | 671 +-----------|(root) |-------+ 672 | +-------+ | 673 | | 674 | | 675 | | 676 | | 677 | B |C 678 +---|---+ +---|---+ 679 | 6LR | | 6LR | 680 +---------| |--+ +--- ---+ 681 | +-------+ | | +-------+ | 682 | | | | 683 | | | | 684 | | | | 685 | | | | 686 | D | E | | 687 +-|-----+ +---|---+ | | 688 | 6LR | | 6LR | | | 689 | | +------ | | | 690 +---|---+ | +---|---+ | | 691 | | | | | 692 | | +--+ | | 693 | | | | | 694 | | | | | 695 | | | I | J | 696 F | | G | H | | 697 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 698 | RAL | | RUL | | RAL | | RAL | | RUL | 699 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 700 +-------+ +-------+ +------+ +-------+ +-------+ 702 Figure 6: A reference RPL Topology. 704 6. Use cases 706 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 707 encapsulation are going to be analyzed for a number of representative 708 traffic flows. 710 The use cases describe the communication in the following cases: - 711 Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- 712 nodes with the Internet - Between RUL nodes within the LLN (e.g. see 713 Section 7.1.4) - Inside of the LLN when the final destination address 714 resides outside of the LLN (e.g. see Section 7.2.3). 716 The use cases are as follows: 718 Interaction between Leaf and Root: 720 RAL to root 722 root to RAL 724 RUL to root 726 root to RUL 728 Interaction between Leaf and Internet: 730 RAL to Internet 732 Internet to RAL 734 RUL to Internet 736 Internet to RUL 738 Interaction between leaves: 740 RAL to RAL 742 RAL to RUL 744 RUL to RAL 746 RUL to RUL 748 This document is consistent with the rule that a Header cannot be 749 inserted or removed on the fly inside an IPv6 packet that is being 750 routed. This is a fundamental precept of the IPv6 architecture as 751 outlined in [RFC8200]. 753 As the rank information in the RPI artifact is changed at each hop, 754 it will typically be zero when it arrives at the DODAG root. The 755 DODAG root MUST force it to zero when passing the packet out to the 756 Internet. The Internet will therefore not see any SenderRank 757 information. 759 Despite being legal to leave the RPI artifact in place, an 760 intermediate router that needs to add an extension header (e.g. RH3 761 or RPL Option) MUST still encapsulate the packet in an (additional) 762 outer IP header. The new header is placed after this new outer IP 763 header. 765 A corollary is that an intermediate router can remove an RH3 or RPL 766 Option only if it is placed in an encapsulating IPv6 Header that is 767 addressed TO this intermediate router. When doing the above, the 768 whole encapsulating header must be removed. (A replacement may be 769 added). This sometimes can result in outer IP headers being 770 addressed to the next hop router using link-local address. 772 Both the RPL Option and the RH3 headers may be modified in very 773 specific ways by routers on the path of the packet without the need 774 to add and remove an encapsulating header. Both headers were 775 designed with this modification in mind, and both the RPL RH3 and the 776 RPL Option are marked mutable but recoverable: so an IPsec AH 777 security header can be applied across these headers, but it can not 778 secure the values which mutate. 780 The RPI MUST be present in every single RPL data packet. 782 Prior to [RFC8138], there was significant interest in creating an 783 exception to this rule and removing the RPI for downward flows in 784 non-storing mode. This exception covered a very small number of 785 cases, and caused significant interoperability challenges while 786 adding significant interest in the code and tests. The ability to 787 compress the RPI down to three bytes or less removes much of the 788 pressure to optimize this any further 789 [I-D.ietf-anima-autonomic-control-plane]. 791 Throughout the following subsections, the examples are described in 792 more details in the first subsections, and more concisely in the 793 later ones. 795 The uses cases are delineated based on the following IPV6 and RPL 796 mandates: 798 The RPI has to be in every packet that traverses the LLN. 800 - Because of the above requirement, packets from the Internet have 801 to be encapsulated. 803 - A Header cannot be inserted or removed on the fly inside an IPv6 804 packet that is being routed. 806 - Extension headers may not be added or removed except by the 807 sender or the receiver. 809 - RPI and RH3 headers may be modified by routers on the path of 810 the packet without the need to add and remove an encapsulating 811 header. 813 - an RH3 or RPL Option can only be removed by an intermediate 814 router if it is placed in an encapsulating IPv6 Header, which is 815 addressed to the intermediate router. 817 - Non-storing mode requires downstream encapsulation by root for 818 RH3. 820 The uses cases are delineated based on the following assumptions: 822 This document assumes that the LLN is using the no-drop RPI Option 823 Type (0x23). 825 - Each IPv6 node (including Internet routers) obeys [RFC8200], so 826 that 0x23 RPI Option Type can be safely inserted. 828 - All 6LRs obey [RFC8200]. 830 - The RPI is ignored at the IPv6 dst node (RUL). 832 - In the uses cases, we assume that the RAL supports IP-in-IP 833 encapsulation. 835 - In the uses cases, we don't assume that the RUL supports IP-in- 836 IP encapsulation. 838 - For traffic leaving a RUL, if the RUL adds an opaque RPI then 839 the 6LR as a RPL border router SHOULD rewrite the RPI to indicate 840 the selected Instance and set the flags. 842 - The description for RALs applies to RAN in general. 844 - Non-constrained uses of RPL are not in scope of this document. 846 - Compression is based on [RFC8138]. 848 - The flow label [RFC6437] is not needed in RPL. 850 7. Storing mode 852 In storing mode (SM) (fully stateful), the sender can determine if 853 the destination is inside the LLN by looking if the destination 854 address is matched by the DIO's Prefix Information Option (PIO) 855 option. 857 The following table (Figure 7) itemizes which headers are needed in 858 each of the following scenarios. It indicates whether an IPv6-in- 859 IPv6 header must be added and what destination it must be addressed 860 to: (1) the final destination (the RAL node that is the target 861 (tgt)), (2) the "root", or (3) the 6LR parent of a RUL. 863 In cases where no IPv6-in-IPv6 header is needed, the column states 864 "No", and the destination is N/A (Not Applicable). If the IPv6-in- 865 IPv6 header is needed, the column shows "must". 867 In all cases, the RPI is needed, since it identifies inconsistencies 868 (loops) in the routing topology. In general, the RH3 is not needed 869 because it is not used in storing mode. However, there is one 870 scenario (from the root to the RUL in SM) where the RH3 can be used 871 to point at the RUL (Figure 11). 873 The leaf can be a router 6LR or a host, both indicated as 6LN. The 874 root refers to the 6LBR (see Figure 6). 876 +---------------------+--------------+------------+----------------+ 877 | Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst| 878 +---------------------+--------------+------------+----------------+ 879 | | RAL to root | No | N/A | 880 + +--------------+------------+----------------+ 881 | Leaf - Root | root to RAL | No | N/A | 882 + +--------------+------------+----------------+ 883 | | root to RUL | must | 6LR | 884 + +--------------+------------+----------------+ 885 | | RUL to root | must | root | 886 +---------------------+--------------+------------+----------------+ 887 | | RAL to Int | may | root | 888 + +--------------+------------+----------------+ 889 | Leaf - Internet | Int to RAL | must | RAL (tgt) | 890 + +--------------+------------+----------------+ 891 | | RUL to Int | must | root | 892 + +--------------+------------+----------------+ 893 | | Int to RUL | must | 6LR | 894 +---------------------+--------------+------------+----------------+ 895 | | RAL to RAL | No | N/A | 896 | Leaf - Leaf +--------------+------------+----------------+ 897 | | RAL to RUL | No(up) | N/A | 898 | + +------------+----------------+ 899 | | | must(down) | 6LR | 900 | +--------------+------------+----------------+ 901 | | RUL to RAL | must(up) | root | 902 | | +------------+----------------+ 903 | | | must(down) | RAL | 904 | +--------------+------------+----------------+ 905 | | RUL to RUL | must(up) | root | 906 | | +------------+----------------+ 907 | | | must(down) | 6LR | 908 |---------------------+--------------+------------+----------------+ 910 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 912 7.1. Storing Mode: Interaction between Leaf and Root 914 In this section is described the communication flow in storing mode 915 (SM) between, 917 RAL to root 919 root to RAL 921 RUL to root 923 root to RUL 925 7.1.1. SM: Example of Flow from RAL to Root 927 In storing mode, RFC 6553 (RPI) is used to send RPL Information 928 instanceID and rank information. 930 In this case the flow comprises: 932 RAL (6LN) --> 6LR_i --> root(6LBR) 934 For example, a communication flow could be: Node F (6LN) --> Node D 935 (6LR_i) --> Node B (6LR_i)--> Node A root(6LBR) 937 The RAL (Node F) inserts the RPI, and sends the packet to 6LR (Node 938 D) which decrements the rank in the RPI and sends the packet up. 939 When the packet arrives at 6LBR (Node A), the RPI is removed and the 940 packet is processed. 942 No IPv6-in-IPv6 header is required. 944 The RPI can be removed by the 6LBR because the packet is addressed to 945 the 6LBR. The RAL must know that it is communicating with the 6LBR 946 to make use of this scenario. The RAL can know the address of the 947 6LBR because it knows the address of the root via the DODAGID in the 948 DIO messages. 950 The Figure 8 summarizes what headers are needed for this use case. 952 +-----------+-----+-------+------+ 953 | Header | RAL | 6LR_i | 6LBR | 954 | | src | | dst | 955 +-----------+-----+-------+------+ 956 | Added | RPI | -- | -- | 957 | headers | | | | 958 +-----------+-----+-------+------+ 959 | Modified | -- | RPI | -- | 960 | headers | | | | 961 +-----------+-----+-------+------+ 962 | Removed | -- | -- | RPI | 963 | headers | | | | 964 +-----------+-----+-------+------+ 965 | Untouched | -- | -- | -- | 966 | headers | | | | 967 +-----------+-----+-------+------+ 969 Figure 8: SM: Summary of the use of headers from RAL to root 971 7.1.2. SM: Example of Flow from Root to RAL 973 In this case the flow comprises: 975 root (6LBR) --> 6LR_i --> RAL (6LN) 977 For example, a communication flow could be: Node A root(6LBR) --> 978 Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN) 980 In this case the 6LBR inserts RPI and sends the packet down, the 6LR 981 is going to increment the rank in RPI (it examines the RPLInstanceID 982 to identify the right forwarding table), the packet is processed in 983 the RAL and the RPI removed. 985 No IPv6-in-IPv6 header is required. 987 The Figure 9 summarizes what headers are needed for this use case. 989 +-----------+------+-------+-----+ 990 | Header | 6LBR | 6LR_i | RAL | 991 | | src | | dst | 992 +-----------+------+-------+-----+ 993 | Added | RPI | -- | -- | 994 | headers | | | | 995 +-----------+------+-------+-----+ 996 | Modified | -- | RPI | -- | 997 | headers | | | | 998 +-----------+------+-------+-----+ 999 | Removed | -- | -- | RPI | 1000 | headers | | | | 1001 +-----------+------+-------+-----+ 1002 | Untouched | -- | -- | -- | 1003 | headers | | | | 1004 +-----------+------+-------+-----+ 1006 Figure 9: SM: Summary of the use of headers from root to RAL 1008 7.1.3. SM: Example of Flow from Root to RUL 1010 In this case the flow comprises: 1012 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1014 For example, a communication flow could be: Node A (6LBR) --> Node B 1015 (6LR_i) --> Node E (6LR_n) --> Node G (RUL) 1017 6LR_i (Node B) represents the intermediate routers from the source 1018 (6LBR) to the destination (RUL), 1 <= i <= n, where n is the total 1019 number of routers (6LR) that the packet goes through from the 6LBR 1020 (Node A) to the RUL (Node G). 1022 The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and 1023 prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR 1024 parent of the RUL (6LR_n). The 6LR parent of the RUL removes the 1025 header and sends the packet to the RUL. 1027 The Figure 10 summarizes what headers are needed for this use case. 1029 +-----------+---------+---------+---------+-----+ 1030 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1031 | | src | | | dst | 1032 +-----------+---------+---------+---------+-----+ 1033 | Added | IP6-IP6 | -- | -- | -- | 1034 | headers | RPI | | | | 1035 +-----------+---------+---------+---------+-----+ 1036 | Modified | -- | | -- | -- | 1037 | headers | | RPI | | | 1038 +-----------+---------+---------+---------+-----+ 1039 | Removed | -- | -- | IP6-IP6 | -- | 1040 | headers | | | RPI | | 1041 +-----------+---------+---------+---------+-----+ 1042 | Untouched | -- | IP6-IP6 | -- | -- | 1043 | headers | | | | | 1044 +-----------+---------+---------+---------+-----+ 1046 Figure 10: SM: Summary of the use of headers from root to RUL 1048 IP-in-IP encapsulation may be avoided for Root to RUL communication. 1049 In SM, it can be replaced by a loose RH3 header that indicates the 1050 RUL, in which case the packet is routed to the 6LR as a normal SM 1051 operation, then the 6LR forwards to the RUL based on the RH3, and the 1052 RUL ignores both the consumed RH3 and the RPI, as in Non-Storing 1053 Mode. 1055 The Figure 11 summarizes what headers are needed for this scenario. 1057 +-----------+----------+--------------+----------------+----------+ 1058 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1059 | | src | i=(1,..,n-1) | | dst | 1060 | | | | | | 1061 +-----------+----------+--------------+----------------+----------+ 1062 | Added | RPI, RH3 | -- | -- | -- | 1063 | headers | | | | | 1064 +-----------+----------+--------------+----------------+----------+ 1065 | Modified | -- | RPI | RPI | -- | 1066 | headers | | | RH3(consumed) | | 1067 +-----------+----------+--------------+----------------+----------+ 1068 | Removed | -- | -- | -- | -- | 1069 | headers | | | | | 1070 +-----------+----------+--------------+----------------+----------+ 1071 | Untouched | -- | RH3 | -- | RPI, RH3 | 1072 | headers | | | | (both | 1073 | | | | | ignored) | 1074 +-----------+----------+--------------+----------------+----------+ 1076 Figure 11: SM: Summary of the use of headers from root to RUL without 1077 encapsulation 1079 7.1.4. SM: Example of Flow from RUL to Root 1081 In this case the flow comprises: 1083 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) 1085 For example, a communication flow could be: Node G (RUL) --> Node E 1086 (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) 1088 6LR_i represents the intermediate routers from the source (RUL) to 1089 the destination (6LBR), 1 <= i <= n, where n is the total number of 1090 routers (6LR) that the packet goes through from the RUL to the 6LBR. 1092 When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the 1093 6LR_1 will encapsulate the packet in an IPv6-in-IPv6 header with an 1094 RPI. The IPv6-in-IPv6 header is addressed to the root (Node A). The 1095 root removes the header and processes the packet. 1097 The Figure 12 shows the table that summarizes what headers are needed 1098 for this use case where the IPv6-in-IPv6 header is addressed to the 1099 root (Node A). 1101 +-----------+------+--------------+----------------+-----------------+ 1102 | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | 1103 | | src | | | | 1104 | | node | | | | 1105 +-----------+------+--------------+----------------+-----------------+ 1106 | Added | -- | IP6-IP6 | | -- | 1107 | headers | | RPI | -- | | 1108 +-----------+------+--------------+----------------+-----------------+ 1109 | Modified | -- | -- | RPI | -- | 1110 | headers | | | | | 1111 +-----------+------+--------------+----------------+-----------------+ 1112 | Removed | -- | -- | --- | IP6-IP6 | 1113 | headers | | | | RPI | 1114 +-----------+------+--------------+----------------+-----------------+ 1115 | Untouched | -- | -- | IP6-IP6 | -- | 1116 | headers | | | | | 1117 +-----------+------+--------------+----------------+-----------------+ 1119 Figure 12: SM: Summary of the use of headers from RUL to root. 1121 7.2. SM: Interaction between Leaf and Internet. 1123 In this section is described the communication flow in storing mode 1124 (SM) between, 1126 RAL to Internet 1128 Internet to RAL 1130 RUL to Internet 1132 Internet to RUL 1134 7.2.1. SM: Example of Flow from RAL to Internet 1136 In this case the flow comprises: 1138 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 1140 For example, the communication flow could be: Node F (RAL) --> Node D 1141 (6LR_i)--> Node B (6LR_i)--> Node A root(6LBR) --> Internet 1143 6LR_i represents the intermediate routers from the source (RAL) to 1144 the root (6LBR), 1 <= i <= n, where n is the total number of routers 1145 (6LR) that the packet goes through from the RAL to the 6LBR. 1147 RPL information from RFC 6553 may go out to Internet as it will be 1148 ignored by nodes which have not been configured to be RPI aware. No 1149 IPv6-in-IPv6 header is required. 1151 On the other hand, the RAL may insert the RPI encapsulated in a IPv6- 1152 in-IPv6 header to the root. Thus, the root removes the RPI and send 1153 the packet to the Internet. 1155 Note: In this use case, it is used a node as a leaf, but this use 1156 case can be also applicable to any RPL-aware-node type (e.g. 6LR) 1158 The Figure 13 summarizes what headers are needed for this use case 1159 when there is no encapsulation. Note that the RPI is modified by 1160 6LBR to set the SenderRank to zero in case that it is not already 1161 zero. The Figure 14 summarizes what headers are needed when 1162 encapsulation to the root takes place. 1164 +-----------+-----+-------+------+-----------+ 1165 | Header | RAL | 6LR_i | 6LBR | Internet | 1166 | | src | | | dst | 1167 +-----------+-----+-------+------+-----------+ 1168 | Added | RPI | -- | -- | -- | 1169 | headers | | | | | 1170 +-----------+-----+-------+------+-----------+ 1171 | Modified | -- | RPI | RPI | -- | 1172 | headers | | | | | 1173 +-----------+-----+-------+------+-----------+ 1174 | Removed | -- | -- | -- | -- | 1175 | headers | | | | | 1176 +-----------+-----+-------+------+-----------+ 1177 | Untouched | -- | -- | -- | RPI | 1178 | headers | | | | (Ignored) | 1179 +-----------+-----+-------+------+-----------+ 1181 Figure 13: SM: Summary of the use of headers from RAL to Internet 1182 with no encapsulation 1184 +-----------+----------+--------------+--------------+--------------+ 1185 | Header | RAL | 6LR_i | 6LBR | Internet dst | 1186 | | src | | | | 1187 +-----------+----------+--------------+--------------+--------------+ 1188 | Added | IP6-IP6 | -- | -- | -- | 1189 | headers | RPI | | | | 1190 +-----------+----------+--------------+--------------+--------------+ 1191 | Modified | -- | RPI | -- | -- | 1192 | headers | | | | | 1193 +-----------+----------+--------------+--------------+--------------+ 1194 | Removed | -- | -- | IP6-IP6 | -- | 1195 | headers | | | RPI | | 1196 +-----------+----------+--------------+--------------+--------------+ 1197 | Untouched | -- | IP6-IP6 | -- | -- | 1198 | headers | | | | | 1199 +-----------+----------+--------------+--------------+--------------+ 1201 Figure 14: SM: Summary of the use of headers from RAL to Internet 1202 with encapsulation to the root (6LBR). 1204 7.2.2. SM: Example of Flow from Internet to RAL 1206 In this case the flow comprises: 1208 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 1210 For example, a communication flow could be: Internet --> Node A 1211 root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) 1213 When the packet arrives from Internet to 6LBR the RPI is added in a 1214 outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address 1215 set to the RAL) and sent to 6LR, which modifies the rank in the RPI. 1216 When the packet arrives at the RAL, the packet is decapsulated, which 1217 removes the RPI before the packet is processed. 1219 The Figure 15 shows the table that summarizes what headers are needed 1220 for this use case. 1222 +-----------+----------+--------------+--------------+--------------+ 1223 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1224 | | src | | | | 1225 +-----------+----------+--------------+--------------+--------------+ 1226 | Added | -- | IP6-IP6(RPI) | -- | -- | 1227 | headers | | | | | 1228 +-----------+----------+--------------+--------------+--------------+ 1229 | Modified | -- | -- | RPI | -- | 1230 | headers | | | | | 1231 +-----------+----------+--------------+--------------+--------------+ 1232 | Removed | -- | -- | -- | IP6-IP6(RPI) | 1233 | headers | | | | | 1234 +-----------+----------+--------------+--------------+--------------+ 1235 | Untouched | -- | -- | -- | -- | 1236 | headers | | | | | 1237 +-----------+----------+--------------+--------------+--------------+ 1239 Figure 15: SM: Summary of the use of headers from Internet to RAL. 1241 7.2.3. SM: Example of Flow from RUL to Internet 1243 In this case the flow comprises: 1245 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1247 For example, a communication flow could be: Node G (RUL)--> Node E 1248 (6LR_1)--> Node B (6lR_i) --> Node A root(6LBR) --> Internet 1250 The node 6LR_1 (i=1) will add an IPv6-in-IPv6(RPI) header addressed 1251 to the root such that the root can remove the RPI before passing 1252 upwards. In the intermediate 6LR, the rank in the RPI is modified. 1254 The originating node will ideally leave the IPv6 flow label as zero 1255 so that the packet can be better compressed through the LLN. The 1256 6LBR will set the flow label of the packet to a non-zero value when 1257 sending to the Internet, for details check [RFC6437]. 1259 The Figure 16 shows the table that summarizes what headers are needed 1260 for this use case. 1262 +---------+-------+------------+-------------+-------------+--------+ 1263 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1264 | | src | | [i=2,...,n] | | dst | 1265 | | node | | | | | 1266 | | (RUL) | | | | | 1267 +---------+-------+------------+-------------+-------------+--------+ 1268 | Added | -- |IP6-IP6(RPI)| -- | -- | -- | 1269 | headers | | | | | | 1270 +---------+-------+------------+-------------+-------------+--------+ 1271 | Modified| -- | -- | RPI | -- | -- | 1272 | headers | | | | | | 1273 +---------+-------+------------+-------------+-------------+--------+ 1274 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1275 | headers | | | | | | 1276 +---------+-------+------------+-------------+-------------+--------+ 1277 |Untouched| -- | -- | -- | -- | -- | 1278 | headers | | | | | | 1279 +---------+-------+------------+-------------+-------------+--------+ 1281 Figure 16: SM: Summary of the use of headers from RUL to Internet. 1283 7.2.4. SM: Example of Flow from Internet to RUL. 1285 In this case the flow comprises: 1287 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1289 For example, a communication flow could be: Internet --> Node A 1290 root(6LBR) --> Node B (6LR_i)--> Node E (6LR_n) --> Node G (RUL) 1292 The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The 1293 IPv6-in-IPv6 is addressed to the 6LR parent of the RUL. 1295 Further details about this are mentioned in 1296 [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN 1297 acting as a plain host and not being aware of RPL. 1299 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1300 zero in order to aid in compression [RFC8138][RFC6437]. 1302 The Figure 17 shows the table that summarizes what headers are needed 1303 for this use case. 1305 +---------+-------+------------+--------------+-------------+-------+ 1306 | Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL | 1307 | | net | |[i=1,..,n-1] | | dst | 1308 | | src | | | | | 1309 | | | | | | | 1310 +---------+-------+------------+--------------+-------------+-------+ 1311 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1312 | headers | | | | | | 1313 +---------+-------+------------+--------------+-------------+-------+ 1314 | Modified| -- | -- | RPI | -- | -- | 1315 | headers | | | | | | 1316 +---------+-------+------------+--------------+-------------+-------+ 1317 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1318 | headers | | | | | | 1319 +---------+-------+------------+--------------+-------------+-------+ 1320 |Untouched| -- | -- | -- | -- | -- | 1321 | headers | | | | | | 1322 +---------+-------+------------+--------------+-------------+-------+ 1324 Figure 17: SM: Summary of the use of headers from Internet to RUL. 1326 7.3. SM: Interaction between Leaf and Leaf 1328 In this section is described the communication flow in storing mode 1329 (SM) between, 1331 RAL to RAL 1333 RAL to RUL 1335 RUL to RAL 1337 RUL to RUL 1339 7.3.1. SM: Example of Flow from RAL to RAL 1341 In [RFC6550] RPL allows a simple one-hop optimization for both 1342 storing and non-storing networks. A node may send a packet destined 1343 to a one-hop neighbor directly to that node. See section 9 in 1344 [RFC6550]. 1346 When the nodes are not directly connected, then in storing mode, the 1347 flow comprises: 1349 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL 1350 dst (6LN) 1351 For example, a communication flow could be: Node F (RAL src)--> Node 1352 D (6LR_ia)--> Node B (6LR_x) --> Node E (6LR_id) --> Node H (RAL dst) 1354 6LR_ia (Node D) represents the intermediate routers from source to 1355 the common parent (6LR_x) (Node B), 1 <= ia <= n, where n is the 1356 total number of routers (6LR) that the packet goes through from RAL 1357 (Node F) to the common parent 6LR_x (Node B). 1359 6LR_id (Node E) represents the intermediate routers from the common 1360 parent (6LR_x) (Node B) to destination RAL (Node H), 1 <= id <= m, 1361 where m is the total number of routers (6LR) that the packet goes 1362 through from the common parent (6LR_x) to destination RAL (Node H). 1364 It is assumed that the two nodes are in the same RPL domain (that 1365 they share the same DODAG root). At the common parent (Node B), the 1366 direction flag ('O' flag) of the RPI is changed (from decreasing 1367 ranks to increasing ranks). 1369 While the 6LR nodes will update the RPI, no node needs to add or 1370 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1372 The Figure 18 summarizes what headers are needed for this use case. 1374 +-----------+-----+--------+---------+--------+-----+ 1375 | Header | RAL | 6LR_ia | 6LR_x | 6LR_id | RAL | 1376 | | src | | (common | | dst | 1377 | | | | parent) | | | 1378 +-----------+-----+--------+---------+--------+-----+ 1379 | Added | RPI | -- | -- | -- | -- | 1380 | headers | | | | | | 1381 +-----------+-----+--------+---------+--------+-----+ 1382 | Modified | -- | RPI | RPI | RPI | -- | 1383 | headers | | | | | | 1384 +-----------+-----+--------+---------+--------+-----+ 1385 | Removed | -- | -- | -- | -- | RPI | 1386 | headers | | | | | | 1387 +-----------+-----+--------+---------+--------+-----+ 1388 | Untouched | -- | -- | -- | -- | -- | 1389 | headers | | | | | | 1390 +-----------+-----+--------+---------+--------+-----+ 1392 Figure 18: SM: Summary of the Use of Headers from RAL to RAL 1394 7.3.2. SM: Example of Flow from RAL to RUL 1396 In this case the flow comprises: 1398 RAL src (6LN) --> 6LR_ia --> common parent (6LBR - The root-) --> 1399 6LR_id --> RUL (IPv6 dst node) 1401 For example, a communication flow could be: Node F (RAL)--> Node D 1402 --> Node B--> Node A -->Node B --> Node E --> Node G (RUL) 1404 6LR_ia represents the intermediate routers from source (RAL) to the 1405 common parent (the Root), 1 <= ia <= n, where n is the total number 1406 of routers (6LR) that the packet goes through from RAL to the Root. 1408 6LR_id (Node E) represents the intermediate routers from the Root 1409 (Node B) to destination RUL (Node G). In this case, 1 <= id <= m, 1410 where m is the total number of routers (6LR) that the packet goes 1411 through from the Root down to the destination RUL. 1413 In this case, the packet from the RAL goes to 6LBR because the route 1414 to the RUL is not injected into the RPL-SM. Thus, the RAL inserts an 1415 RPI (RPI1) addressed to the root(6LBR). The root does not remove the 1416 RPI1 (the root cannot remove an RPI if there is no encapsulation). 1417 The root inserts an IPv6-IPv6 encapsulation with an RPI2 and sends it 1418 to the 6LR parent of the RUL, which removes the encapsulation and 1419 RPI2 before passing the packet to the RUL. 1421 The Figure 19 summarizes what headers are needed for this use case. 1423 +----------+-------+-------+---------+---------+---------+---------+ 1424 | Header | RAL |6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 1425 | | src | | | | | dst | 1426 | | node | | | | | node | 1427 +----------+-------+-------+---------+---------+---------+---------+ 1428 | Added | | | IP6-IP6 | -- | -- | -- | 1429 | headers | RPI1 | -- | (RPI2) | | | | 1430 | | | | | | | | 1431 +----------+-------+-------+---------+---------+---------+---------+ 1432 | Modified | -- | | -- | | | -- | 1433 | headers | | RPI1 | | RPI2 | -- | | 1434 | | | | | | | | 1435 +----------+-------+-------+---------+---------+---------+---------+ 1436 | Removed | -- | -- | | -- | IP6-IP6 | -- | 1437 | headers | | | -- | | (RPI2) | | 1438 | | | | | | | | 1439 +----------+-------+-------+---------+---------+---------+---------+ 1440 |Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 1441 | headers | | | | | |(Ignored)| 1442 | | | | | | | | 1443 +----------+-------+-------+---------+---------+---------+---------+ 1445 Figure 19: SM: Summary of the Use of Headers from RAL to RUL 1447 7.3.3. SM: Example of Flow from RUL to RAL 1449 In this case the flow comprises: 1451 RUL (IPv6 src node) --> 6LR_ia --> 6LBR --> 6LR_id --> RAL dst (6LN) 1453 For example, a communication flow could be: Node G (RUL)--> Node E 1454 --> Node B --> Node A --> Node B --> Node D --> Node F (RAL) 1456 6LR_ia (Node E) represents the intermediate routers from source (RUL) 1457 (Node G) to the root (Node A). In this case, 1 <= ia <= n, where n 1458 is the total number of routers (6LR) that the packet goes through 1459 from source to the root. 1461 6LR_id represents the intermediate routers from the root (Node A) to 1462 destination RAL (Node F). In this case, 1 <= id <= m, where m is the 1463 total number of routers (6LR) that the packet goes through from the 1464 root to the destination RAL. 1466 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1467 inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to the 1468 root. The root removes the outer header including the RPI (RPI1) and 1469 inserts a new RPI (RPI2) addressed to the destination RAL (Node F). 1471 The Figure 20 shows the table that summarizes what headers are needed 1472 for this use case. 1474 +-----------+------+---------+---------+---------+---------+---------+ 1475 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 1476 | | src | | | | | dst | 1477 | | node | | | | | node | 1478 +-----------+------+---------+---------+---------+---------+---------+ 1479 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1480 | headers | | (RPI1) | | (RPI2) | | | 1481 | | | | | | | | 1482 +-----------+------+---------+---------+---------+---------+---------+ 1483 | Modified | -- | | | -- | | -- | 1484 | headers | | -- | RPI1 | | RPI2 | | 1485 | | | | | | | | 1486 +-----------+------+---------+---------+---------+---------+---------+ 1487 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1488 | headers | | -- | | (RPI1) | | (RPI2) | 1489 | | | | | | | | 1490 +-----------+------+---------+---------+---------+---------+---------+ 1491 | Untouched | -- | -- | -- | -- | -- | -- | 1492 | headers | | | | | | | 1493 +-----------+------+---------+---------+---------+---------+---------+ 1495 Figure 20: SM: Summary of the use of headers from RUL to RAL. 1497 7.3.4. SM: Example of Flow from RUL to RUL 1499 In this case the flow comprises: 1501 RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> RUL 1502 (IPv6 dst node) 1504 For example, a communication flow could be: Node G (RUL src)--> Node 1505 E --> Node B --> Node A (root) --> Node C --> Node J (RUL dst) 1507 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1508 router from the RUL source (Node G) to the root (6LBR) (Node A). In 1509 this case, 1 <= ia <= n, where n is the total number of routers (6LR) 1510 that the packet goes through from the RUL to the root. 6LR_1 refers 1511 when ia=1. 1513 6LR_id (Node C) represents the intermediate routers from the root 1514 (Node A) to the destination RUL dst node (Node J). In this case, 1 1515 <= id <= m, where m is the total number of routers (6LR) that the 1516 packet goes through from the root to destination RUL. 1518 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1519 inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header 1520 directed to the root. The root removes the outer header including 1521 the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR 1522 father of the RUL. 1524 The Figure 21 shows the table that summarizes what headers are needed 1525 for this use case. 1527 +---------+----+-------------+--------+---------+--------+-------+---+ 1528 | Header |RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id |6LR_n |RUL| 1529 | |src | | | | | |dst| 1530 | | | | | | | | | 1531 +---------+----+-------------+--------+---------+--------+-------+---+ 1532 | Added | -- |IP6-IP6(RPI1)| -- | IP6-IP6 | -- | -- | --| 1533 | Headers | | | | (RPI2) | | | | 1534 +---------+----+-------------+--------+---------+--------+-------+---+ 1535 |Modified | -- | -- | | -- | | -- | --| 1536 |headers | | | RPI1 | | RPI2 | | | 1537 +---------+----+-------------+--------+---------+--------+-------+---+ 1538 | Removed | -- | -- | -- | IP6-IP6 | -- |IP6-IP6| --| 1539 | headers | | | | (RPI1) | | (RPI2)| | 1540 +---------+----+-------------+--------+---------+--------+-------+---+ 1541 |Untouched| -- | -- | -- | -- | -- | -- | --| 1542 | headers | | | | | | | | 1543 +---------+----+-------------+--------+---------+--------+-------+---+ 1545 Figure 21: SM: Summary of the use of headers from RUL to RUL 1547 8. Non Storing mode 1549 In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG 1550 root) has complete knowledge about the connectivity of all DODAG 1551 nodes, and all traffic flows through the root node. Thus, there is 1552 no need for all nodes to know about the existence of RPL-unaware 1553 nodes. Only the 6LBR needs to act if compensation is necessary for 1554 not-RPL aware receivers. 1556 The table (Figure 22) summarizes what headers are needed in the 1557 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 1558 header are to be inserted. The last column depicts the target 1559 destination of the IPv6-in-IPv6 header: 6LN (indicated by "RAL"), 6LR 1560 (parent of a RUL) or the root. In cases where no IPv6-in-IPv6 header 1561 is needed, the column indicates "No". There is no expectation on RPL 1562 that RPI can be omitted, because it is needed for routing, quality of 1563 service and compression. This specification expects that an RPI is 1564 always present. The term "may(up)" means that the IPv6-in-IPv6 1565 header may be necessary in the upwards direction. The term 1566 "must(up)" means that the IPv6-in-IPv6 header must be present in the 1567 upwards direction. The term "must(down)" means that the IPv6-in-IPv6 1568 header must be present in the downward direction. 1570 The leaf can be a router 6LR or a host, both indicated as 6LN 1571 (Figure 6). In the table (Figure 22) the (1) indicates a 6tisch case 1572 [RFC8180], where the RPI may still be needed for the RPLInstanceID to 1573 be available for priority/channel selection at each hop. 1575 +--- ------------+-------------+-----+-----+--------------+----------+ 1576 | Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP | 1577 | between | | | | | dst | 1578 +----------------+-------------+-----+-----+--------------+----------+ 1579 | | RAL to root | Yes | No | No | No | 1580 | +-------------+-----+-----+--------------+----------+ 1581 | Leaf - Root | root to RAL | Yes | Yes | No | No | 1582 | +-------------+-----+-----+--------------+----------+ 1583 | | root to RUL | Yes | Yes | No | 6LR | 1584 | | | (1) | | | | 1585 | +-------------+-----+-----+--------------+----------+ 1586 | | RUL to root | Yes | No | must | root | 1587 +----------------+-------------+-----+-----+--------------+----------+ 1588 | | RAL to Int | Yes | No | may(up) | root | 1589 | +-------------+-----+-----+--------------+----------+ 1590 |Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | 1591 | +-------------+-----+-----+--------------+----------+ 1592 | | RUL to Int | Yes | No | must | root | 1593 | +-------------+-----+-----+--------------+----------+ 1594 | | Int to RUL | Yes | Yes | must | 6LR | 1595 +----------------+-------------+-----+-----+--------------+----------+ 1596 | | RAL to RAL | Yes | Yes | may(up) | root | 1597 | | | | +--------------+----------+ 1598 | | | | | must(down) | RAL | 1599 | Leaf - Leaf +-------------+-----+-----+--------------+----------+ 1600 | | RAL to RUL | Yes | Yes | may(up) | root | 1601 | | | | +--------------+----------+ 1602 | | | | | must(down) | 6LR | 1603 | +-------------+-----+-----+--------------+----------+ 1604 | | RUL to RAL | Yes | Yes | must(up) | root | 1605 | | | | +--------------+----------+ 1606 | | | | | must(down) | RAL | 1607 | +-------------+-----+-----+--------------+----------+ 1608 | | RUL to RUL | Yes | Yes | must(up) | root | 1609 | | | | +--------------+----------+ 1610 | | | | | must(down) | 6LR | 1611 +----------------+-------------+-----+-----+--------------+----------+ 1613 Figure 22: Table that shows headers needed in Non-Storing mode: RPI, 1614 RH3, IPv6-in-IPv6 encapsulation. 1616 8.1. Non-Storing Mode: Interaction between Leaf and Root 1618 In this section is described the communication flow in Non Storing 1619 Mode (Non-SM) between, 1621 RAL to root 1623 root to RAL 1625 RUL to root 1627 root to RUL 1629 8.1.1. Non-SM: Example of Flow from RAL to root 1631 In non-storing mode the leaf node uses default routing to send 1632 traffic to the root. The RPI must be included since it contains the 1633 rank information, which is used to avoid/detect loops. 1635 RAL (6LN) --> 6LR_i --> root(6LBR) 1637 For example, a communication flow could be: Node F --> Node D --> 1638 Node B --> Node A (root) 1640 6LR_i represents the intermediate routers from source to destination. 1641 In this case, 1 <= i <= n, where n is the total number of routers 1642 (6LR) that the packet goes through from source (RAL) to destination 1643 (6LBR). 1645 This situation is the same case as storing mode. 1647 The Figure 23 summarizes what headers are needed for this use case. 1649 +-----------+-----+-------+------+ 1650 | Header | RAL | 6LR_i | 6LBR | 1651 | | src | | dst | 1652 +-----------+-----+-------+------+ 1653 | Added | RPI | -- | -- | 1654 | headers | | | | 1655 +-----------+-----+-------+------+ 1656 | Modified | -- | RPI | -- | 1657 | headers | | | | 1658 +-----------+-----+-------+------+ 1659 | Removed | -- | -- | RPI | 1660 | headers | | | | 1661 +-----------+-----+-------+------+ 1662 | Untouched | -- | -- | -- | 1663 | headers | | | | 1664 +-----------+-----+-------+------+ 1666 Figure 23: Non-SM: Summary of the use of headers from RAL to root 1668 8.1.2. Non-SM: Example of Flow from root to RAL 1670 In this case the flow comprises: 1672 root (6LBR) --> 6LR_i --> RAL (6LN) 1674 For example, a communication flow could be: Node A (root) --> Node B 1675 --> Node D --> Node F 1677 6LR_i represents the intermediate routers from source to destination. 1678 In this case, 1 <= i <= n, where n is the total number of routers 1679 (6LR) that the packet goes through from source (6LBR) to destination 1680 (RAL). 1682 The 6LBR inserts an RH3, and an RPI. No IPv6-in-IPv6 header is 1683 necessary as the traffic originates with a RPL aware node, the 6LBR. 1684 The destination is known to be RPL-aware because the root knows the 1685 whole topology in non-storing mode. 1687 The Figure 24 summarizes what headers are needed for this use case. 1689 +-----------+----------+----------+----------+ 1690 | Header | 6LBR | 6LR_i | RAL | 1691 | | src | | dst | 1692 +-----------+----------+----------+----------+ 1693 | Added | RPI, RH3 | -- | -- | 1694 | headers | | | | 1695 +-----------+----------+----------+----------+ 1696 | Modified | -- | RPI, RH3 | -- | 1697 | headers | | | | 1698 +-----------+----------+----------+----------+ 1699 | Removed | -- | -- | RPI, RH3 | 1700 | headers | | | | 1701 +-----------+----------+----------+----------+ 1702 | Untouched | -- | -- | -- | 1703 | headers | | | | 1704 +-----------+----------+----------+----------+ 1706 Figure 24: Non-SM: Summary of the use of headers from root to RAL 1708 8.1.3. Non-SM: Example of Flow from root to RUL 1710 In this case the flow comprises: 1712 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1714 For example, a communication flow could be: Node A (root) --> Node B 1715 --> Node E --> Node G (RUL) 1717 6LR_i represents the intermediate routers from source to destination. 1718 In this case, 1 <= i <= n, where n is the total number of routers 1719 (6LR) that the packet goes through from source (6LBR) to destination 1720 (RUL). 1722 In the 6LBR, the RH3 is added; it is then modified at each 1723 intermediate 6LR (6LR_1 and so on), and it is fully consumed in the 1724 last 6LR (6LR_n) but is left in place. When the RPI is added, the 1725 RUL, which does not understand the RPI, will ignore it (per 1726 [RFC8200]); thus, encapsulation is not necessary. 1728 The Figure 25 depicts the table that summarizes what headers are 1729 needed for this use case. 1731 +-----------+----------+--------------+----------------+----------+ 1732 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1733 | | src | i=(1,..,n-1) | | dst | 1734 | | | | | | 1735 +-----------+----------+--------------+----------------+----------+ 1736 | Added | RPI, RH3 | -- | -- | -- | 1737 | headers | | | | | 1738 +-----------+----------+--------------+----------------+----------+ 1739 | Modified | -- | RPI, RH3 | RPI, | -- | 1740 | headers | | | RH3(consumed) | | 1741 +-----------+----------+--------------+----------------+----------+ 1742 | Removed | -- | -- | -- | -- | 1743 | headers | | | | | 1744 +-----------+----------+--------------+----------------+----------+ 1745 | Untouched | -- | -- | -- | RPI, RH3 | 1746 | headers | | | | (both | 1747 | | | | | ignored) | 1748 +-----------+----------+--------------+----------------+----------+ 1750 Figure 25: Non-SM: Summary of the use of headers from root to RUL 1752 8.1.4. Non-SM: Example of Flow from RUL to root 1754 In this case the flow comprises: 1756 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst 1758 For example, a communication flow could be: Node G --> Node E --> 1759 Node B --> Node A (root) 1761 6LR_i represents the intermediate routers from source to destination. 1762 In this case, 1 <= i <= n, where n is the total number of routers 1763 (6LR) that the packet goes through from source (RUL) to destination 1764 (6LBR). For example, 6LR_1 (i=1) is the router that receives the 1765 packets from the RUL. 1767 In this case, the RPI is added by the first 6LR (6LR_1) (Node E), 1768 encapsulated in an IPv6-in-IPv6 header, and modified in the 1769 subsequent 6LRs in the flow. The RPI and the entire packet are 1770 consumed by the root. 1772 The Figure 26 shows the table that summarizes what headers are needed 1773 for this use case. 1775 +---------+----+-----------------+-----------------+-----------------+ 1776 | |RUL | | | | 1777 | Header |src | 6LR_1 | 6LR_i | 6LBR dst | 1778 | |node| | | | 1779 +---------+----+-----------------+-----------------+-----------------+ 1780 | Added | -- |IPv6-in-IPv6(RPI)| -- | -- | 1781 | headers | | | | | 1782 +---------+----+-----------------+-----------------+-----------------+ 1783 | Modified| -- | -- | RPI | -- | 1784 | headers | | | | | 1785 +---------+----+-----------------+-----------------+-----------------+ 1786 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1787 | headers | | | | | 1788 +---------+----+-----------------+-----------------+-----------------+ 1789 |Untouched| -- | -- | -- | -- | 1790 | headers | | | | | 1791 +---------+----+-----------------+-----------------+-----------------+ 1793 Figure 26: Non-SM: Summary of the use of headers from RUL to root 1795 8.2. Non-Storing Mode: Interaction between Leaf and Internet 1797 This section will describe the communication flow in Non Storing Mode 1798 (Non-SM) between: 1800 RAL to Internet 1802 Internet to RAL 1804 RUL to Internet 1806 Internet to RUL 1808 8.2.1. Non-SM: Example of Flow from RAL to Internet 1810 In this case the flow comprises: 1812 RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst 1814 For example, a communication flow could be: Node F (RAL) --> Node D 1815 --> Node B --> Node A --> Internet. Having the RAL information about 1816 the RPL domain, the packet may be encapsulated to the root when the 1817 destination is not in the RPL domain of the RAL. 1819 6LR_i represents the intermediate routers from source to destination, 1820 1 <= i <= n, where n is the total number of routers (6LR) that the 1821 packet goes through from source (RAL) to 6LBR. 1823 In this case, the encapsulation from the RAL to the root is optional. 1824 The simplest case is when the RPI gets to the Internet (as the 1825 Figure 27 shows it), knowing that the Internet is going to ignore it. 1827 The IPv6 flow label should be set to zero to aid in compression 1828 [RFC8138], and the 6LBR will set it to a non-zero value when sending 1829 towards the Internet [RFC6437]. 1831 The Figure 27 summarizes what headers are needed for this use case 1832 when no encapsulation is used. The Figure 28 summarizes what headers 1833 are needed for this use case when encapsulation to the root is used. 1835 +-----------+-----+-------+------+-----------+ 1836 | Header | RAL | 6LR_i | 6LBR | Internet | 1837 | | src | | | dst | 1838 +-----------+-----+-------+------+-----------+ 1839 | Added | RPI | -- | -- | -- | 1840 | headers | | | | | 1841 +-----------+-----+-------+------+-----------+ 1842 | Modified | -- | RPI | RPI | -- | 1843 | headers | | | | | 1844 +-----------+-----+-------+------+-----------+ 1845 | Removed | -- | -- | -- | -- | 1846 | headers | | | | | 1847 +-----------+-----+-------+------+-----------+ 1848 | Untouched | -- | -- | -- | RPI | 1849 | headers | | | | (Ignored) | 1850 +-----------+-----+-------+------+-----------+ 1852 Figure 27: Non-SM: Summary of the use of headers from RAL to Internet 1853 with no encapsulation 1855 +-----------+--------------+--------------+--------------+----------+ 1856 | Header | RAL | 6LR_i | 6LBR | Internet | 1857 | | src | | | dst | 1858 +-----------+--------------+--------------+--------------+----------+ 1859 | Added | IPv6-in-IPv6 | -- | -- | -- | 1860 | headers | (RPI) | | | | 1861 +-----------+--------------+--------------+--------------+----------+ 1862 | Modified | -- | | -- | -- | 1863 | headers | | RPI | | | 1864 +-----------+--------------+--------------+--------------+----------+ 1865 | Removed | -- | -- | IPv6-in-IPv6 | -- | 1866 | headers | | | (RPI) | | 1867 +-----------+--------------+--------------+--------------+----------+ 1868 | Untouched | -- | -- | -- | -- | 1869 | headers | | | | | 1870 +-----------+--------------+--------------+--------------+----------+ 1872 Figure 28: Non-SM: Summary of the use of headers from RAL to Internet 1873 with encapsulation to the root 1875 8.2.2. Non-SM: Example of Flow from Internet to RAL 1877 In this case the flow comprises: 1879 Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN) 1881 For example, a communication flow could be: Internet --> Node A 1882 (root) --> Node B --> Node D --> Node F (RAL) 1884 6LR_i represents the intermediate routers from source to destination, 1885 1 <= i <= n, where n is the total number of routers (6LR) that the 1886 packet goes through from 6LBR to destination (RAL). 1888 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1889 address of the target node, it can address the IPv6-in-IPv6 header to 1890 that node. The 6LBR will zero the flow label upon entry in order to 1891 aid compression [RFC8138]. 1893 The Figure 29 summarizes what headers are needed for this use case. 1895 +-----------+----------+--------------+--------------+--------------+ 1896 | Header | Internet | 6LBR | 6LR_i | RAL | 1897 | | src | | | dst | 1898 +-----------+----------+--------------+--------------+--------------+ 1899 | Added | -- | IPv6-in-IPv6 | -- | -- | 1900 | headers | | (RH3, RPI) | | | 1901 +-----------+----------+--------------+--------------+--------------+ 1902 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1903 | headers | | | (RH3, RPI) | | 1904 +-----------+----------+--------------+--------------+--------------+ 1905 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1906 | headers | | | | (RH3, RPI) | 1907 +-----------+----------+--------------+--------------+--------------+ 1908 | Untouched | -- | -- | -- | -- | 1909 | headers | | | | | 1910 +-----------+----------+--------------+--------------+--------------+ 1912 Figure 29: Non-SM: Summary of the use of headers from Internet to RAL 1914 8.2.3. Non-SM: Example of Flow from RUL to Internet 1916 In this case the flow comprises: 1918 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1919 dst 1921 For example, a communication flow could be: Node G --> Node E --> 1922 Node B --> Node A --> Internet 1924 6LR_i represents the intermediate routers from source to destination, 1925 1 <= i <= n, where n is the total number of routers (6LRs) that the 1926 packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1 1927 (i=1). 1929 In this case the flow label is recommended to be zero in the RUL. As 1930 the RUL parent adds RPL headers in the RUL packet, the first 6LR 1931 (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6- 1932 in-IPv6 header will be addressed to the root. This case is identical 1933 to the storing-mode case (see Section 7.2.3). 1935 The Figure 30 shows the table that summarizes what headers are needed 1936 for this use case. 1938 +---------+----+-------------+--------------+--------------+--------+ 1939 | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| 1940 | |src | | [i=2,..,n] | | dst | 1941 | |node| | | | | 1942 +---------+----+-------------+--------------+--------------+--------+ 1943 | Added | -- |IP6-IP6(RPI) | -- | -- | -- | 1944 | headers | | | | | | 1945 +---------+----+-------------+--------------+--------------+--------+ 1946 | Modified| -- | -- | RPI | -- | -- | 1947 | headers | | | | | | 1948 +---------+----+-------------+--------------+--------------+--------+ 1949 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1950 | headers | | | | | | 1951 +---------+----+-------------+--------------+--------------+--------+ 1952 |Untouched| -- | -- | -- | -- | -- | 1953 | headers | | | | | | 1954 +---------+----+-------------+--------------+--------------+--------+ 1956 Figure 30: Non-SM: Summary of the use of headers from RUL to Internet 1958 8.2.4. Non-SM: Example of Flow from Internet to RUL 1960 In this case the flow comprises: 1962 Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1964 For example, a communication flow could be: Internet --> Node A 1965 (root) --> Node B --> Node E --> Node G 1967 6LR_i represents the intermediate routers from source to destination, 1968 1 <= i <= n, where n is the total number of routers (6LR) that the 1969 packet goes through from 6LBR to RUL. 1971 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1972 6LBR will know the path, and will recognize that the final node is 1973 not a RPL capable node as it will have received the connectivity DAO 1974 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1975 header destination be the last 6LR. The 6LBR will set to zero the 1976 flow label upon entry in order to aid compression [RFC8138]. 1978 The Figure 31 shows the table that summarizes what headers are needed 1979 for this use case. 1981 +----------+--------+------------------+-----------+-----------+-----+ 1982 | Header |Internet| 6LBR | 6LR_i | 6LR_n | RUL | 1983 | | src | | | | dst | 1984 +----------+--------+------------------+-----------+-----------+-----+ 1985 | Added | -- | IP6-IP6(RH3,RPI) | -- | -- | -- | 1986 | headers | | | | | | 1987 +----------+--------+------------------+-----------+-----------+-----+ 1988 | Modified | -- | -- | IP6-IP6 | -- | -- | 1989 | headers | | | (RH3,RPI) | | | 1990 +----------+--------+------------------+-----------+-----------+-----+ 1991 | Removed | -- | -- | -- | IP6-IP6 | -- | 1992 | headers | | | | (RH3,RPI) | | 1993 +----------+--------+------------------+-----------+-----------+-----+ 1994 |Untouched | -- | -- | -- | -- | -- | 1995 | headers | | | | | | 1996 +----------+--------+------------------+-----------+-----------+-----+ 1998 Figure 31: Non-SM: Summary of the use of headers from Internet to 1999 RUL. 2001 8.3. Non-SM: Interaction between leaves 2003 In this section is described the communication flow in Non Storing 2004 Mode (Non-SM) between, 2006 RAL to RAL 2008 RAL to RUL 2010 RUL to RAL 2012 RUL to RUL 2014 8.3.1. Non-SM: Example of Flow from RAL to RAL 2016 In this case the flow comprises: 2018 RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst 2020 For example, a communication flow could be: Node F (RAL src)--> Node 2021 D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL 2022 dst) 2024 6LR_ia represents the intermediate routers from source to the root, 1 2025 <= ia <= n, where n is the total number of routers (6LR) that the 2026 packet goes through from RAL to the root. 2028 6LR_id represents the intermediate routers from the root to the 2029 destination, 1 <= id <= m, where m is the total number of the 2030 intermediate routers (6LR). 2032 This case involves only nodes in same RPL domain. The originating 2033 node will add an RPI to the original packet, and send the packet 2034 upwards. 2036 The originating node may put the RPI (RPI1) into an IPv6-in-IPv6 2037 header addressed to the root, so that the 6LBR can remove that 2038 header. If it does not, then the RPI1 is forwarded down from the 2039 root in the inner header to no avail. 2041 The 6LBR will need to insert an RH3 header, which requires that it 2042 add an IPv6-in-IPv6 header. It removes the RPI(RPI1), as it was 2043 contained in an IPv6-in-IPv6 header addressed to it. Otherwise, 2044 there may be an RPI buried inside the inner IP header, which should 2045 get ignored. The root inserts an RPI (RPI2) alongside the RH3. 2047 Networks that use the RPL P2P extension [RFC6997] are essentially 2048 non-storing DODAGs and fall into this scenario or scenario 2049 Section 8.1.2, with the originating node acting as 6LBR. 2051 The Figure 32 shows the table that summarizes what headers are needed 2052 for this use case when encapsulation to the root takes place. 2054 The Figure 33 shows the table that summarizes what headers are needed 2055 for this use case when there is no encapsulation to the root. Note 2056 that in the Modified headers row, going up in each 6LR_ia only the 2057 RPI1 is changed. Going down, in each 6LR_id the IPv6 header is 2058 swapped with the RH3 so both are changed alongside with the RPI2. 2060 +---------+-------+----------+------------+----------+------------+ 2061 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 2062 | | src | | | | dst | 2063 +---------+-------+----------+------------+----------+------------+ 2064 | Added |IP6-IP6| | IP6-IP6 | -- | -- | 2065 | headers |(RPI1) | -- |(RH3-> RAL, | | | 2066 | | | | RPI2) | | | 2067 +---------+-------+----------+------------+----------+------------+ 2068 | Modified| -- | | -- | IP6-IP6 | -- | 2069 | headers | | RPI1 | |(RH3,RPI2)| | 2070 +---------+-------+----------+------------+----------+------------+ 2071 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | 2072 | headers | | | (RPI1) | | (RH3, | 2073 | | | | | | RPI2) | 2074 +---------+-------+----------+------------+----------+------------+ 2075 |Untouched| -- | -- | -- | -- | -- | 2076 | headers | | | | | | 2077 +---------+-------+----------+------------+----------+------------+ 2079 Figure 32: Non-SM: Summary of the Use of Headers from RAL to RAL with 2080 encapsulation to the root. 2082 +-----------+------+--------+---------+---------+---------+ 2083 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 2084 +-----------+------+--------+---------+---------+---------+ 2085 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | 2086 | headers | | | (RH3, | | | 2087 | | | | RPI2) | | | 2088 +-----------+------+--------+---------+---------+---------+ 2089 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | 2090 | headers | | | | (RH3, | | 2091 | | | | | RPI2) | | 2092 +-----------+------+--------+---------+---------+---------+ 2093 | Removed | -- | -- | -- | -- | IP6-IP6 | 2094 | headers | | | | | (RH3, | 2095 | | | | | | RPI2) | 2096 | | | | | | | 2097 +-----------+------+--------+---------+---------+---------+ 2098 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | 2099 | headers | | | | |(Ignored)| 2100 +-----------+------+--------+---------+---------+---------+ 2102 Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL 2103 without encapsulation to the root. 2105 8.3.2. Non-SM: Example of Flow from RAL to RUL 2107 In this case the flow comprises: 2109 RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node) 2111 For example, a communication flow could be: Node F (RAL) --> Node D 2112 --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL) 2114 6LR_ia represents the intermediate routers from source to the root, 1 2115 <= ia <= n, where n is the total number of intermediate routers (6LR) 2117 6LR_id represents the intermediate routers from the root to the 2118 destination, 1 <= id <= m, where m is the total number of the 2119 intermediate routers (6LRs). 2121 As in the previous case, the RAL (6LN) may insert an RPI (RPI1) 2122 header which must be in an IPv6-in-IPv6 header addressed to the root 2123 so that the 6LBR can remove this RPI. The 6LBR will then insert an 2124 RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id 2125 (6LR_id = m) alongside the insertion of RPI2. 2127 If the originating node does not put the RPI (RPI1) into an IPv6-in- 2128 IPv6 header addressed to the root. Then, the RPI1 is forwarded down 2129 from the root in the inner header to no avail. 2131 The Figure 34 shows the table that summarizes what headers are needed 2132 for this use case when encapsulation to the root takes place. The 2133 Figure 35 shows the table that summarizes what headers are needed for 2134 this use case when no encapsulation to the root takes place. 2136 +-----------+---------+---------+---------+---------+---------+------+ 2137 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 2138 | | src | | | | | dst | 2139 | | node | | | | | node | 2140 +-----------+---------+---------+---------+---------+---------+------+ 2141 | Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 2142 | headers | (RPI1) | -- | (RH3, | | | | 2143 | | | | RPI2) | | | | 2144 +-----------+---------+---------+---------+---------+---------+------+ 2145 | Modified | -- | | -- | IP6-IP6 | | -- | 2146 | headers | | RPI1 | | (RH3, | -- | | 2147 | | | | | RPI2) | | | 2148 +-----------+---------+---------+---------+---------+---------+------+ 2149 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2150 | headers | | | (RPI1) | | (RH3, | | 2151 | | | | | | RPI2) | | 2152 +-----------+---------+---------+---------+---------+---------+------+ 2153 | Untouched | -- | -- | -- | -- | -- | -- | 2154 | headers | | | | | | | 2155 +-----------+---------+---------+---------+---------+---------+------+ 2157 Figure 34: Non-SM: Summary of the use of headers from RAL to RUL with 2158 encapsulation to the root. 2160 +-----------+------+--------+---------+---------+---------+---------+ 2161 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL | 2162 | | src | | | | | dst | 2163 | | node | | | | | node | 2164 +-----------+------+--------+---------+---------+---------+---------+ 2165 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | -- | 2166 | headers | | | (RH3, | | | | 2167 | | | | RPI2) | | | | 2168 +-----------+------+--------+---------+---------+---------+---------+ 2169 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- | 2170 | headers | | | | (RH3, | | | 2171 | | | | | RPI2) | | | 2172 +-----------+------+--------+---------+---------+---------+---------+ 2173 | Removed | -- | -- | -- | -- | IP6-IP6 | -- | 2174 | headers | | | | | (RH3, | | 2175 | | | | | | RPI2) | | 2176 +-----------+------+--------+---------+---------+---------+---------+ 2177 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 2178 | headers | | | | | |(Ignored)| 2179 +-----------+------+--------+---------+---------+---------+---------+ 2181 Figure 35: Non-SM: Summary of the use of headers from RAL to RUL 2182 without encapsulation to the root. 2184 8.3.3. Non-SM: Example of Flow from RUL to RAL 2186 In this case the flow comprises: 2188 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2189 --> RAL dst (6LN) 2191 For example, a communication flow could be: Node G (RUL)--> Node E 2192 --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL) 2194 6LR_ia represents the intermediate routers from source to the root, 1 2195 <= ia <= n, where n is the total number of intermediate routers (6LR) 2197 6LR_id represents the intermediate routers from the root to the 2198 destination, 1 <= id <= m, where m is the total number of the 2199 intermediate routers (6LR). 2201 In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1) 2202 inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will 2203 remove this RPI, and add its own IPv6-in-IPv6 header containing an 2204 RH3 header and an RPI (RPI2). 2206 The Figure 36 shows the table that summarizes what headers are needed 2207 for this use case. 2209 +----------+------+---------+---------+---------+---------+---------+ 2210 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 2211 | | src | | | | | dst | 2212 | | node | | | | | node | 2213 +----------+------+---------+---------+---------+---------+---------+ 2214 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 2215 | headers | | (RPI1) | | (RH3, | | | 2216 | | | | | RPI2) | | | 2217 +----------+------+---------+---------+---------+---------+---------+ 2218 | Modified | -- | | | -- | IP6-IP6 | -- | 2219 | headers | | -- | RPI1 | | (RH3, | | 2220 | | | | | | RPI2) | | 2221 +----------+------+---------+---------+---------+---------+---------+ 2222 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 2223 | headers | | -- | | (RPI1) | | (RH3, | 2224 | | | | | | | RPI2) | 2225 +----------+------+---------+---------+---------+---------+---------+ 2226 |Untouched | -- | -- | -- | -- | -- | -- | 2227 | headers | | | | | | | 2228 +----------+------+---------+---------+---------+---------+---------+ 2230 Figure 36: Non-SM: Summary of the use of headers from RUL to RAL. 2232 8.3.4. Non-SM: Example of Flow from RUL to RUL 2234 In this case the flow comprises: 2236 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2237 --> RUL (IPv6 dst node) 2239 For example, a communication flow could be: Node G --> Node E --> 2240 Node B --> Node A (root) --> Node C --> Node J 2242 6LR_ia represents the intermediate routers from source to the root, 1 2243 <= ia <= n, where n is the total number of intermediate routers (6LR) 2245 6LR_id represents the intermediate routers from the root to the 2246 destination, 1 <= id <= m, where m is the total number of the 2247 intermediate routers (6LR). 2249 This scenario is the combination of the previous two cases. 2251 The Figure 37 shows the table that summarizes what headers are needed 2252 for this use case. 2254 +---------+------+-------+-------+---------+-------+---------+------+ 2255 | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL | 2256 | | src | | | | | | dst | 2257 | | node | | | | | | node | 2258 +---------+------+-------+-------+---------+-------+---------+------+ 2259 | Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 2260 | headers | | (RPI1)| | (RH3, | | | | 2261 | | | | | RPI2) | | | | 2262 +---------+------+-------+-------+---------+-------+---------+------+ 2263 | Modified| -- | -- | | -- |IP6-IP6| -- | -- | 2264 | headers | | | RPI1 | | (RH3, | | | 2265 | | | | | | RPI2)| | | 2266 +---------+------+-------+-------+---------+-------+---------+------+ 2267 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2268 | headers | | | | (RPI1) | | (RH3, | | 2269 | | | | | | | RPI2) | | 2270 +---------+------+-------+-------+---------+-------+---------+------+ 2271 |Untouched| -- | -- | -- | -- | -- | -- | -- | 2272 | headers | | | | | | | | 2273 +---------+------+-------+-------+---------+-------+---------+------+ 2275 Figure 37: Non-SM: Summary of the use of headers from RUL to RUL 2277 9. Operational Considerations of supporting RUL-leaves 2279 Roughly half of the situations described in this document involve 2280 leaf ("host") nodes that do not speak RPL. These nodes fall into two 2281 further categories: ones that drop a packet that have RPI or RH3 2282 headers, and ones that continue to process a packet that has RPI and/ 2283 or RH3 headers. 2285 [RFC8200] provides for new rules that suggest that nodes that have 2286 not been configured (explicitly) to examine Hop-by-Hop headers, 2287 should ignore those headers, and continue processing the packet. 2288 Despite this, and despite the switch from 0x63 to 0x23, there may be 2289 nodes that are pre-RFC8200, or simply intolerant. Those nodes will 2290 drop packets that continue to have RPL artifacts in them. In 2291 general, such nodes can not be easily supported in RPL LLNs. 2293 There are some specific cases where it is possible to remove the RPL 2294 artifacts prior to forwarding the packet to the leaf host. The 2295 critical thing is that the artifacts have been inserted by the RPL 2296 root inside an IPv6-in-IPv6 header, and that the header has been 2297 addressed to the 6LR immediately prior to the leaf node. In that 2298 case, in the process of removing the IPv6-in-IPv6 header, the 2299 artifacts can also be removed. 2301 The above case occurs whenever traffic originates from the outside 2302 the LLN (the "Internet" cases above), and non-storing mode is used. 2303 In non-storing mode, the RPL root knows the exact topology (as it 2304 must create the RH3 header) and therefore knows which 6LR is prior to 2305 the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf 2306 Node G, or Node C is the 6LR prior to leaf Node J. 2308 Traffic originating from the RPL root (such as when the data 2309 collection system is co-located on the RPL root), does not require an 2310 IPv6-in-IPv6 header (in storing or non-storing mode), as the packet 2311 is originating at the root, and the root can insert the RPI and RH3 2312 headers directly into the packet, as it is formed. Such a packet is 2313 slightly smaller, but only can be sent to nodes (whether RPL aware or 2314 not), that will tolerate the RPL artifacts. 2316 An operator that finds itself with a high amount of traffic from the 2317 RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 2318 encapsulation if the leaf is not tolerant of the RPL artifacts. Such 2319 an operator could otherwise omit this unnecessary header if it was 2320 certain of the properties of the leaf. 2322 As storing mode can not know the final path of the traffic, 2323 intolerant (that drop packets with RPL artifacts) leaf nodes can not 2324 be supported. 2326 10. Operational considerations of introducing 0x23 2328 This section describes the operational considerations of introducing 2329 the new RPI Option Type of 0x23. 2331 During bootstrapping the node gets the DIO with the information of 2332 RPI Option Type, indicating the new RPI in the DODAG Configuration 2333 option Flag. The DODAG root is in charge to configure the current 2334 network to the new value, through DIO messages and when all the nodes 2335 are set with the new value. The DODAG should change to a new DODAG 2336 version. In case of rebooting, the node does not remember the RPI 2337 Option Type. Thus, the DIO is sent with a flag indicating the new 2338 RPI Option Type. 2340 The DODAG Configuration option is contained in a RPL DIO message, 2341 which contains a unique DTSN counter. The leaf nodes respond to this 2342 message with DAO messages containing the same DTSN. This is a normal 2343 part of RPL routing; the RPL root therefore knows when the updated 2344 DODAG Configuration option has been seen by all nodes. 2346 Before the migration happens, all the RPL-aware nodes should support 2347 both values . The migration procedure is triggered when the DIO is 2348 sent with the flag indicating the new RPI Option Type. Namely, it 2349 remains at 0x63 until it is sure that the network is capable of 0x23, 2350 then it abruptly changes to 0x23. The 0x23 RPI Option allows to send 2351 packets to not-RPL nodes. The not-RPL nodes should ignore the option 2352 and continue processing the packets. 2354 As mentioned previously, indicating the new RPI in the DODAG 2355 Configuration option flag is a way to avoid the flag day (abrupt 2356 changeover) in a network using 0x63 as the RPI Option Type value. It 2357 is suggested that RPL implementations accept both 0x63 and 0x23 RPI 2358 Option type values when processing the header to enable 2359 interoperability. 2361 11. IANA Considerations 2363 11.1. Option Type in RPL Option 2365 This document updates the registration made in [RFC6553] Destination 2366 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2367 Figure 38. 2369 +-------+-------------------+------------------------+---------- -+ 2370 | Hex | Binary Value | Description | Reference | 2371 + Value +-------------------+ + + 2372 | | act | chg | rest | | | 2373 +-------+-----+-----+-------+------------------------+------------+ 2374 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2375 +-------+-----+-----+-------+------------------------+------------+ 2376 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2377 | | | | | |[RFCXXXX](*)| 2378 +-------+-----+-----+-------+------------------------+------------+ 2380 Figure 38: Option Type in RPL Option.(*)represents this document 2382 DODAG Configuration option is updated as follows (Figure 39): 2384 +------------+-----------------+---------------+ 2385 | Bit number | Description | Reference | 2386 +------------+-----------------+---------------+ 2387 | 3 | RPI 0x23 enable | This document | 2388 +------------+-----------------+---------------+ 2390 Figure 39: DODAG Configuration option Flag to indicate the RPI-flag- 2391 day. 2393 11.2. Change to the DODAG Configuration Options Flags registry 2395 This document requests IANA to change the name of the "DODAG 2396 Configuration Option Flags" registry to "DODAG Configuration Option 2397 Flags for MOP 0..6". 2399 This document requests to be mentioned as a reference for this 2400 change. 2402 11.3. Change MOP value 7 to Reserved 2404 This document requests the changing the registration status of value 2405 7 in the Mode of Operation registry from Unassigned to Reserved. 2406 This change is in support of future work. 2408 This document requests to be mentioned as a reference for this entry 2409 in the registry. 2411 12. Security Considerations 2413 The security considerations covered in [RFC6553] and [RFC6554] apply 2414 when the packets are in the RPL Domain. 2416 The IPv6-in-IPv6 mechanism described in this document is much more 2417 limited than the general mechanism described in [RFC2473]. The 2418 willingness of each node in the LLN to decapsulate packets and 2419 forward them could be exploited by nodes to disguise the origin of an 2420 attack. 2422 While a typical LLN may be a very poor origin for attack traffic (as 2423 the networks tend to be very slow, and the nodes often have very low 2424 duty cycles), given enough nodes, LLNs could still have a significant 2425 impact, particularly if the attack is targeting another LLN. 2426 Additionally, some uses of RPL involve large backbone ISP scale 2427 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2428 equipped with multiple 100Gb/s interfaces. 2430 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2431 LLN as described above will make sure that any attack that is mounted 2432 must originate from compromised nodes within the LLN. The use of 2433 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2434 alert the operator to the existence of the attack, as well as drop 2435 the attack traffic. As the RPL network is typically numbered from a 2436 single prefix, which is itself assigned by RPL, BCP38 filtering 2437 involves a single prefix comparison and should be trivial to 2438 automatically configure. 2440 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2441 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2442 communications between a new Pledge and the Join Registrar/ 2443 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2444 and [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. This is the case 2445 for the RPL root to do careful filtering: it occurs only when the 2446 Join Coordinator is not co-located inside the RPL root. 2448 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2449 only be by a node within the LLN on another node within the LLN. 2450 Such an attack could, of course, be done directly. An attack of this 2451 kind is meaningful only if the source addresses are either fake or if 2452 the point is to amplify return traffic. Such an attack, could also 2453 be done without the use of IPv6-in-IPv6 headers using forged source 2454 addresses. If the attack requires bi-directional communication, then 2455 IPv6-in-IPv6 provides no advantages. 2457 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2458 about creating security issues. In the Security Considerations 2459 section of [RFC2473], it was suggested that tunnel entry and exit 2460 points can be secured by securing the IPv6 path between them. This 2461 recommendation is not practical for RPL networks. [RFC5406] goes 2462 into some detail on what additional details would be needed in order 2463 to "Use IPsec". Use of ESP would prevent [RFC8138] compression 2464 (compression must occur before encryption), and [RFC8138] compression 2465 is lossy in a way that prevents use of AH. These are minor issues. 2466 The major issue is how to establish trust enough such that IKEv2 2467 could be used. This would require a system of certificates to be 2468 present in every single node, including any Internet nodes that might 2469 need to communicate with the LLN. Thus, using IPsec requires a 2470 global PKI in the general case. 2472 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2473 IPv6 headers would in the general case scale with the square of the 2474 number of nodes. This is a lot of resource for a constrained nodes 2475 on a constrained network. In the end, the IPsec tunnels would be 2476 providing only BCP38-like origin authentication! That is, IPsec 2477 provides a transitive guarantee to the tunnel exit point that the 2478 tunnel entry point did BCP38 on traffic going in. Just doing origin 2479 filtering per BCP 38 at the entry and exit of the LLN provides a 2480 similar level of security without all the scaling and trust problems 2481 related to IPv6 tunnels as discussed in RFC 2473. IPsec is not 2482 recommended. 2484 An LLN with hostile nodes within it would not be protected against 2485 impersonation with the LLN by entry/exit filtering. 2487 The RH3 header usage described here can be abused in equivalent ways. 2488 An external attacker may form a packet with an RH3 that is not fully 2489 consumed and encapsulate it to hide the RH3 from intermediate nodes 2490 and disguise the origin of traffic. As such, the attacker's RH3 2491 header will not be seen by the network until it reaches the 2492 destination, which will decapsulate it. As indicated in section 4.2 2493 of [RFC6554], RPL routers are responsible for ensuring that an SRH is 2494 only used between RPL routers. As such, if there is an RH3 that is 2495 not fully consumed in the encapsulated packet, the node that 2496 decapsulates it MUST ensure that the outer packet was originated in 2497 the RPL domain and drop the packet otherwise. 2499 Also, as indicated by section 2 of [RFC6554], RPL Border Routers "do 2500 not allow datagrams carrying an SRH header to enter or exit a RPL 2501 routing domain". This sentence must be understood as concerning non- 2502 fully-consumed packets. A consumed (inert) RH3 header could be 2503 present in a packet that flows from one LLN, crosses the Internet, 2504 and enters another LLN. As per the discussion in this document, such 2505 headers do not need to be removed. However, there is no case 2506 described in this document where an RH3 is inserted in a non-storing 2507 network on traffic that is leaving the LLN, but this document should 2508 not preclude such a future innovation. 2510 In short, a packet that crosses the border of the RPL domain MAY 2511 carry and RH3, and if so, that RH3 MUST be fully consumed. 2513 The RPI, if permitted to enter the LLN, could be used by an attacker 2514 to change the priority of a packet by selecting a different 2515 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2516 It could also be that not all nodes are reachable in an LLN using the 2517 default RPLInstanceID, but a change of RPLInstanceID would permit an 2518 attacker to bypass such filtering. Like the RH3, an RPI is to be 2519 inserted by the RPL root on traffic entering the LLN by first 2520 inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will 2521 not be seen by the network. Upon reaching the destination node the 2522 RPI has no further meaning and is just skipped; the presence of a 2523 second RPI will have no meaning to the end node as the packet has 2524 already been identified as being at it's final destination. 2526 For traffic leaving a RUL, if the RUL adds an opaque RPI then the 6LR 2527 as a RPL border router SHOULD rewrite the RPI to indicate the 2528 selected Instance and set the flags. This is done in order to avoid: 2529 1) The leaf is an external router that passes a packet that it did 2530 not generate and that carries an unrelated RPI and 2) The leaf is an 2531 attacker or presents misconfiguration and tries to inject traffic in 2532 a protected instance. Also, this applies in the case where the leaf 2533 is aware of the RPL instance and passes a correct RPI; the 6LR needs 2534 a configuration that allows that leaf to inject in that instance. 2536 The RH3 and RPIs could be abused by an attacker inside of the network 2537 to route packets on non-obvious ways, perhaps eluding observation. 2538 This usage appears consistent with a normal operation of [RFC6997] 2539 and can not be restricted at all. This is a feature, not a bug. 2541 [RFC7416] deals with many other threats to LLNs not directly related 2542 to the use of IPv6-in-IPv6 headers, and this document does not change 2543 that analysis. 2545 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2546 attack on another part of the LLN, while disguising the origin of the 2547 attack. The mechanism can even be abused to make it appear that the 2548 attack is coming from outside the LLN, and unless countered, this 2549 could be used to mount a Distributed Denial Of Service attack upon 2550 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2551 such attacks already seen in the real world. 2553 If an attack comes from inside of LLN, it can be alleviated with SAVI 2554 (Source Address Validation Improvement) using [RFC8505] with 2556 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2557 traffic with an address that is not registered, and the registration 2558 process checks for topological correctness. Notice that there is an 2559 L2 authentication in most of the cases. If an attack comes from 2560 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2561 but by construction, the RH3 can typically only address nodes within 2562 the LLN. That is, an RH3 with a CmprI less than 8 , should be 2563 considered an attack (see RFC6554, section 3). 2565 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2566 through the RPL root to perform this attack. To counter, the RPL 2567 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2568 simpler solution), or it SHOULD walk the IP header extension chain 2569 until it can inspect the upper-layer-payload as described in 2570 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2571 on the source addresses of all IP headers that it examines in both 2572 directions. 2574 Note: there are some situations where a prefix will spread across 2575 multiple LLNs via mechanisms such as the one described in 2576 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2577 needs to take this into account, either by exchanging detailed 2578 routing information on each LLN, or by moving the BCP38 filtering 2579 further towards the Internet, so that the details of the multiple 2580 LLNs do not matter. 2582 13. Acknowledgments 2584 This work is done thanks to the grant given by the StandICT.eu 2585 project. 2587 A special BIG thanks to C. M. Heard for the help with the 2588 Section 4. Much of the redaction in that section is based on his 2589 comments. 2591 Additionally, the authors would like to acknowledge the review, 2592 feedback, and comments of (alphabetical order): Dominique Barthel, 2593 Robert Cragie, Simon Duquennoy, Ralph Droms, Cenk Guendogan, Rahul 2594 Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Mercado, 2595 Subramanian Moonesamy, Marcela Orbiscay, Charlie Perkins, Cristian 2596 Perez, Alvaro Retana, Peter van der Stok, Xavier Vilajosana, Eric 2597 Vyncke and Thomas Watteyne. 2599 14. References 2600 14.1. Normative References 2602 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2603 Defeating Denial of Service Attacks which employ IP Source 2604 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2605 May 2000, . 2607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2608 Requirement Levels", BCP 14, RFC 2119, 2609 DOI 10.17487/RFC2119, March 1997, 2610 . 2612 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2613 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2614 2010, . 2616 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2617 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2618 DOI 10.17487/RFC6282, September 2011, 2619 . 2621 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2622 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2623 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2624 Low-Power and Lossy Networks", RFC 6550, 2625 DOI 10.17487/RFC6550, March 2012, 2626 . 2628 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2629 Power and Lossy Networks (RPL) Option for Carrying RPL 2630 Information in Data-Plane Datagrams", RFC 6553, 2631 DOI 10.17487/RFC6553, March 2012, 2632 . 2634 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2635 Routing Header for Source Routes with the Routing Protocol 2636 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2637 DOI 10.17487/RFC6554, March 2012, 2638 . 2640 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2641 of IPv6 Extension Headers", RFC 7045, 2642 DOI 10.17487/RFC7045, December 2013, 2643 . 2645 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2646 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2647 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2648 . 2650 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2651 "IPv6 over Low-Power Wireless Personal Area Network 2652 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2653 April 2017, . 2655 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2656 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2657 May 2017, . 2659 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2660 (IPv6) Specification", STD 86, RFC 8200, 2661 DOI 10.17487/RFC8200, July 2017, 2662 . 2664 14.2. Informative References 2666 [DDOS-KREBS] 2667 Goodin, D., "Record-breaking DDoS reportedly delivered by 2668 >145k hacked cameras", September 2016, 2669 . 2672 [I-D.ietf-6lo-ap-nd] 2673 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2674 "Address Protected Neighbor Discovery for Low-power and 2675 Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in 2676 progress), April 2020. 2678 [I-D.ietf-6lo-backbone-router] 2679 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2680 Backbone Router", draft-ietf-6lo-backbone-router-20 (work 2681 in progress), March 2020. 2683 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2684 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2685 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 2686 progress), July 2019. 2688 [I-D.ietf-anima-autonomic-control-plane] 2689 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2690 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2691 plane-30 (work in progress), October 2020. 2693 [I-D.ietf-anima-bootstrapping-keyinfra] 2694 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2695 and K. Watsen, "Bootstrapping Remote Secure Key 2696 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2697 keyinfra-45 (work in progress), November 2020. 2699 [I-D.ietf-intarea-tunnels] 2700 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2701 Architecture", draft-ietf-intarea-tunnels-10 (work in 2702 progress), September 2019. 2704 [I-D.ietf-roll-unaware-leaves] 2705 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 2706 draft-ietf-roll-unaware-leaves-29 (work in progress), 2707 January 2021. 2709 [RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, 2710 DOI 10.17487/RFC0801, November 1981, 2711 . 2713 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2714 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2715 December 1998, . 2717 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2718 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2719 December 1998, . 2721 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2722 Control Message Protocol (ICMPv6) for the Internet 2723 Protocol Version 6 (IPv6) Specification", STD 89, 2724 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2725 . 2727 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2728 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2729 February 2009, . 2731 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2732 "IPv6 Flow Label Specification", RFC 6437, 2733 DOI 10.17487/RFC6437, November 2011, 2734 . 2736 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2737 Bormann, "Neighbor Discovery Optimization for IPv6 over 2738 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2739 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2740 . 2742 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2743 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2744 in Low-Power and Lossy Networks", RFC 6997, 2745 DOI 10.17487/RFC6997, August 2013, 2746 . 2748 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2749 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2750 2014, . 2752 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2753 and M. Richardson, Ed., "A Security Threat Analysis for 2754 the Routing Protocol for Low-Power and Lossy Networks 2755 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2756 . 2758 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2759 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2760 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2761 May 2017, . 2763 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2764 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2765 January 2019, . 2767 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2768 Perkins, "Registration Extensions for IPv6 over Low-Power 2769 Wireless Personal Area Network (6LoWPAN) Neighbor 2770 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2771 . 2773 Authors' Addresses 2775 Maria Ines Robles 2776 Universidad Tecno. Nac.(UTN)-FRM, Argentina/ Aalto University Finland 2778 Email: mariainesrobles@gmail.com 2780 Michael C. Richardson 2781 Sandelman Software Works 2782 470 Dawson Avenue 2783 Ottawa, ON K1Z 5V7 2784 CA 2786 Email: mcr+ietf@sandelman.ca 2787 URI: http://www.sandelman.ca/mcr/ 2788 Pascal Thubert 2789 Cisco Systems, Inc 2790 Building D 2791 45 Allee des Ormes - BP1200 2792 MOUGINS - Sophia Antipolis 06254 2793 FRANCE 2795 Phone: +33 497 23 26 34 2796 Email: pthubert@cisco.com