idnits 2.17.1 draft-ietf-roll-useofrplinfo-36.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 (February 26, 2020) is 1492 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-19 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-17 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-22 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-35 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-09 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 7 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: August 29, 2020 P. Thubert 7 Cisco 8 February 26, 2020 10 Using RPI option Type, Routing Header for Source Routes and IPv6-in-IPv6 11 encapsulation in the RPL Data Plane 12 draft-ietf-roll-useofrplinfo-36 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 August 29, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Language . . . . . . . . . . . . 5 65 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 67 4.1. Updates to RFC6550: Advertising External Routes with Non- 68 Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 69 4.2. Updates to RFC6553: Indicating the new RPI option Type. . 8 70 4.3. Updates to RFC6550: Indicating the new RPI in the 71 DODAG Configuration option Flag. . . . . . . . . . . . . 11 72 4.4. Updates to RFC8138: Indicating the way to decompress with 73 the new RPI option Type. . . . . . . . . . . . . . . . . 13 74 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14 75 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20 78 7.1.1. SM: Example of Flow from RAL to root . . . . . . . . 20 79 7.1.2. SM: Example of Flow from root to RAL . . . . . . . . 21 80 7.1.3. SM: Example of Flow from root to RUL . . . . . . . . 22 81 7.1.4. SM: Example of Flow from RUL to root . . . . . . . . 22 82 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 23 83 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 23 84 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 24 85 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 25 86 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 26 87 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 27 88 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 27 89 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 28 90 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 29 91 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 30 92 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 31 93 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 33 94 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 34 95 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 34 96 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 35 97 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 36 98 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 37 99 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 37 100 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 38 101 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 39 102 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 40 103 8.3. Non-SM: Interaction between leaves . . . . . . . . . . . 41 104 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 41 105 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 44 106 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 46 107 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 47 108 9. Operational Considerations of supporting 109 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 48 110 10. Operational considerations of introducing 0x23 . . . . . . . 49 111 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 113 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 115 14.1. Normative References . . . . . . . . . . . . . . . . . . 54 116 14.2. Informative References . . . . . . . . . . . . . . . . . 55 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 119 1. Introduction 121 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 122 [RFC6550] is a routing protocol for constrained networks. [RFC6553] 123 defines the RPL Option carried within the IPv6 Hop-by-Hop Header to 124 carry the RPLInstanceID and quickly identify inconsistencies (loops) 125 in the routing topology. The RPL Option is commonly referred to as 126 the RPL Packet Information (RPI) though the RPI is really the 127 abstract information that is defined in [RFC6550] and transported in 128 the RPL Option. RFC6554 [RFC6554] defines the "RPL Source Route 129 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 130 RPL routing domain, particularly in non-storing mode. 132 These various items are referred to as RPL artifacts, and they are 133 seen on all of the data-plane traffic that occurs in RPL routed 134 networks; they do not in general appear on the RPL control plane 135 traffic at all which is mostly Hop-by-Hop traffic (one exception 136 being DAO messages in non-storing mode). 138 It has become clear from attempts to do multi-vendor 139 interoperability, and from a desire to compress as many of the above 140 artifacts as possible that not all implementers agree when artifacts 141 are necessary, or when they can be safely omitted, or removed. 143 The ROLL WG analysized how [RFC2460] rules apply to storing and non- 144 storing use of RPL. The result was 24 data plane use cases. They 145 are exhaustively outlined here in order to be completely unambiguous. 146 During the processing of this document, new rules were published as 147 [RFC8200], and this document was updated to reflect the normative 148 changes in that document. 150 This document updates RFC6553, changing the value of the Option Type 151 of the RPL Option to make RFC8200 routers ignore this option when not 152 recognized. 154 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 155 mechanism for compressing RPL Option information and Routing Header 156 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 157 technique. 159 Since some of the uses cases here described, use IPv6-in-IPv6 160 encapsulation. It MUST take in consideration, when encapsulation is 161 applied, the RFC6040 [RFC6040], which defines how the explicit 162 congestion notification (ECN) field of the IP header should be 163 constructed on entry to and exit from any IPV6-in-IPV6 tunnel. 164 Additionally, it is recommended the reading of 165 [I-D.ietf-intarea-tunnels] that explains the relationship of IP 166 tunnels to existing protocol layers and the challenges in supporting 167 IP tunneling. 169 Non-constrained uses of RPL are not in scope of this document, and 170 applicability statements for those uses may provide different advice, 171 E.g. [I-D.ietf-anima-autonomic-control-plane]. 173 1.1. Overview 175 The rest of the document is organized as follows: Section 2 describes 176 the used terminology. Section 3 provides a RPL Overview. Section 4 177 describes the updates to RFC6553, RFC6550 and RFC 8138. Section 5 178 provides the reference topology used for the uses cases. Section 6 179 describes the uses cases included. Section 7 describes the storing 180 mode cases and section 8 the non-storing mode cases. Section 9 181 describes the operational considerations of supporting RPL-unaware- 182 leaves. Section 10 depicts operational considerations for the 183 proposed change on RPI option Type, section 11 the IANA 184 considerations and then section 12 describes the security aspects. 186 2. Terminology and Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 Terminology defined in [RFC7102] applies to this document: LLN, RPL, 195 RPL domain and ROLL. 197 RPL Leaf: An IPv6 host that is attached to a RPL router and obtains 198 connectivity through a RPL Destination Oriented Directed Acyclic 199 Graph (DODAG). As an IPv6 node, a RPL Leaf is expected to ignore a 200 consumed Routing Header and as an IPv6 host, it is expected to ignore 201 a Hop-by-Hop header. It results that a RPL Leaf can correctly 202 receive a packet with RPL artifacts. On the other hand, a RPL Leaf 203 is not expected to generate RPL artifacts or to support IP-in-IP 204 encapsulation. For simplification, this document uses the standalone 205 term leaf to mean a RPL leaf. 207 RPL Packet Information (RPI): The abstract information that [RFC6550] 208 places in IP packets. The term is commonly used, including in this 209 document, to refer to the RPL Option [RFC6553] that transports that 210 abstract information in an IPv6 Hob-by-Hop Header. 212 RPL-aware-node (RAN): A device which implements RPL. Please note 213 that the device can be found inside the LLN or outside LLN. 215 RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. 217 RPL-unaware-node: A device which does not implement RPL, thus the 218 device is not-RPL-aware. Please note that the device can be found 219 inside the LLN. 221 RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. 223 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any 224 host or router participating in a LoWPAN. This term is used when 225 referring to situations in which either a host or router can play the 226 role described.". In this document, a 6LN acts as a leaf. 228 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate 229 router in the LoWPAN that is able to send and receive Router 230 Advertisements (RAs) and Router Solicitations (RSs) as well as 231 forward and route IPv6 packets. 6LoWPAN routers are present only in 232 route-over topologies." 233 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 234 router located at the junction of separate 6LoWPAN networks or 235 between a 6LoWPAN network and another IP network. There may be one 236 or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the 237 responsible authority for IPv6 prefix propagation for the 6LoWPAN 238 network it is serving. An isolated LoWPAN also contains a 6LBR in 239 the network, which provides the prefix(es) for the isolated network." 241 Flag Day: A transition that involves having a network with different 242 values of RPI option Type. Thus the network does not work correctly 243 (Lack of interoperation). 245 Hop-by-Hop re-encapsulation: The term "Hop-by-Hop re-encapsulation" 246 header refers to adding a header that originates from a node to an 247 adjacent node, using the addresses (usually the Global Unicast 248 Address (GUA) or Unique Local Address (ULA) but could also use the 249 link-local addresses) of each node. If the packet must traverse 250 multiple hops, then it must be decapsulated at each hop, and then re- 251 encapsulated again in a similar fashion. 253 Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- 254 aware-nodes send information to the root about its parents. Thus, 255 the root know the topology. Because the root knows the topology, the 256 intermediate 6LRs do not maintain routing state then source routing 257 is needed. 259 Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes 260 (6LRs) maintain routing state (of the children) so that source 261 routing is not needed. 263 Note: Due to lack of space in some figures (tables) we refers IPv6- 264 in-IPv6 as IP6-IP6. 266 3. RPL Overview 268 RPL defines the RPL Control messages (control plane), a new ICMPv6 269 [RFC4443] message with Type 155. DIS (DODAG Information 270 Solicitation), DIO (DODAG Information Object) and DAO (Destination 271 Advertisement Object) messages are all RPL Control messages but with 272 different Code values. A RPL Stack is shown in Figure 1. 274 +--------------+ 275 | Upper Layers | 276 | | 277 +--------------+ 278 | RPL | 279 | | 280 +--------------+ 281 | ICMPv6 | 282 | | 283 +--------------+ 284 | IPv6 | 285 | | 286 +--------------+ 287 | 6LoWPAN | 288 | | 289 +--------------+ 290 | PHY-MAC | 291 | | 292 +--------------+ 294 Figure 1: RPL Stack. 296 RPL supports two modes of Downward traffic: in storing mode (SM), it 297 is fully stateful; in non-storing mode (Non-SM), it is fully source 298 routed. A RPL Instance is either fully storing or fully non-storing, 299 i.e. a RPL Instance with a combination of storing and non-storing 300 nodes is not supported with the current specifications at the time of 301 writing this document. 303 4. Updates to RFC6553, RFC6550 and RFC8138 305 4.1. Updates to RFC6550: Advertising External Routes with Non-Storing 306 Mode Signaling. 308 Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to 309 indicate that the 6LR that generates the DAO redistributes external 310 targets into the RPL network. An external Target is a Target that 311 has been learned through an alternate protocol, for instance a route 312 to a prefix that is outside the RPL domain but reachable via a 6LR. 313 Being outside of the RPL domain, a node that is reached via an 314 external target cannot be guaranteed to ignore the RPL artifacts and 315 cannot be expected to process the [RFC8138] compression correctly. 316 This means that the RPL artifacts should be contained in an IP-in-IP 317 encapsulation that is removed by the 6LR, and that any remaining 318 compression should be expanded by the 6LR before it forwards a packet 319 outside the RPL domain. 321 This specification updates [RFC6550] to RECOMMEND that external 322 targets are advertised using Non-Storing Mode DAO messaging even in a 323 Storing-Mode network. This way, external routes are not advertised 324 within the DODAG and all packets to an external target reach the Root 325 like normal Non-Storing Mode traffic. The Non-Storing Mode DAO 326 informs the Root of the address of the 6LR that injects the external 327 route, and the root uses IP-in-IP encapsulation to that 6LR, which 328 terminates the IP-in-IP tunnel and forwards the original packet 329 outside the RPL domain free of RPL artifacts. In the other 330 direction, for traffic coming from an external target into the LLN, 331 the parent (6LR) that injects the traffic always encapsulates to the 332 root. This whole operation is transparent to intermediate routers 333 that only see traffic between the 6LR and the Root, and only the Root 334 and the 6LRs that inject external routes in the network need to be 335 upgraded to add this function to the network. 337 A RUL is a special case of external target when the target is 338 actually a host and it is known to support a consumed Routing Header 339 and to ignore a HbH header as prescribed by [RFC8200]. The target 340 may have been learned through as a host route or may have been 341 registered to the 6LR using [RFC8505]. IP-in-IP encapsulation MAY be 342 avoided for Root to RUL communication if the RUL is known to process 343 the packets as forwarded by the parent 6LR without decapsulation. 345 In order to enable IP-in-IP all the way to a 6LN, it is beneficial 346 that the 6LN supports decapsulating IP-in-IP, but that is not assumed 347 by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a 348 packet SHOULD terminate the tunnel at a parent 6LR unless it is aware 349 that the RUL supports IP-in-IP decapsulation. 351 A node that is reachable over an external route is not expected to 352 support [RFC8138]. Whether a decapsulation took place or not and 353 even when the 6LR is delivering the packet to a RUL, the 6LR that 354 injected an external route MUST uncompress the packet before 355 forwarding over that external route. 357 4.2. Updates to RFC6553: Indicating the new RPI option Type. 359 This modification is required in order to be able to send, for 360 example, IPv6 packets from a RPL-Aware-Leaf to a RPL-unaware node 361 through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 362 encapsulation. 364 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 365 the Option Type field of the RPL Option, the two high order bits must 366 be set to '01' and the third bit is equal to '1'. The first two bits 367 indicate that the IPv6 node must discard the packet if it doesn't 368 recognize the Option Type, and the third bit indicates that the 369 Option Data may change in route. The remaining bits serve as the 370 Option Type. 372 +-------+-------------------+----------------+-----------+ 373 | Hex | Binary Value | Description | Reference | 374 + Value +-------------------+ + + 375 | | act | chg | rest | | | 376 +-------+-----+-----+-------+----------------+-----------+ 377 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 378 +-------+-----+-----+-------+----------------+-----------+ 380 Figure 2: Option Type in RPL Option. 382 This document illustrates that is is not always possible to know for 383 sure at the source that a packet will only travel within the RPL 384 domain or may leave it. 386 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 387 the outer IPv6 header chain could potentially impact core routers in 388 the internet. So at that time, it was decided to encapsulate any 389 packet with a RPL Option using IPv6-in-IPv6 in all cases where it was 390 unclear whether the packet would remain within the RPL domain. In 391 the exception case where a packet would still leak, the Option Type 392 would ensure that the first router in the Internet that does not 393 recognize the option would drop the packet and protect the rest of 394 the network. 396 Even with [RFC8138], where the IPv6-in-IPv6 header is compressed, 397 this approach yields extra bytes in a packet which means consuming 398 more energy, more bandwidth, incurring higher chances of loss and 399 possibly causing a fragmentation at the 6LoWPAN level. This impacts 400 the daily operation of constrained devices for a case that generally 401 does not happen and would not heavily impact the core anyway. 403 While intention was and remains that the Hop-by-Hop header with a RPL 404 Option should be confined within the RPL domain, this specification 405 modifies this behavior in order to reduce the dependency on IPv6-in- 406 IPv6 and protect the constrained devices. Section 4 of [RFC8200] 407 clarifies the behaviour of routers in the Internet as follows: "it is 408 now expected that nodes along a packet's delivery path only examine 409 and process the Hop-by-Hop Options header if explicitly configured to 410 do so". 412 When unclear about the travel of a packet, it becomes preferable for 413 a source not to encapsulate, accepting the fact that the packet may 414 leave the RPL domain on its way to its destination. In that event, 415 the packet should reach its destination and should not be discarded 416 by the first node that does not recognize the RPL Option. But with 417 the current value of the Option Type, if a node in the Internet is 418 configured to process the Hop-by-Hop header, and if such node 419 encounters an option with the first two bits set to 01 and conforms 420 to [RFC8200], it will drop the packet. Host systems should do the 421 same, irrespective of the configuration. 423 Thus, this document updates the Option Type of the RPL Option 424 [RFC6553], abusively naming it RPI option Type for simplicity, to 425 (Figure 3): the two high order bits MUST be set to '00' and the third 426 bit is equal to '1'. The first two bits indicate that the IPv6 node 427 MUST skip over this option and continue processing the header 428 ([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and 429 the third bit continues to be set to indicate that the Option Data 430 may change en route. The five rightmost bits remain at 0x3(00011). 431 This ensures that a packet that leaves the RPL domain of an LLN (or 432 that leaves the LLN entirely) will not be discarded when it contains 433 the RPL Option. 435 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 436 capable) receives a packet with an RPL Option, it should ignore the 437 Hop-by-Hop RPL Option (skip over this option and continue processing 438 the header). This is relevant, as it was mentioned previously, in 439 the case that there is a flow from RAL to Internet (see 440 Section 7.2.1). 442 This is a significant update to [RFC6553]. 444 +-------+-------------------+-------------+------------+ 445 | Hex | Binary Value | Description | Reference | 446 + Value +-------------------+ + + 447 | | act | chg | rest | | | 448 +-------+-----+-----+-------+-------------+------------+ 449 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 450 +-------+-----+-----+-------+-------------+------------+ 452 Figure 3: Revised Option Type in RPL Option. (*)represents this 453 document 455 Without the signaling described below, this change would otherwise 456 create a lack of interoperation (flag day) for existing networks 457 which are currently using 0x63 as the RPI option Type value. A move 458 to 0x23 will not be understood by those networks. It is suggested 459 that RPL implementations accept both 0x63 and 0x23 when processing 460 the header. 462 When forwarding packets, implementations SHOULD use the same value of 463 RPI Type as it was received. This is required because the RPI option 464 Type does not change en route ([RFC8200] - Section 4.2). It allows 465 the network to be incrementally upgraded and allows the DODAG root to 466 know which parts of the network have been upgraded. 468 When originating new packets, implementations SHOULD have an option 469 to determine which value to originate with, this option is controlled 470 by the DIO option described below. 472 The change of RPI option Type from 0x63 to 0x23, makes all [RFC8200] 473 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 474 therefore no longer a necessity to remove the artifacts when sending 475 traffic to the Internet. This change clarifies when to use IPv6-in- 476 IPv6 headers, and how to address them: The Hop-by-Hop Options header 477 containing the RPI MUST always be added when 6LRs originate packets 478 (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST always 479 be added when a 6LR find that it needs to insert a Hop-by-Hop Options 480 header containing the RPL Option. The IPv6-in-IPv6 header is to be 481 addressed to the RPL root when on the way up, and to the end-host 482 when on the way down. 484 In the non-storing case, dealing with not-RPL aware leaf nodes is 485 much easier as the 6LBR (DODAG root) has complete knowledge about the 486 connectivity of all DODAG nodes, and all traffic flows through the 487 root node. 489 The 6LBR can recognize not-RPL aware leaf nodes because it will 490 receive a DAO about that node from the 6LR immediately above that 491 not-RPL aware node. This means that the non-storing mode case can 492 avoid ever using Hop-by-Hop re-encapsulation headers for traffic 493 originating from the root to the leaves. 495 The non-storing mode case does not require the type change from 0x63 496 to 0x23, as the root can always create the right packet. The type 497 change does not adversely affect the non-storing case. 499 4.3. Updates to RFC6550: Indicating the new RPI in the DODAG 500 Configuration option Flag. 502 In order to avoid a Flag Day caused by lack of interoperation between 503 new RPI option Type (0x23) and old RPI option Type (0x63) nodes, this 504 section defines a flag in the DIO Configuration option, to indicate 505 when then new RPI option Type can be safely used. This means, the 506 flag is going to indicate the value of Option Type that the network 507 is using for the RPL Option. Thus, when a node join to a network 508 will know which value to use. With this, RPL-capable nodes know if 509 it is safe to use 0x23 when creating a new RPL Option. A node that 510 forwards a packet with a RPI MUST NOT modify the Option Type of the 511 RPL Option. 513 This is done using a DODAG Configuration option flag which will 514 signal "RPI 0x23 enable" and propagate through the network. 515 Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) 516 in the DIO Base Object. The flag is defined only for MOP value 517 between 0 to 6. For a MOP value of 7 or above, the flag MAY indicate 518 something different and MUST NOT be interpreted as "RPI 0x23 enable" 519 unless the specification of the MOP indicates to do so. 521 As stated in [RFC6550] the DODAG Configuration option is present in 522 DIO messages. The DODAG Configuration option distributes 523 configuration information. It is generally static, and does not 524 change within the DODAG. This information is configured at the DODAG 525 root and distributed throughout the DODAG with the DODAG 526 Configuration option. Nodes other than the DODAG root do not modify 527 this information when propagating the DODAG Configuration option. 529 Currently, the DODAG Configuration option in [RFC6550] states: "the 530 unused bits MUST be initialize to zero by the sender and MUST be 531 ignored by the receiver". If the flag is received with a value zero 532 (which is the default), then new nodes will remain in RFC6553 533 Compatible Mode; originating traffic with the old-RPI option Type 534 (0x63) value. If the flag is received with a value of 1, then the 535 option value for the RPL Option MUST be set to 0x23. 537 Bit number three of the flag field in the DODAG Configuration option 538 is to be used as shown in Figure 4 (which is the same as Figure 26 in 539 Section 11 and is shown here for convenience): 541 +------------+-----------------+---------------+ 542 | Bit number | Description | Reference | 543 +------------+-----------------+---------------+ 544 | 3 | RPI 0x23 enable | This document | 545 +------------+-----------------+---------------+ 547 Figure 4: DODAG Configuration option Flag to indicate the RPI-flag- 548 day. 550 In the case of rebooting, the node (6LN or 6LR) does not remember the 551 RPL Option Type (i.e., whether or not the flag is set), so DIO 552 messages sent by the node would be sent with the flag unset until a 553 DIO message is received with the flag set, indicating the new RPI 554 value. The node will use the value 0x23 if it supports this feature. 556 4.4. Updates to RFC8138: Indicating the way to decompress with the new 557 RPI option Type. 559 This modification is required in order to be able to decompress the 560 RPL Option with the new Option Type of 0x23. 562 RPI-6LoRH header provides a compressed form for the RPL RPI; see 563 [RFC8138], Section 6. A node that is decompressing this header MUST 564 decompress using the RPI option Type that is currently active: that 565 is, a choice between 0x23 (new) and 0x63 (old). The node will know 566 which to use based upon the presence of the flag in the DODAG 567 Configuration option defined in Section 4.3. E.g. If the network is 568 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 570 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 571 header. 573 There are potential significant advantages to having a single code 574 path that always processes IPv6-in-IPv6 headers with no conditional 575 branches. 577 In Storing Mode, the scenarios where the flow goes from RAL to RUL 578 and RUL to RUL include compression of the IPv6-in-IPv6 and RPI 579 headers. The use of the IPv6-in-IPv6 header is MANDATORY in this 580 case, and it SHOULD be compressed with [RFC8138] section 7. Figure 5 581 illustrates the case in Storing mode where the packet is received 582 from the Internet, then the root encapsulates the packet to insert 583 the RPI. In that example, the leaf is not known to support RFC 8138, 584 and the packet is encapsulated to the 6LR that is the parent and last 585 hop to the final destination. 587 +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... 588 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 589 |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 590 +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-... 591 <-4bytes-> <- RFC 6282 -> 592 No RPL artifact 594 Figure 5: RPI Inserted by the Root in Storing Mode 596 In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the 597 Root, so it is elided in the IP-in-IP 6LoRH. The destination is the 598 parent 6LR of the destination of the inner packet so it cannot be 599 elided. It is placed as the single entry in an SRH-6LoRH as the 600 first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In 601 that example, the type is 1 so the 6LR address is compressed to 2 602 bytes. It results that the total length of the SRH-6LoRH is 4 bytes. 603 Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 604 6LoRH is removed, all the router headers that precede it are also 605 removed. The Paging Dispatch [RFC8025] may also be removed if there 606 was no previous Page change to a Page other than 0 or 1, since the 607 LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and 608 in Page 1. The resulting packet to the destination is the inner 609 packet compressed with [RFC6282]. 611 5. Sample/reference topology 613 A RPL network in general is composed of a 6LBR, Backbone Router 614 (6BBR), 6LR and 6LN as a leaf logically organized in a DODAG 615 structure. 617 Figure 6 shows the reference RPL Topology for this document. The 618 letters above the nodes are there so that they may be referenced in 619 subsequent sections. In the figure, 6LR represents a full router 620 node. The 6LN is a RPL aware router, or host (as a leaf). 621 Additionally, for simplification purposes, it is supposed that the 622 6LBR has direct access to Internet and is the root of the DODAG, thus 623 the 6BBR is not present in the figure. 625 The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no 626 children hosts. 628 The leaves marked as RUL (G and J) are devices which do not speak RPL 629 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 630 DAC and efficient-ND only to participate in the network [RFC6775]. 631 In the document these leaves (G and J) are also referred to as an 632 IPv6 node. 634 The 6LBR ("A") in the figure is the root of the Global DODAG. 636 +------------+ 637 | INTERNET ----------+ 638 | | | 639 +------------+ | 640 | 641 | 642 | 643 A | 644 +-------+ 645 |6LBR | 646 +-----------|(root) |-------+ 647 | +-------+ | 648 | | 649 | | 650 | | 651 | | 652 | B |C 653 +---|---+ +---|---+ 654 | 6LR | | 6LR | 655 +---------| |--+ +--- ---+ 656 | +-------+ | | +-------+ | 657 | | | | 658 | | | | 659 | | | | 660 | | | | 661 | D | E | | 662 +-|-----+ +---|---+ | | 663 | 6LR | | 6LR | | | 664 | | +------ | | | 665 +---|---+ | +---|---+ | | 666 | | | | | 667 | | +--+ | | 668 | | | | | 669 | | | | | 670 | | | I | J | 671 F | | G | H | | 672 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 673 | RAL | | RUL | | RAL | | RAL | | RUL | 674 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 675 +-------+ +-------+ +------+ +-------+ +-------+ 677 Figure 6: A reference RPL Topology. 679 6. Use cases 681 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 682 encapsulation are going to be analyzed for a number of representative 683 traffic flows. 685 This document assumes that the LLN is using the no-drop RPI option 686 Type of 0x23. 688 The use cases describe the communication in the following cases: - 689 Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- 690 nodes with the Internet - Between RUL nodes within the LLN (e.g. see 691 Section 7.1.4) - Inside of the LLN when the final destination address 692 resides outside of the LLN (e.g. see Section 7.2.3). 694 The uses cases are as follows: 696 Interaction between Leaf and Root: 698 RAL to root 700 root to RAL 702 RUL to root 704 root to RUL 706 Interaction between Leaf and Internet: 708 RAL to Internet 710 Internet to RAL 712 RUL to Internet 714 Internet to RUL 716 Interaction between leaves: 718 RAL to RAL 720 RAL to RUL 722 RUL to RAL 724 RUL to RUL 726 This document is consistent with the rule that a Header cannot be 727 inserted or removed on the fly inside an IPv6 packet that is being 728 routed. This is a fundamental precept of the IPv6 architecture as 729 outlined in [RFC8200]. 731 As the rank information in the RPI artifact is changed at each hop, 732 it will typically be zero when it arrives at the DODAG root. The 733 DODAG root MUST force it to zero when passing the packet out to the 734 Internet. The Internet will therefore not see any SenderRank 735 information. 737 Despite being legal to leave the RPI artifact in place, an 738 intermediate router that needs to add an extension header (e.g. RH3 739 or RPL Option) MUST still encapsulate the packet in an (additional) 740 outer IP header. The new header is placed after this new outer IP 741 header. 743 A corollary is that a RH3 or RPL Option can only be removed by an 744 intermediate router if it is placed in an encapsulating IPv6 Header, 745 which is addressed TO the intermediate router. When it does so, the 746 whole encapsulating header must be removed. (A replacement may be 747 added). This sometimes can result in outer IP headers being 748 addressed to the next hop router using link-local address. 750 Both the RPL Option and the RH3 headers may be modified in very 751 specific ways by routers on the path of the packet without the need 752 to add and remove an encapsulating header. Both headers were 753 designed with this modification in mind, and both the RPL RH3 and the 754 RPL Option are marked mutable but recoverable: so an IPsec AH 755 security header can be applied across these headers, but it can not 756 secure the values which mutate. 758 The RPI MUST be present in every single RPL data packet. 760 Prior to [RFC8138], there was significant interest in removing the 761 RPI for downward flows in non-storing mode. The exception covered a 762 very small number of cases, and causes significant interoperability 763 challenges, yet costed significant code and testing complexity. The 764 ability to compress the RPI down to three bytes or less removes much 765 of the pressure to optimize this any further 766 [I-D.ietf-anima-autonomic-control-plane]. 768 The earlier examples are more extensive to make sure that the process 769 is clear, while later examples are more concise. 771 The uses cases are delineated based on the following requirements: 773 The RPIhas to be in every packet that traverses the LLN. 775 - Because of the previous requirement, packets from the Internet 776 have to be encapsulated. 778 - A Header cannot be inserted or removed on the fly inside an IPv6 779 packet that is being routed. 781 - Extension headers may not be added or removed except by the 782 sender or the receiver. 784 - RPI and RH3 headers may be modified by routers on the path of 785 the packet without the need to add and remove an encapsulating 786 header. 788 - a RH3 or RPL Option can only be removed by an intermediate 789 router if it is placed in an encapsulating IPv6 Header, which is 790 addressed to the intermediate router. 792 - Non-storing mode requires downstream encapsulation by root for 793 RH3. 795 The uses cases are delineated based on the following assumptions: 797 This document assumes that the LLN is using the no-drop RPI option 798 Type (0x23). 800 - Each IPv6 node (including Internet routers) obeys [RFC8200] RFC 801 8200, so that 0x23 RPI option Type can be safely inserted. 803 - All 6LRs obey RFC 8200 [RFC8200]. 805 - The RPI is ignored at the IPv6 dst node (RUL). 807 - In the uses cases, we assume that the RAL supports IP-in-IP 808 encapsulation. 810 - In the uses cases, we dont assume that the RUL supports IP-in-IP 811 encapsulation. 813 - Non-constrained uses of RPL are not in scope of this document. 815 - Compression is based on [RFC8138]. 817 - The flow label [RFC6437] is not needed in RPL. 819 7. Storing mode 821 In storing mode (SM) (fully stateful), the sender can determine if 822 the destination is inside the LLN by looking if the destination 823 address is matched by the DIO's Prefix Information Option (PIO) 824 option. 826 The following table (Figure 7) itemizes which headers are needed in 827 each of the following scenarios. It indicates whether (1) the IPv6- 828 in-IPv6 header that is added must be addressed to the final 829 destination (the RAL node that is the target (tgt)), (2) the IPv6-in- 830 IPv6 header that is added must be addressed to the "root", or (3) the 831 6LR parent of a RUL. 833 In cases where no IPv6-in-IPv6 header is needed, the column states as 834 "No". If the IPv6-in-IPv6 header is needed is a "must". 836 In all cases the RPI is needed, since it identifies inconsistencies 837 (loops) in the routing topology. In all cases the RH3 is not needed 838 because it is not used in storing mode. 840 In each case, 6LR_i represents the intermediate routers from source 841 to destination. "1 <= i <= n", n is the number of routers (6LR) that 842 the packet goes through from source (6LN) to destination. 844 The leaf can be a router 6LR or a host, both indicated as 6LN. The 845 root refers to the 6LBR (see Figure 6). 847 +---------------------+--------------+------------+----------------+ 848 | Interaction between | Use Case |IPv6-in-IPv6|IPv6-in-IPv6 dst| 849 +---------------------+--------------+------------+----------------+ 850 | | RAL to root | No | No | 851 + +--------------+------------+----------------+ 852 | Leaf - Root | root to RAL | No | No | 853 + +--------------+------------+----------------+ 854 | | root to RUL | No | No | 855 + +--------------+------------+----------------+ 856 | | RUL to root | must | root | 857 +---------------------+--------------+------------+----------------+ 858 | | RAL to Int | No | No | 859 + +--------------+------------+----------------+ 860 | Leaf - Internet | Int to RAL | must | RAL (tgt) | 861 + +--------------+------------+----------------+ 862 | | RUL to Int | must | root | 863 + +--------------+------------+----------------+ 864 | | Int to RUL | must | 6LR | 865 +---------------------+--------------+------------+----------------+ 866 | | RAL to RAL | No | No | 867 + +--------------+------------+----------------+ 868 | | RAL to RUL | No | No | 869 + Leaf - Leaf +--------------+------------+----------------+ 870 | | RUL to RAL | must | root | 871 + +--------------+------------+----------------+ 872 | | RUL to RUL | must | root | 873 +---------------------+--------------+------------+----------------+ 875 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 877 7.1. Storing Mode: Interaction between Leaf and Root 879 In this section is described the communication flow in storing mode 880 (SM) between, 882 RAL to root 884 root to RAL 886 RUL to root 888 root to RUL 890 7.1.1. SM: Example of Flow from RAL to root 892 In storing mode, RFC 6553 (RPI) is used to send RPL Information 893 instanceID and rank information. 895 In this case the flow comprises: 897 RAL (6LN) --> 6LR_i --> root(6LBR) 899 For example, a communication flow could be: Node F (6LN) --> Node D 900 (6LR_i) --> Node B (6LR_i)--> Node A root(6LBR) 902 The RAL (Node F) inserts the RPI, and sends the packet to 6LR (Node 903 D) which decrements the rank in the RPI and sends the packet up. 904 When the packet arrives at 6LBR (Node A), the RPI is removed and the 905 packet is processed. 907 No IPv6-in-IPv6 header is required. 909 The RPI can be removed by the 6LBR because the packet is addressed to 910 the 6LBR. The RAL must know that it is communicating with the 6LBR 911 to make use of this scenario. The RAL can know the address of the 912 6LBR because it knows the address of the root via the DODAGID in the 913 DIO messages. 915 The Table 1 summarizes what headers are needed for this use case. 917 +-------------------+---------+-------+----------+ 918 | Header | RAL src | 6LR_i | 6LBR dst | 919 +-------------------+---------+-------+----------+ 920 | Added headers | RPI | -- | -- | 921 | Modified headers | -- | RPI | -- | 922 | Removed headers | -- | -- | RPI | 923 | Untouched headers | -- | -- | -- | 924 +-------------------+---------+-------+----------+ 926 Table 1: SM: Summary of the use of headers from RAL to root 928 7.1.2. SM: Example of Flow from root to RAL 930 In this case the flow comprises: 932 root (6LBR) --> 6LR_i --> RAL (6LN) 934 For example, a communication flow could be: Node A root(6LBR) --> 935 Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN) 937 In this case the 6LBR inserts RPI and sends the packet down, the 6LR 938 is going to increment the rank in RPI (it examines the RPLInstanceID 939 to identify the right forwarding table), the packet is processed in 940 the RAL and the RPI removed. 942 No IPv6-in-IPv6 header is required. 944 The Table 2 summarizes what headers are needed for this use case. 946 +-------------------+----------+-------+---------+ 947 | Header | 6LBR src | 6LR_i | RAL dst | 948 +-------------------+----------+-------+---------+ 949 | Added headers | RPI | -- | -- | 950 | Modified headers | -- | RPI | -- | 951 | Removed headers | -- | -- | RPI | 952 | Untouched headers | -- | -- | -- | 953 +-------------------+----------+-------+---------+ 955 Table 2: SM: Summary of the use of headers from root to RAL 957 7.1.3. SM: Example of Flow from root to RUL 959 In this case the flow comprises: 961 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 963 For example, a communication flow could be: Node A (6LBR) --> Node B 964 (6LR_i) --> Node E (6LR_i) --> Node G (RUL) 966 As the RPI extension can be ignored by the RUL, this situation is 967 identical to the previous scenario. 969 The Table 3 summarizes what headers are needed for this use case. 971 +-------------------+----------+-------+----------------------+ 972 | Header | 6LBR src | 6LR_i | RUL (IPv6 dst node) | 973 +-------------------+----------+-------+----------------------+ 974 | Added headers | RPI | -- | -- | 975 | Modified headers | -- | RPI | -- | 976 | Removed headers | -- | -- | -- | 977 | Untouched headers | -- | -- | RPI (Ignored) | 978 +-------------------+----------+-------+----------------------+ 980 Table 3: SM: Summary of the use of headers from root to RUL 982 7.1.4. SM: Example of Flow from RUL to root 984 In this case the flow comprises: 986 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) 988 For example, a communication flow could be: Node G (RUL) --> Node E 989 (6LR_1)--> Node B (6LR_i)--> Node A root(6LBR) 990 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 991 the 6LR_1 will insert a RPI, encapsulated in a IPv6-in-IPv6 header. 992 The IPv6-in-IPv6 header is addressed to the root (Node A). The root 993 removes the header and processes the packet. 995 The Figure 8 shows the table that summarizes what headers are needed 996 for this use case where the IPv6-in-IPv6 header is addressed to the 997 root (Node A). 999 +-----------+------+--------------+----------------+-----------------+ 1000 | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | 1001 | | src | | | | 1002 | | node | | | | 1003 +-----------+------+--------------+----------------+-----------------+ 1004 | Added | -- | IP6-IP6(RPI) | | -- | 1005 | headers | | | -- | | 1006 +-----------+------+--------------+----------------+-----------------+ 1007 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1008 | headers | | | | | 1009 +-----------+------+--------------+----------------+-----------------+ 1010 | Removed | -- | -- | --- | IP6-IP6(RPI) | 1011 | headers | | | | | 1012 +-----------+------+--------------+----------------+-----------------+ 1013 | Untouched | -- | -- | -- | -- | 1014 | headers | | | | | 1015 +-----------+------+--------------+----------------+-----------------+ 1017 Figure 8: SM: Summary of the use of headers from RUL to root. 1019 7.2. SM: Interaction between Leaf and Internet. 1021 In this section is described the communication flow in storing mode 1022 (SM) between, 1024 RAL to Internet 1026 Internet to RAL 1028 RUL to Internet 1030 Internet to RUL 1032 7.2.1. SM: Example of Flow from RAL to Internet 1034 RPL information from RFC 6553 may go out to Internet as it will be 1035 ignored by nodes which have not been configured to be RPI aware. 1037 In this case the flow comprises: 1039 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 1041 For example, the communication flow could be: Node F (RAL) --> Node D 1042 (6LR_i)--> Node B (6LR_i)--> Node A root(6LBR) --> Internet 1044 No IPv6-in-IPv6 header is required. 1046 Note: In this use case, it is used a node as a leaf, but this use 1047 case can be also applicable to any RPL-aware-node type (e.g. 6LR) 1049 The Table 4 summarizes what headers are needed for this use case. 1051 +-------------------+---------+-------+------+----------------+ 1052 | Header | RAL src | 6LR_i | 6LBR | Internet dst | 1053 +-------------------+---------+-------+------+----------------+ 1054 | Added headers | RPI | -- | -- | -- | 1055 | Modified headers | -- | RPI | -- | -- | 1056 | Removed headers | -- | -- | -- | -- | 1057 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1058 +-------------------+---------+-------+------+----------------+ 1060 Table 4: SM: Summary of the use of headers from RAL to Internet 1062 7.2.2. SM: Example of Flow from Internet to RAL 1064 In this case the flow comprises: 1066 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 1068 For example, a communication flow could be: Internet --> Node A 1069 root(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) 1071 When the packet arrives from Internet to 6LBR the RPI is added in a 1072 outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address 1073 set to the RAL) and sent to 6LR, which modifies the rank in the RPI. 1074 When the packet arrives at the RAL the RPI is removed and the packet 1075 processed. 1077 The Figure 9 shows the table that summarizes what headers are needed 1078 for this use case. 1080 +-----------+----------+--------------+--------------+--------------+ 1081 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1082 | | src | | | | 1083 +-----------+----------+--------------+--------------+--------------+ 1084 | Added | -- | IP6-IP6(RPI) | -- | -- | 1085 | headers | | | | | 1086 +-----------+----------+--------------+--------------+--------------+ 1087 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1088 | headers | | | | | 1089 +-----------+----------+--------------+--------------+--------------+ 1090 | Removed | -- | -- | -- | IP6-IP6(RPI) | 1091 | headers | | | | | 1092 +-----------+----------+--------------+--------------+--------------+ 1093 | Untouched | -- | -- | -- | -- | 1094 | headers | | | | | 1095 +-----------+----------+--------------+--------------+--------------+ 1097 Figure 9: SM: Summary of the use of headers from Internet to RAL. 1099 7.2.3. SM: Example of Flow from RUL to Internet 1101 In this case the flow comprises: 1103 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1105 For example, a communication flow could be: Node G (RUL)--> Node E 1106 (6LR_1)--> Node B (6lR_i) --> Node A root(6LBR) --> Internet 1108 The node 6LR_1 (i=1) will add an IPv6-in-IPv6(RPI) header addressed 1109 to the root such that the root can remove the RPI before passing 1110 upwards. The IPv6-in-IPv6 addressed to the root cause less 1111 processing overhead. In the intermindiate 6LR the rank in the RPI is 1112 modified. 1114 The originating node will ideally leave the IPv6 flow label as zero 1115 so that the packet can be better compressed through the LLN. The 1116 6LBR will set the flow label of the packet to a non-zero value when 1117 sending to the Internet, for details check [RFC6437]. 1119 The Figure 10 shows the table that summarizes what headers are needed 1120 for this use case. 1122 +---------+-------+------------+-------------+-------------+--------+ 1123 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1124 | | src | | [i=2,...,n] | | dst | 1125 | | node | | | | | 1126 | | (RUL) | | | | | 1127 +---------+-------+------------+-------------+-------------+--------+ 1128 | Added | -- |IP6-IP6(RPI)| -- | -- | -- | 1129 | headers | | | | | | 1130 +---------+-------+------------+-------------+-------------+--------+ 1131 | Modified| -- | -- |IP6-IP6(RPI) | -- | -- | 1132 | headers | | | | | | 1133 +---------+-------+------------+-------------+-------------+--------+ 1134 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1135 | headers | | | | | | 1136 +---------+-------+------------+-------------+-------------+--------+ 1137 |Untouched| -- | -- | -- | -- | -- | 1138 | headers | | | | | | 1139 +---------+-------+------------+-------------+-------------+--------+ 1141 Figure 10: SM: Summary of the use of headers from RUL to Internet. 1143 7.2.4. SM: Example of Flow from Internet to RUL. 1145 In this case the flow comprises: 1147 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1149 For example, a communication flow could be: Internet --> Node A 1150 root(6LBR) --> Node B (6LR_i)--> Node E (6LR_n) --> Node G (RUL) 1152 The 6LBR will have to add a RPI within an IPv6-in-IPv6 header. The 1153 IPv6-in-IPv6 is addressed to the 6LR parent of the RUL. 1155 Further details about this are mentioned in 1156 [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN 1157 acting as a plain host and not being aware of RPL. 1159 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1160 zero in order to aid in compression [RFC8138][RFC6437]. 1162 The Figure 11 shows the table that summarizes what headers are needed 1163 for this use case. 1165 +---------+-------+------------+--------------+-------------+-------+ 1166 | Header |Inter- | 6LBR | 6LR_i | 6LR_n | RUL | 1167 | | net | |[i=1,..,n-1] | | dst | 1168 | | src | | | | | 1169 | | | | | | | 1170 +---------+-------+------------+--------------+-------------+-------+ 1171 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1172 | headers | | | | | | 1173 +---------+-------+------------+--------------+-------------+-------+ 1174 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1175 | headers | | | | | | 1176 +---------+-------+------------+--------------+-------------+-------+ 1177 | Removed | -- | -- | -- | IP6-IP6(RPI)| -- | 1178 | headers | | | | | | 1179 +---------+-------+------------+--------------+-------------+-------+ 1180 |Untouched| -- | -- | -- | -- | -- | 1181 | headers | | | | | | 1182 +---------+-------+------------+--------------+-------------+-------+ 1184 Figure 11: SM: Summary of the use of headers from Internet to RUL. 1186 7.3. SM: Interaction between Leaf and Leaf 1188 In this section is described the communication flow in storing mode 1189 (SM) between, 1191 RAL to RAL 1193 RAL to RUL 1195 RUL to RAL 1197 RUL to RUL 1199 7.3.1. SM: Example of Flow from RAL to RAL 1201 In [RFC6550] RPL allows a simple one-hop optimization for both 1202 storing and non-storing networks. A node may send a packet destined 1203 to a one-hop neighbor directly to that node. See section 9 in 1204 [RFC6550]. 1206 When the nodes are not directly connected, then in storing mode, the 1207 flow comprises: 1209 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL 1210 dst (6LN) 1211 For example, a communication flow could be: Node F (RAL src)--> Node 1212 D (6LR_ia)--> Node B (6LR_x) --> Node E (6LR_id) --> Node H (RAL dst) 1214 6LR_ia (Node D) represents the intermediate routers from source to 1215 the common parent (6LR_x) (Node B). In this case, 1 <= ia <= n, n is 1216 the number of routers (6LR) that the packet goes through from RAL 1217 (Node F) to the common parent 6LR_x (Node B). 1219 6LR_id (Node E) represents the intermediate routers from the common 1220 parent (6LR_x) (Node B) to destination RAL (Node H). In this case, 1 1221 <= id <= m, m is the number of routers (6LR) that the packet goes 1222 through from the common parent (6LR_x) to destination RAL (Node H). 1224 It is assumed that the two nodes are in the same RPL domain (that 1225 they share the same DODAG root). At the common parent (Node B), the 1226 direction of RPI is changed (from decreasing to increasing the rank). 1228 While the 6LR nodes will update the RPI, no node needs to add or 1229 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1231 The Table 5 summarizes what headers are needed for this use case. 1233 +---------------+--------+--------+---------------+--------+--------+ 1234 | Header | RAL | 6LR_ia | 6LR_x (common | 6LR_id | RAL | 1235 | | src | | parent) | | dst | 1236 +---------------+--------+--------+---------------+--------+--------+ 1237 | Added headers | RPI | -- | -- | -- | -- | 1238 | Modified | -- | RPI | RPI | RPI | -- | 1239 | headers | | | | | | 1240 | Removed | -- | -- | -- | -- | RPI | 1241 | headers | | | | | | 1242 | Untouched | -- | -- | -- | -- | -- | 1243 | headers | | | | | | 1244 +---------------+--------+--------+---------------+--------+--------+ 1246 Table 5: SM: Summary of the Use of Headers from RAL to RAL 1248 7.3.2. SM: Example of Flow from RAL to RUL 1250 In this case the flow comprises: 1252 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RUL 1253 (IPv6 dst node) 1255 For example, a communication flow could be: Node F (RAL)--> Node D 1256 --> Node B --> Node E --> Node G (RUL) 1257 6LR_ia represents the intermediate routers from source (RAL) to the 1258 common parent (6LR_x) In this case, 1 <= ia <= n, n is the number of 1259 routers (6LR) that the packet goes through from RAL to the common 1260 parent (6LR_x). 1262 6LR_id (Node E) represents the intermediate routers from the common 1263 parent (6LR_x) (Node B) to destination RUL (Node G). In this case, 1 1264 <= id <= m, m is the number of routers (6LR) that the packet goes 1265 through from the common parent (6LR_x) to destination RUL. The 1266 packet from the RAL goes to 6LBR because the route to the RUL is not 1267 injected into the RPL-SM. 1269 The Table 6 summarizes what headers are needed for this use case. 1271 +-----------------+---------+--------+------+--------+--------------+ 1272 | Header | RAL src | 6LR_ia | 6LBR | 6LR_id | RUL dst | 1273 +-----------------+---------+--------+------+--------+--------------+ 1274 | Added headers | RPI | -- | -- | -- | -- | 1275 | Modified | -- | RPI | RPI | RPI | -- | 1276 | headers | | | | | | 1277 | Removed headers | -- | -- | -- | -- | -- | 1278 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1279 | headers | | | | | | 1280 +-----------------+---------+--------+------+--------+--------------+ 1282 Table 6: SM: Summary of the Use of Headers from RAL to RUL 1284 7.3.3. SM: Example of Flow from RUL to RAL 1286 In this case the flow comprises: 1288 RUL (IPv6 src node) --> 6LR_ia --> 6LBR --> 6LR_id --> RAL dst (6LN) 1290 For example, a communication flow could be: Node G (RUL)--> Node E 1291 --> Node B --> Node A --> Node B --> Node D --> Node F (RAL) 1293 6LR_ia (Node E) represents the intermediate routers from source (RUL) 1294 (Node G) to the root (Node A). In this case, 1 <= ia <= n, n is the 1295 number of routers (6LR) that the packet goes through from source to 1296 the root. 1298 6LR_id represents the intermediate routers from the root (Node A) to 1299 destination RAL (Node F). In this case, 1 <= id <= m, m is the 1300 number of routers (6LR) that the packet goes through from the root to 1301 the destination RAL. 1303 The 6LR_ia (ia=1) (Node E) receives the packet from the RUL (Node G) 1304 and inserts the RPI (RPI1) encapsulated in a IPv6-in-IPv6 header to 1305 the root. The root removes the outer header including the RPI (RPI1) 1306 and inserts a new RPI (RPI2) addressed to the destination RAL (Node 1307 F). 1309 The Figure 12 shows the table that summarizes what headers are needed 1310 for this use case. 1312 +-----------+------+---------+---------+---------+---------+---------+ 1313 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 1314 | | src | | | | | dst | 1315 | | node | | | | | node | 1316 +-----------+------+---------+---------+---------+---------+---------+ 1317 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1318 | headers | | (RPI1) | | (RPI2) | | | 1319 | | | | | | | | 1320 +-----------+------+---------+---------+---------+---------+---------+ 1321 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1322 | headers | | -- | (RPI1) | | (RPI2) | | 1323 | | | | | | | | 1324 +-----------+------+---------+---------+---------+---------+---------+ 1325 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1326 | headers | | -- | | (RPI1) | | (RPI2) | 1327 | | | | | | | | 1328 +-----------+------+---------+---------+---------+---------+---------+ 1329 | Untouched | -- | -- | -- | -- | -- | -- | 1330 | headers | | | | | | | 1331 +-----------+------+---------+---------+---------+---------+---------+ 1333 Figure 12: SM: Summary of the use of headers from RUL to RAL. 1335 7.3.4. SM: Example of Flow from RUL to RUL 1337 In this case the flow comprises: 1339 RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> RUL 1340 (IPv6 dst node) 1342 For example, a communication flow could be: Node G (RUL src)--> Node 1343 E --> Node B --> Node A (root) --> Node C --> Node J (RUL dst) 1345 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1346 router from the RUL source (Node G) to the root (6LBR) (Node A). In 1347 this case, 1 <= ia <= n, n is the number of routers (6LR) that the 1348 packet goes through from the RUL to the root. 6LR_1 refers when ia=1. 1350 6LR_id (Node C) represents the intermediate routers from the root 1351 (Node A) to the destination RUL dst node (Node J). In this case, 1 1352 <= id <= m, m is the number of routers (6LR) that the packet goes 1353 through from the root to destination RUL. 1355 The RPI is ignored at the RUL dst node. 1357 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1358 inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header 1359 directed to the root. The root removes the outer header including 1360 the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR 1361 father of the RUL. 1363 The Figure 13 shows the table that summarizes what headers are needed 1364 for this use case. 1366 +---------+----+-------------+--------+---------+--------+-------+---+ 1367 | Header |RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id |6LR_n |RUL| 1368 | |src | | | | | |dst| 1369 | | | | | | | | | 1370 +---------+----+-------------+--------+---------+--------+-------+---+ 1371 | Added | -- |IP6-IP6(RPI1)| -- | IP6-IP6 | -- | -- | --| 1372 | Headers | | | | (RPI2) | | | | 1373 +---------+----+-------------+--------+---------+--------+-------+---+ 1374 |Modified | -- | -- |IP6-IP6 | -- |IP6-IP6 | -- | --| 1375 |headers | | | (RPI1) | | (RPI2) | | | 1376 +---------+----+-------------+--------+---------+--------+-------+---+ 1377 | Removed | -- | -- | -- | IP6-IP6 | -- |IP6-IP6| --| 1378 | headers | | | | (RPI1) | | (RPI2)| | 1379 +---------+----+-------------+--------+---------+--------+-------+---+ 1380 |Untouched| -- | -- | -- | -- | -- | -- | --| 1381 | headers | | | | | | | | 1382 +---------+----+-------------+--------+---------+--------+-------+---+ 1384 Figure 13: SM: Summary of the use of headers from RUL to RUL 1386 8. Non Storing mode 1388 In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG 1389 root) has complete knowledge about the connectivity of all DODAG 1390 nodes, and all traffic flows through the root node. Thus, there is 1391 no need for all nodes to know about the existence of RPL-unaware 1392 nodes. Only the 6LBR needs to act if compensation is necessary for 1393 not-RPL aware receivers. 1395 The table (Figure 14) summarizes what headers are needed in the 1396 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 1397 header are to be inserted. It depicts the target destination address 1398 possible to a 6LN (indicated by "RAL"), to a 6LR (parent of a RUL) or 1399 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1400 column states as "No". There is no expectation on RPL that RPI can 1401 be omitted, because it is needed for routing, quality of service and 1402 compression. This specification expects that is always a RPI 1403 Present. The term "may(up)" refers that the IPv6-in-IPv6 header may 1404 be necessary in the upwards direction. The term "must(up)" refers 1405 that the IPv6-in-IPv6 header must be present in the upwards 1406 direction. The term "must(down)" refers that the IPv6-in-IPv6 header 1407 must be present in the downward direction. 1409 The leaf can be a router 6LR or a host, both indicated as 6LN 1410 (Figure 6). In the table (Figure 14) the (1) indicates a 6tisch case 1411 [RFC8180], where the RPI may still be needed for the RPLInstanceID to 1412 be available for priority/channel selection at each hop. 1414 The root always have to encapuslate on the way down 1416 +--- ------------+-------------+-----+-----+--------------+----------+ 1417 | Interaction | Use Case | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP | 1418 | between | | | | | dst | 1419 +----------------+-------------+-----+-----+--------------+----------+ 1420 | | RAL to root | Yes | No | No | No | 1421 | +-------------+-----+-----+--------------+----------+ 1422 | Leaf - Root | root to RAL | Yes | Yes | No | No | 1423 | +-------------+-----+-----+--------------+----------+ 1424 | | root to RUL | Yes | Yes | must | 6LR | 1425 | | | (1) | | | | 1426 | +-------------+-----+-----+--------------+----------+ 1427 | | RUL to root | Yes | No | must | root | 1428 +----------------+-------------+-----+-----+--------------+----------+ 1429 | | RAL to Int | Yes | No | may(up) | root | 1430 | +-------------+-----+-----+--------------+----------+ 1431 |Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | 1432 | +-------------+-----+-----+--------------+----------+ 1433 | | RUL to Int | Yes | No | must | root | 1434 | +-------------+-----+-----+--------------+----------+ 1435 | | Int to RUL | Yes | Yes | must | 6LR | 1436 +----------------+-------------+-----+-----+--------------+----------+ 1437 | | RAL to RAL | Yes | Yes | may(up) | root | 1438 | | | | +--------------+----------+ 1439 | | | | | must(down) | RAL | 1440 | Leaf - Leaf +-------------+-----+-----+--------------+----------+ 1441 | | RAL to RUL | Yes | Yes | may(up) | root | 1442 | | | | +--------------+----------+ 1443 | | | | | must(down) | 6LR | 1444 | +-------------+-----+-----+--------------+----------+ 1445 | | RUL to RAL | Yes | Yes | must(up) | root | 1446 | | | | +--------------+----------+ 1447 | | | | | must(down) | RAL | 1448 | +-------------+-----+-----+--------------+----------+ 1449 | | RUL to RUL | Yes | Yes | must(up) | root | 1450 | | | | +--------------+----------+ 1451 | | | | | must(down) | 6LR | 1452 +----------------+-------------+-----+-----+--------------+----------+ 1454 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1455 RH3, IPv6-in-IPv6 encapsulation. 1457 8.1. Non-Storing Mode: Interaction between Leaf and Root 1459 In this section is described the communication flow in Non Storing 1460 Mode (Non-SM) between, 1462 RAL to root 1463 root to RAL 1465 RUL to root 1467 root to RUL 1469 8.1.1. Non-SM: Example of Flow from RAL to root 1471 In non-storing mode the leaf node uses default routing to send 1472 traffic to the root. The RPI must be included since it contains the 1473 rank information, which is used to avoid/detect loops. 1475 RAL (6LN) --> 6LR_i --> root(6LBR) 1477 For example, a communication flow could be: Node F --> Node D --> 1478 Node B --> Node A (root) 1480 6LR_i represents the intermediate routers from source to destination. 1481 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1482 packet goes through from source (RAL) to destination (6LBR). 1484 This situation is the same case as storing mode. 1486 The Table 7 summarizes what headers are needed for this use case. 1488 +-------------------+---------+-------+----------+ 1489 | Header | RAL src | 6LR_i | 6LBR dst | 1490 +-------------------+---------+-------+----------+ 1491 | Added headers | RPI | -- | -- | 1492 | Modified headers | -- | RPI | -- | 1493 | Removed headers | -- | -- | RPI | 1494 | Untouched headers | -- | -- | -- | 1495 +-------------------+---------+-------+----------+ 1497 Table 7: Non-SM: Summary of the use of headers from RAL to root 1499 8.1.2. Non-SM: Example of Flow from root to RAL 1501 In this case the flow comprises: 1503 root (6LBR) --> 6LR_i --> RAL (6LN) 1505 For example, a communication flow could be: Node A (root) --> Node B 1506 --> Node D --> Node F 1508 6LR_i represents the intermediate routers from source to destination. 1509 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1510 packet goes through from source (6LBR) to destination (RAL). 1512 The 6LBR inserts a RH3, and a RPI. No IPv6-in-IPv6 header is 1513 necessary as the traffic originates with a RPL aware node, the 6LBR. 1514 The destination is known to be RPL-aware because the root knows the 1515 whole topology in non-storing mode. 1517 The Table 8 summarizes what headers are needed for this use case. 1519 +-------------------+----------+-----------+-----------+ 1520 | Header | 6LBR src | 6LR_i | RAL dst | 1521 +-------------------+----------+-----------+-----------+ 1522 | Added headers | RPI, RH3 | -- | -- | 1523 | Modified headers | -- | RPI, RH3 | -- | 1524 | Removed headers | -- | -- | RH3, RPI | 1525 | Untouched headers | -- | -- | -- | 1526 +-------------------+----------+-----------+-----------+ 1528 Table 8: Non-SM: Summary of the use of headers from root to RAL 1530 8.1.3. Non-SM: Example of Flow from root to RUL 1532 In this case the flow comprises: 1534 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1536 For example, a communication flow could be: Node A (root) --> Node B 1537 --> Node E --> Node G (RUL) 1539 6LR_i represents the intermediate routers from source to destination. 1540 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1541 packet goes through from source (6LBR) to destination (RUL). 1543 In the 6LBR, the RH3 is added; it is then modified at each 1544 intermediate 6LR (6LR_1 and so on), and it is fully consumed in the 1545 last 6LR (6LR_n) but is left in place. When the RPI is added, the 1546 IPv6 node, which does not understand the RPI, will ignore it (per 1547 RFC8200); thus, encapsulation is not necessary. 1549 The Figure 15 depicts the table that summarizes what headers are 1550 needed for this use case. 1552 +-----------+----------+--------------+----------------+----------+ 1553 | Header | 6LBR | 6LR_i | 6LR_n | RUL | 1554 | | src | i=(1,..,n-1) | | dst | 1555 | | | | | | 1556 +-----------+----------+--------------+----------------+----------+ 1557 | Added | RPI, RH3 | -- | -- | -- | 1558 | headers | | | | | 1559 +-----------+----------+--------------+----------------+----------+ 1560 | Modified | -- | RPI, RH3 | RPI, | -- | 1561 | headers | | | RH3(consumed) | | 1562 +-----------+----------+--------------+----------------+----------+ 1563 | Removed | -- | -- | -- | -- | 1564 | headers | | | | | 1565 +-----------+----------+--------------+----------------+----------+ 1566 | Untouched | -- | -- | -- | RPI, RH3 | 1567 | headers | | | | (both | 1568 | | | | | ignored) | 1569 +-----------+----------+--------------+----------------+----------+ 1571 Figure 15: Non-SM: Summary of the use of headers from root to RUL 1573 8.1.4. Non-SM: Example of Flow from RUL to root 1575 In this case the flow comprises: 1577 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst 1579 For example, a communication flow could be: Node G --> Node E --> 1580 Node B --> Node A (root) 1582 6LR_i represents the intermediate routers from source to destination. 1583 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1584 packet goes through from source (RUL) to destination (6LBR). For 1585 example, 6LR_1 (i=1) is the router that receives the packets from the 1586 IPv6 node. 1588 In this case, the RPI is added by the first 6LR (6LR_1) (Node E), 1589 encapsulated in an IPv6-in-IPv6 header, and modified in the 1590 subsequent 6LRs in the flow. The RPI and the entire packet is 1591 consumed by the root. 1593 The Figure 16 shows the table that summarizes what headers are needed 1594 for this use case. 1596 +---------+----+-----------------+-----------------+-----------------+ 1597 | |RUL | | | | 1598 | Header |src | 6LR_1 | 6LR_i | 6LBR dst | 1599 | |node| | | | 1600 +---------+----+-----------------+-----------------+-----------------+ 1601 | Added | -- |IPv6-in-IPv6(RPI)| -- | -- | 1602 | headers | | | | | 1603 +---------+----+-----------------+-----------------+-----------------+ 1604 | Modified| -- | -- |IPv6-in-IPv6(RPI)| -- | 1605 | headers | | | | | 1606 +---------+----+-----------------+-----------------+-----------------+ 1607 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1608 | headers | | | | | 1609 +---------+----+-----------------+-----------------+-----------------+ 1610 |Untouched| -- | -- | -- | -- | 1611 | headers | | | | | 1612 +---------+----+-----------------+-----------------+-----------------+ 1614 Figure 16: Non-SM: Summary of the use of headers from RUL to root 1616 8.2. Non-Storing Mode: Interaction between Leaf and Internet 1618 This section will describe the communication flow in Non Storing Mode 1619 (Non-SM) between: 1621 RAL to Internet 1623 Internet to RAL 1625 RUL to Internet 1627 Internet to RUL 1629 8.2.1. Non-SM: Example of Flow from RAL to Internet 1631 In this case the flow comprises: 1633 RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst 1635 For example, a communication flow could be: Node F (RAL) --> Node D 1636 --> Node B --> Node A --> Internet 1638 6LR_i represents the intermediate routers from source to destination. 1639 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1640 packet goes through from source (RAL) to 6LBR. 1642 In this case, the encapsulation from the RAL to the root is optional. 1643 The simplest case is when the RPI gets to the Internet (as the table 1644 show it), knowing that the Internet is going to ignore it. 1646 The IPv6 flow label should be set to zero to aid in compression 1647 [RFC8138], and the 6LBR will set it to a non-zero value when sending 1648 towards the Internet [RFC6437]. 1650 The Table 9 summarizes what headers are needed for this use case when 1651 no encapsulation is used. The Table 10 summarizes what headers are 1652 needed for this use case when encapsulation to the root is used. 1654 +-------------------+---------+-------+------+----------------+ 1655 | Header | RAL src | 6LR_i | 6LBR | Internet dst | 1656 +-------------------+---------+-------+------+----------------+ 1657 | Added headers | RPI | -- | -- | -- | 1658 | Modified headers | -- | RPI | -- | -- | 1659 | Removed headers | -- | -- | -- | -- | 1660 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1661 +-------------------+---------+-------+------+----------------+ 1663 Table 9: Non-SM: Summary of the use of headers from RAL to Internet 1664 with no encapsulation 1666 +-----------+--------------+--------------+--------------+----------+ 1667 | Header | RAL src | 6LR_i | 6LBR | Internet | 1668 | | | | | dst | 1669 +-----------+--------------+--------------+--------------+----------+ 1670 | Added | IPv6-in-IPv6 | -- | -- | -- | 1671 | headers | (RPI) | | | | 1672 | Modified | -- | IPv6-in-IPv6 | -- | -- | 1673 | headers | | (RPI) | | | 1674 | Removed | -- | -- | IPv6-in-IPv6 | -- | 1675 | headers | | | (RPI) | | 1676 | Untouched | -- | -- | -- | -- | 1677 | headers | | | | | 1678 +-----------+--------------+--------------+--------------+----------+ 1680 Table 10: Non-SM: Summary of the use of headers from RAL to Internet 1681 with encapsulation to the root 1683 8.2.2. Non-SM: Example of Flow from Internet to RAL 1685 In this case the flow comprises: 1687 Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN) 1688 For example, a communication flow could be: Internet --> Node A 1689 (root) --> Node B --> Node D --> Node F (RAL) 1691 6LR_i represents the intermediate routers from source to destination. 1692 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1693 packet goes through from 6LBR to destination (RAL). 1695 The 6LBR must add a RH3 header. As the 6LBR will know the path and 1696 address of the target node, it can address the IPv6-in-IPv6 header to 1697 that node. The 6LBR will zero the flow label upon entry in order to 1698 aid compression [RFC8138]. 1700 The Table 11 summarizes what headers are needed for this use case. 1702 +-----------+----------+--------------+--------------+--------------+ 1703 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1704 | | src | | | | 1705 +-----------+----------+--------------+--------------+--------------+ 1706 | Added | -- | IPv6-in-IPv6 | -- | -- | 1707 | headers | | (RH3,RPI) | | | 1708 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1709 | headers | | | (RH3,RPI) | | 1710 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1711 | headers | | | | (RH3,RPI) | 1712 | Untouched | -- | -- | -- | -- | 1713 | headers | | | | | 1714 +-----------+----------+--------------+--------------+--------------+ 1716 Table 11: Non-SM: Summary of the use of headers from Internet to RAL 1718 8.2.3. Non-SM: Example of Flow from RUL to Internet 1720 In this case the flow comprises: 1722 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1723 dst 1725 For example, a communication flow could be: Node G --> Node E --> 1726 Node B --> Node A --> Internet 1728 6LR_i are the intermediate routers from source to destination. In 1729 this case, "1 <= i <= n", where n is the number of routers (6LRs) 1730 that the packet goes through from the source (RUL) to the 6LBR, e.g., 1731 6LR_1 (i=1). 1733 In this case the flow label is recommended to be zero in the IPv6 1734 node. As RPL headers are added in the IPv6 node packet, the first 1735 6LR (6LR_1) will add a RPI inside a new IPv6-in-IPv6 header. The 1736 IPv6-in-IPv6 header will be addressed to the root. This case is 1737 identical to the storing-mode case (see Section 7.2.3). 1739 The Figure 17 shows the table that summarizes what headers are needed 1740 for this use case. 1742 +---------+----+-------------+--------------+--------------+--------+ 1743 | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| 1744 | |src | | [i=2,..,n] | | dst | 1745 | |node| | | | | 1746 +---------+----+-------------+--------------+--------------+--------+ 1747 | Added | -- |IP6-IP6(RPI) | -- | -- | -- | 1748 | headers | | | | | | 1749 +---------+----+-------------+--------------+--------------+--------+ 1750 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1751 | headers | | | | | | 1752 +---------+----+-------------+--------------+--------------+--------+ 1753 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1754 | headers | | | | | | 1755 +---------+----+-------------+--------------+--------------+--------+ 1756 |Untouched| -- | -- | -- | -- | -- | 1757 | headers | | | | | | 1758 +---------+----+-------------+--------------+--------------+--------+ 1760 Figure 17: Non-SM: Summary of the use of headers from RUL to Internet 1762 8.2.4. Non-SM: Example of Flow from Internet to RUL 1764 In this case the flow comprises: 1766 Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1768 For example, a communication flow could be: Internet --> Node A 1769 (root) --> Node B --> Node E --> Node G 1771 6LR_i represents the intermediate routers from source to destination. 1772 In this case, 1 <= i <= n, n is the number of routers (6LR) that the 1773 packet goes through from 6LBR to RUL. 1775 The 6LBR must add a RH3 header inside an IPv6-in-IPv6 header. The 1776 6LBR will know the path, and will recognize that the final node is 1777 not a RPL capable node as it will have received the connectivity DAO 1778 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1779 header destination be the last 6LR. The 6LBR will set to zero the 1780 flow label upon entry in order to aid compression [RFC8138]. 1782 The Figure 18 shows the table that summarizes what headers are needed 1783 for this use case. 1785 +----------+--------+------------------+-----------+-----------+-----+ 1786 | Header |Internet| 6LBR | 6LR_i | 6LR_n | RUL | 1787 | | src | | | | dst | 1788 +----------+--------+------------------+-----------+-----------+-----+ 1789 | Added | -- | IP6-IP6(RH3,RPI) | -- | -- | -- | 1790 | headers | | | | | | 1791 +----------+--------+------------------+-----------+-----------+-----+ 1792 | Modified | -- | -- | IP6-IP6 | -- | -- | 1793 | headers | | | (RH3,RPI) | | | 1794 +----------+--------+------------------+-----------+-----------+-----+ 1795 | Removed | -- | -- | -- | IP6-IP6 | -- | 1796 | headers | | | | (RH3,RPI) | | 1797 +----------+--------+------------------+-----------+-----------+-----+ 1798 |Untouched | -- | -- | -- | -- | -- | 1799 | headers | | | | | | 1800 +----------+--------+------------------+-----------+-----------+-----+ 1802 Figure 18: Non-SM: Summary of the use of headers from Internet to 1803 RUL. 1805 8.3. Non-SM: Interaction between leaves 1807 In this section is described the communication flow in Non Storing 1808 Mode (Non-SM) between, 1810 RAL to RAL 1812 RAL to RUL 1814 RUL to RAL 1816 RUL to RUL 1818 8.3.1. Non-SM: Example of Flow from RAL to RAL 1820 In this case the flow comprises: 1822 RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst 1824 For example, a communication flow could be: Node F (RAL src)--> Node 1825 D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL 1826 dst) 1828 6LR_ia represents the intermediate routers from source to the root In 1829 this case, 1 <= ia <= n, n is the number of routers (6LR) that the 1830 packet goes through from RAL to the root. 1832 6LR_id represents the intermediate routers from the root to the 1833 destination. In this case, 1 <= id <= m, m is the number of the 1834 intermediate routers (6LR). 1836 This case involves only nodes in same RPL domain. The originating 1837 node will add a RPI to the original packet, and send the packet 1838 upwards. 1840 The originating node may put the RPI (RPI1) into an IPv6-in-IPv6 1841 header addressed to the root, so that the 6LBR can remove that 1842 header. If it does not, then the RPI1 is forwarded down from the 1843 root in the inner header to no avail. 1845 The 6LBR will need to insert a RH3 header, which requires that it add 1846 an IPv6-in-IPv6 header. It should be able to remove the RPI(RPI1), 1847 as it was contained in an IPv6-in-IPv6 header addressed to it. 1848 Otherwise, there may be a RPI buried inside the inner IP header, 1849 which should get ignored. The root inserts a RPI (RPI2) alongside 1850 the RH3. 1852 Networks that use the RPL P2P extension [RFC6997] are essentially 1853 non-storing DODAGs and fall into this scenario or scenario 1854 Section 8.1.2, with the originating node acting as 6LBR. 1856 The Figure 19 shows the table that summarizes what headers are needed 1857 for this use case when encapsulation to the root takes place. 1859 The Figure 20 shows the table that summarizes what headers are needed 1860 for this use case when there is no encapsulation to the root. 1862 +---------+-------+----------+------------+----------+------------+ 1863 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 1864 | | src | | | | dst | 1865 +---------+-------+----------+------------+----------+------------+ 1866 | Added |IP6-IP6| | IP6-IP6 | -- | -- | 1867 | headers |(RPI1) | -- |(RH3-> RAL, | | | 1868 | | | | RPI2) | | | 1869 +---------+-------+----------+------------+----------+------------+ 1870 | Modified| -- | IP6-IP6 | -- | IP6-IP6 | -- | 1871 | headers | | (RPI1) | |(RH3,RPI) | | 1872 +---------+-------+----------+------------+----------+------------+ 1873 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | 1874 | headers | | | (RPI1) | | (RH3, | 1875 | | | | | | RPI2) | 1876 +---------+-------+----------+------------+----------+------------+ 1877 |Untouched| -- | -- | -- | -- | -- | 1878 | headers | | | | | | 1879 +---------+-------+----------+------------+----------+------------+ 1881 Figure 19: Non-SM: Summary of the Use of Headers from RAL to RAL with 1882 encapsulation to the root. 1884 +-----------+------+--------+---------+---------+---------+ 1885 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 1886 +-----------+------+--------+---------+---------+---------+ 1887 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | 1888 | headers | | | (RH3, | | | 1889 | | | | RPI2) | | | 1890 +-----------+------+--------+---------+---------+---------+ 1891 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | 1892 | headers | | | | (RH3, | | 1893 | | | | | RPI2) | | 1894 +-----------+------+--------+---------+---------+---------+ 1895 | Removed | -- | -- | -- | -- | IP6-IP6 | 1896 | headers | | | | | (RH3, | 1897 | | | | | | RPI2) | 1898 | | | | | | RPI1 | 1899 +-----------+------+--------+---------+---------+---------+ 1900 | Untouched | -- | -- | RPI1 | RPI1 | -- | 1901 | headers | | | | | | 1902 +-----------+------+--------+---------+---------+---------+ 1904 Figure 20: Non-SM: Summary of the Use of Headers from RAL to RAL 1905 without encapsulation to the root. 1907 8.3.2. Non-SM: Example of Flow from RAL to RUL 1909 In this case the flow comprises: 1911 RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node) 1913 For example, a communication flow could be: Node F (RAL) --> Node D 1914 --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL) 1916 6LR_ia represents the intermediate routers from source to the root In 1917 this case, 1 <= ia <= n, n is the number of intermediate routers 1918 (6LR) 1920 6LR_id represents the intermediate routers from the root to the 1921 destination. In this case, 1 <= id <= m, m is the number of the 1922 intermediate routers (6LRs). 1924 As in the previous case, the RAL (6LN) may insert a RPI (RPI1) header 1925 which must be in an IPv6-in-IPv6 header addressed to the root so that 1926 the 6LBR can remove this RPI. The 6LBR will then insert a RH3 inside 1927 a new IPv6-in-IPv6 header addressed to the last 6LR_id (6LR_id = m) 1928 alongside the insertion of RPI2. 1930 If the originating node does not not put the RPI (RPI1) into an IPv6- 1931 in-IPv6 header addressed to the root. Then, the RPI1 is forwarded 1932 down from the root in the inner header to no avail. 1934 The Figure 21 shows the table that summarizes what headers are needed 1935 for this use case when encapsulation to the root takes place. The 1936 Figure 22 shows the table that summarizes what headers are needed for 1937 this use case when no encapsulation to the root takes place. 1939 +-----------+---------+---------+---------+---------+---------+------+ 1940 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 1941 | | src | | | | | dst | 1942 | | node | | | | | node | 1943 +-----------+---------+---------+---------+---------+---------+------+ 1944 | Added | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1945 | headers | (RPI1) | -- | (RH3, | | | | 1946 | | | | RPI2) | | | | 1947 +-----------+---------+---------+---------+---------+---------+------+ 1948 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1949 | headers | | (RPI1) | | (RH3, | -- | | 1950 | | | | | RPI2) | | | 1951 +-----------+---------+---------+---------+---------+---------+------+ 1952 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1953 | headers | | | (RPI1) | | (RH3, | | 1954 | | | | | | RPI2) | | 1955 +-----------+---------+---------+---------+---------+---------+------+ 1956 | Untouched | -- | -- | -- | -- | -- | -- | 1957 | headers | | | | | | | 1958 +-----------+---------+---------+---------+---------+---------+------+ 1960 Figure 21: Non-SM: Summary of the use of headers from RAL to RUL with 1961 encapsulation to the root. 1963 +-----------+------+--------+---------+---------+---------+---------+ 1964 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL | 1965 | | src | | | | | dst | 1966 | | node | | | | | node | 1967 +-----------+------+--------+---------+---------+---------+---------+ 1968 | Inserted | RPI1 | -- | IP6-IP6 | -- | -- | -- | 1969 | headers | | | (RH3, | | | | 1970 | | | | RPI2) | | | | 1971 +-----------+------+--------+---------+---------+---------+---------+ 1972 | Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- | 1973 | headers | | | | (RH3, | | | 1974 | | | | | RPI2) | | | 1975 +-----------+------+--------+---------+---------+---------+---------+ 1976 | Removed | -- | -- | -- | -- | IP6-IP6 | -- | 1977 | headers | | | | | (RH3, | | 1978 | | | | | | RPI2) | | 1979 +-----------+------+--------+---------+---------+---------+---------+ 1980 | Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 | 1981 | headers | | | | | |(Ignored)| 1982 +-----------+------+--------+---------+---------+---------+---------+ 1984 Figure 22: Non-SM: Summary of the use of headers from RAL to RUL 1985 without encapsulation to the root. 1987 8.3.3. Non-SM: Example of Flow from RUL to RAL 1989 In this case the flow comprises: 1991 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 1992 --> RAL dst (6LN) 1994 For example, a communication flow could be: Node G (RUL)--> Node E 1995 --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL) 1997 6LR_ia represents the intermediate routers from source to the root. 1998 In this case, 1 <= ia <= n, n is the number of intermediate routers 1999 (6LR) 2001 6LR_id represents the intermediate routers from the root to the 2002 destination. In this case, 1 <= id <= m, m is the number of the 2003 intermediate routers (6LR). 2005 In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1) 2006 inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will 2007 remove this RPI, and add it's own IPv6-in-IPv6 header containing a 2008 RH3 header and a RPI (RPI2). 2010 The Figure 23 shows the table that summarizes what headers are needed 2011 for this use case. 2013 +----------+------+---------+---------+---------+---------+---------+ 2014 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 2015 | | src | | | | | dst | 2016 | | node | | | | | node | 2017 +----------+------+---------+---------+---------+---------+---------+ 2018 | Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 2019 | headers | | (RPI1) | | (RH3, | | | 2020 | | | | | RPI2) | | | 2021 +----------+------+---------+---------+---------+---------+---------+ 2022 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 2023 | headers | | -- | (RPI1) | | (RH3, | | 2024 | | | | | | RPI2) | | 2025 +----------+------+---------+---------+---------+---------+---------+ 2026 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 2027 | headers | | -- | | (RPI1) | | (RH3, | 2028 | | | | | | | RPI2) | 2029 +----------+------+---------+---------+---------+---------+---------+ 2030 |Untouched | -- | -- | -- | -- | -- | -- | 2031 | headers | | | | | | | 2032 +----------+------+---------+---------+---------+---------+---------+ 2034 Figure 23: Non-SM: Summary of the use of headers from RUL to RAL. 2036 8.3.4. Non-SM: Example of Flow from RUL to RUL 2038 In this case the flow comprises: 2040 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 2041 --> RUL (IPv6 dst node) 2043 For example, a communication flow could be: Node G --> Node E --> 2044 Node B --> Node A (root) --> Node C --> Node J 2046 6LR_ia represents the intermediate routers from source to the root. 2047 In this case, 1 <= ia <= n, n is the number of intermediate routers 2048 (6LR) 2050 6LR_id represents the intermediate routers from the root to the 2051 destination. In this case, 1 <= id <= m, m is the number of the 2052 intermediate routers (6LR). 2054 This scenario is the combination of the previous two cases. 2056 The Figure 24 shows the table that summarizes what headers are needed 2057 for this use case. 2059 +---------+------+-------+-------+---------+-------+---------+------+ 2060 | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL | 2061 | | src | | | | | | dst | 2062 | | node | | | | | | node | 2063 +---------+------+-------+-------+---------+-------+---------+------+ 2064 | Added | -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 2065 | headers | | (RPI1)| | (RH3, | | | | 2066 | | | | | RPI2) | | | | 2067 +---------+------+-------+-------+---------+-------+---------+------+ 2068 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 2069 | headers | | | (RPI1)| | (RH3, | | | 2070 | | | | | | RPI2)| | | 2071 +---------+------+-------+-------+---------+-------+---------+------+ 2072 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2073 | headers | | | | (RPI1) | | (RH3, | | 2074 | | | | | | | RPI2) | | 2075 +---------+------+-------+-------+---------+-------+---------+------+ 2076 |Untouched| -- | -- | -- | -- | -- | -- | -- | 2077 | headers | | | | | | | | 2078 +---------+------+-------+-------+---------+-------+---------+------+ 2080 Figure 24: Non-SM: Summary of the use of headers from RUL to RUL 2082 9. Operational Considerations of supporting RUL-leaves 2084 Roughly half of the situations described in this document involve 2085 leaf ("host") nodes that do not speak RPL. These nodes fall into two 2086 further categories: ones that drop a packet that have RPI or RH3 2087 headers, and ones that continue to process a packet that has RPI and/ 2088 or RH3 headers. 2090 [RFC8200] provides for new rules that suggest that nodes that have 2091 not been configured (explicitly) to examine Hop-by-Hop headers, 2092 should ignore those headers, and continue processing the packet. 2093 Despite this, and despite the switch from 0x63 to 0x23, there may be 2094 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 2095 drop packets that continue to have RPL artifacts in them. In 2096 general, such hosts can not be easily supported in RPL LLNs. 2098 There are some specific cases where it is possible to remove the RPL 2099 artifacts prior to forwarding the packet to the leaf host. The 2100 critical thing is that the artifacts have been inserted by the RPL 2101 root inside an IPv6-in-IPv6 header, and that the header has been 2102 addressed to the 6LR immediately prior to the leaf node. In that 2103 case, in the process of removing the IPv6-in-IPv6 header, the 2104 artifacts can also be removed. 2106 The above case occurs whenever traffic originates from the outside 2107 the LLN (the "Internet" cases above), and non-storing mode is used. 2108 In non-storing mode, the RPL root knows the exact topology (as it 2109 must create the RH3 header) and therefore knows which 6LR is prior to 2110 the leaf. For example, in Figure 6, Node E is the 6LR prior to leaf 2111 Node G, or Node C is the 6LR prior to leaf Node J. 2113 traffic originating from the RPL root (such as when the data 2114 collection system is co-located on the RPL root), does not require an 2115 IPv6-in-IPv6 header (in either mode), as the packet is originating at 2116 the root, and the root can insert the RPI and RH3 headers directly 2117 into the packet, as it is formed. Such a packet is slightly smaller, 2118 but only can be sent to nodes (whether RPL aware or not), that will 2119 tolerate the RPL artifacts. 2121 An operator that finds itself with a lot of traffic from the RPL root 2122 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 2123 if the leaf is not tolerant of the RPL artifacts. Such an operator 2124 could otherwise omit this unnecessary header if it was certain of the 2125 properties of the leaf. 2127 As storing mode can not know the final path of the traffic, 2128 intolerant (that drop packets with RPL artifacts) leaf nodes can not 2129 be supported. 2131 10. Operational considerations of introducing 0x23 2133 This section describes the operational considerations of introducing 2134 the new RPI option Type of 0x23. 2136 During bootstrapping the node gets the DIO with the information of 2137 RPI option Type, indicating the new RPI in the DODAG Configuration 2138 option Flag. The DODAG root is in charge to configure the current 2139 network to the new value, through DIO messages and when all the nodes 2140 are set with the new value. The DODAG should change to a new DODAG 2141 version. In case of rebooting, the node does not remember the RPI 2142 option Type. Thus, the DIO is sent with a flag indicating the new 2143 RPI option Type. 2145 The DODAG Configuration option is contained in a RPL DIO message, 2146 which contains a unique DTSN counter. The leaf nodes respond to this 2147 message with DAO messages containing the same DTSN. This is a normal 2148 part of RPL routing; the RPL root therefore knows when the updated 2149 DODAG Configuration option has been seen by all nodes. 2151 Before the migration happens, all the RPL-aware nodes should support 2152 both values . The migration procedure it is triggered when the DIO 2153 is sent with the flag indicating the new RPI option Type. Namely, it 2154 remains at 0x63 until it is sure that the network is capable of 0x23, 2155 then it abruptly change to 0x23. This options allows to send packets 2156 to not-RPL nodes, which should ignore the option and continue 2157 processing the packets. 2159 In case that a node join to a network that only process 0x63, it 2160 would produce a flag day as was mentioned previously. Indicating the 2161 new RPI in the DODAG Configuration option Flag is a way to avoid the 2162 flag day in a network. It is recommended that a network process both 2163 options to enable interoperability. 2165 11. IANA Considerations 2167 This document updates the registration made in [RFC6553] Destination 2168 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2169 Figure 25. 2171 +-------+-------------------+------------------------+---------- -+ 2172 | Hex | Binary Value | Description | Reference | 2173 + Value +-------------------+ + + 2174 | | act | chg | rest | | | 2175 +-------+-----+-----+-------+------------------------+------------+ 2176 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2177 +-------+-----+-----+-------+------------------------+------------+ 2178 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2179 | | | | | |[RFCXXXX](*)| 2180 +-------+-----+-----+-------+------------------------+------------+ 2182 Figure 25: Option Type in RPL Option.(*)represents this document 2184 DODAG Configuration option is updated as follows (Figure 26): 2186 +------------+-----------------+---------------+ 2187 | Bit number | Description | Reference | 2188 +------------+-----------------+---------------+ 2189 | 3 | RPI 0x23 enable | This document | 2190 +------------+-----------------+---------------+ 2192 Figure 26: DODAG Configuration option Flag to indicate the RPI-flag- 2193 day. 2195 12. Security Considerations 2197 The security considerations covered in [RFC6553] and [RFC6554] apply 2198 when the packets are in the RPL Domain. 2200 The IPv6-in-IPv6 mechanism described in this document is much more 2201 limited than the general mechanism described in [RFC2473]. The 2202 willingness of each node in the LLN to decapsulate packets and 2203 forward them could be exploited by nodes to disguise the origin of an 2204 attack. 2206 While a typical LLN may be a very poor origin for attack traffic (as 2207 the networks tend to be very slow, and the nodes often have very low 2208 duty cycles) given enough nodes, they could still have a significant 2209 impact, particularly if attack is targeting another LLN. 2210 Additionally, some uses of RPL involve large backbone ISP scale 2211 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2212 equipped with multiple 100Gb/s interfaces. 2214 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2215 LLN as described above will make sure that any attack that is mounted 2216 must originate from compromised nodes within the LLN. The use of 2217 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2218 alert the operator to the existence of the attack, as well as drop 2219 the attack traffic. As the RPL network is typically numbered from a 2220 single prefix, which is itself assigned by RPL, BCP38 filtering 2221 involves a single prefix comparison and should be trivial to 2222 automatically configure. 2224 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2225 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2226 communications between a new Pledge and the Join Registrar/ 2227 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2228 and [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. This is the case 2229 for the RPL root to do careful filtering: it occurs only when the 2230 Join Coordinator is not co-located inside the RPL root. 2232 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2233 only be by a node within the LLN on another node within the LLN. 2234 Such an attack could, of course, be done directly. An attack of this 2235 kind is meaningful only if the source addresses are either fake or if 2236 the point is to amplify return traffic. Such an attack, could also 2237 be done without the use of IPv6-in-IPv6 headers using forged source 2238 addresses. If the attack requires bi-directional communication, then 2239 IPv6-in-IPv6 provides no advantages. 2241 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2242 about creating security issues. In the Security Considerations 2243 section of [RFC2473], it was suggested that tunnel entry and exit 2244 points can be secured by securing the IPv6 path between them. This 2245 recommendation is not practical for RPL networks. [RFC5406] goes 2246 into some detail on what additional details would be needed in order 2247 to "Use IPsec". Use of ESP would prevent RFC8138 compression 2248 (compression must occur before encryption), and RFC8138 compression 2249 is lossy in a way that prevents use of AH. These are minor issues. 2250 The major issue is how to establish trust enough such that IKEv2 2251 could be used. This would require a system of certificates to be 2252 present in every single node, including any Internet nodes that might 2253 need to communicate with the LLN. Thus, using IPsec requires a 2254 global PKI in the general case. 2256 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2257 IPv6 headers would in the general case scale with the square of the 2258 number of nodes. This is a lot of resource for a constrained nodes 2259 on a constrained network. In the end, the IPsec tunnels would be 2260 providing only BCP38-like origin authentication! That is, IPsec 2261 provides a transitive guarantee to the tunnel exit point that the 2262 tunnel entry point did BCP38 on traffic going in. Just doing origin 2263 filtering per BCP 38 at the entry and exit of the LLN provides a 2264 similar level of security without all the scaling and trust problems 2265 related to IPv6 tunnels as discussed in RFC 2473. IPsec is not 2266 recommended. 2268 An LLN with hostile nodes within it would not be protected against 2269 impersonation with the LLN by entry/exit filtering. 2271 The RH3 header usage described here can be abused in equivalent ways 2272 (to disguise the origin of traffic and attack other nodes) with an 2273 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2274 attacker's RH3 header will not be seen by the network until it 2275 reaches the end host, which will decapsulate it. An end-host should 2276 be suspicious about a RH3 header which has additional hops which have 2277 not yet been processed, and SHOULD ignore such a second RH3 header. 2279 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2280 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2281 will see the second RH3 header and MAY choose to discard the packet 2282 if the RH3 header has not been completely consumed. A consumed 2283 (inert) RH3 header could be present in a packet that flows from one 2284 LLN, crosses the Internet, and enters another LLN. As per the 2285 discussion in this document, such headers do not need to be removed. 2286 However, there is no case described in this document where a RH3 is 2287 inserted in a non-storing network on traffic that is leaving the LLN, 2288 but this document should not preclude such a future innovation. It 2289 should just be noted that an incoming RH3 must be fully consumed, or 2290 very carefully inspected. 2292 The RPI, if permitted to enter the LLN, could be used by an attacker 2293 to change the priority of a packet by selecting a different 2294 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2295 It could also be that not all nodes are reachable in an LLN using the 2296 default RPLInstanceID, but a change of RPLInstanceID would permit an 2297 attacker to bypass such filtering. Like the RH3, a RPI is to be 2298 inserted by the RPL root on traffic entering the LLN by first 2299 inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will 2300 not be seen by the network. Upon reaching the destination node the 2301 RPI has no further meaning and is just skipped; the presence of a 2302 second RPI will have no meaning to the end node as the packet has 2303 already been identified as being at it's final destination. 2305 The RH3 and RPIs could be abused by an attacker inside of the network 2306 to route packets on non-obvious ways, perhaps eluding observation. 2307 This usage is in fact part of [RFC6997] and can not be restricted at 2308 all. This is a feature, not a bug. 2310 [RFC7416] deals with many other threats to LLNs not directly related 2311 to the use of IPv6-in-IPv6 headers, and this document does not change 2312 that analysis. 2314 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2315 attack on another part of the LLN, while disguising the origin of the 2316 attack. The mechanism can even be abused to make it appear that the 2317 attack is coming from outside the LLN, and unless countered, this 2318 could be used to mount a Distributed Denial Of Service attack upon 2319 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2320 such attacks already seen in the real world. 2322 If an attack comes from inside of LLN, it can be alleviated with SAVI 2323 (Source Address Validation Improvement) using [RFC8505] with 2324 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2325 traffic with an address that is not registered, and the registration 2326 process checks for topological correctness. Notice that there is an 2327 L2 authentication in most of the cases. If an attack comes from 2328 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2329 but by construction, the RH3 can typically only address nodes within 2330 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2331 considered an attack (see RFC6554, section 3). 2333 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2334 through the RPL root to perform this attack. To counter, the RPL 2335 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2336 simpler solution), or it SHOULD walk the IP header extension chain 2337 until it can inspect the upper-layer-payload as described in 2338 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2339 on the source addresses of all IP headers that it examines in both 2340 directions. 2342 Note: there are some situations where a prefix will spread across 2343 multiple LLNs via mechanisms such as the one described in 2344 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2345 needs to take this into account, either by exchanging detailed 2346 routing information on each LLN, or by moving the BCP38 filtering 2347 further towards the Internet, so that the details of the multiple 2348 LLNs do not matter. 2350 13. Acknowledgments 2352 This work is done thanks to the grant given by the StandICT.eu 2353 project. 2355 A special BIG thanks to C. M. Heard for the help with the 2356 Section 4. Much of the redaction in that section is based on his 2357 comments. 2359 Additionally, the authors would like to acknowledge the review, 2360 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2361 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Benjamin Kaduk, 2362 Matthias Kovatsch, Charlie Perkins, Alvaro Retana, Peter van der 2363 Stok, Xavier Vilajosana, Eric Vyncke and Thomas Watteyne. 2365 14. References 2367 14.1. Normative References 2369 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2370 Defeating Denial of Service Attacks which employ IP Source 2371 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2372 May 2000, . 2374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2375 Requirement Levels", BCP 14, RFC 2119, 2376 DOI 10.17487/RFC2119, March 1997, 2377 . 2379 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2380 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2381 2010, . 2383 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2384 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2385 DOI 10.17487/RFC6282, September 2011, 2386 . 2388 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2389 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2390 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2391 Low-Power and Lossy Networks", RFC 6550, 2392 DOI 10.17487/RFC6550, March 2012, 2393 . 2395 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2396 Power and Lossy Networks (RPL) Option for Carrying RPL 2397 Information in Data-Plane Datagrams", RFC 6553, 2398 DOI 10.17487/RFC6553, March 2012, 2399 . 2401 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2402 Routing Header for Source Routes with the Routing Protocol 2403 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2404 DOI 10.17487/RFC6554, March 2012, 2405 . 2407 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2408 of IPv6 Extension Headers", RFC 7045, 2409 DOI 10.17487/RFC7045, December 2013, 2410 . 2412 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2413 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2414 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2415 . 2417 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2418 "IPv6 over Low-Power Wireless Personal Area Network 2419 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2420 April 2017, . 2422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2424 May 2017, . 2426 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2427 (IPv6) Specification", STD 86, RFC 8200, 2428 DOI 10.17487/RFC8200, July 2017, 2429 . 2431 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2432 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2433 January 2019, . 2435 14.2. Informative References 2437 [DDOS-KREBS] 2438 Goodin, D., "Record-breaking DDoS reportedly delivered by 2439 >145k hacked cameras", September 2016, 2440 . 2443 [I-D.ietf-6lo-ap-nd] 2444 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2445 "Address Protected Neighbor Discovery for Low-power and 2446 Lossy Networks", draft-ietf-6lo-ap-nd-19 (work in 2447 progress), February 2020. 2449 [I-D.ietf-6lo-backbone-router] 2450 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2451 Backbone Router", draft-ietf-6lo-backbone-router-17 (work 2452 in progress), February 2020. 2454 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2455 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2456 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 2457 progress), July 2019. 2459 [I-D.ietf-anima-autonomic-control-plane] 2460 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2461 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2462 plane-22 (work in progress), February 2020. 2464 [I-D.ietf-anima-bootstrapping-keyinfra] 2465 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2466 and K. Watsen, "Bootstrapping Remote Secure Key 2467 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2468 keyinfra-35 (work in progress), February 2020. 2470 [I-D.ietf-intarea-tunnels] 2471 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2472 Architecture", draft-ietf-intarea-tunnels-10 (work in 2473 progress), September 2019. 2475 [I-D.ietf-roll-unaware-leaves] 2476 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 2477 draft-ietf-roll-unaware-leaves-09 (work in progress), 2478 January 2020. 2480 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2481 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2482 December 1998, . 2484 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2485 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2486 December 1998, . 2488 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2489 Control Message Protocol (ICMPv6) for the Internet 2490 Protocol Version 6 (IPv6) Specification", STD 89, 2491 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2492 . 2494 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2495 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2496 February 2009, . 2498 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2499 "IPv6 Flow Label Specification", RFC 6437, 2500 DOI 10.17487/RFC6437, November 2011, 2501 . 2503 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2504 Bormann, "Neighbor Discovery Optimization for IPv6 over 2505 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2506 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2507 . 2509 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2510 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2511 in Low-Power and Lossy Networks", RFC 6997, 2512 DOI 10.17487/RFC6997, August 2013, 2513 . 2515 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2516 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2517 2014, . 2519 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2520 and M. Richardson, Ed., "A Security Threat Analysis for 2521 the Routing Protocol for Low-Power and Lossy Networks 2522 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2523 . 2525 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2526 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2527 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2528 May 2017, . 2530 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2531 Perkins, "Registration Extensions for IPv6 over Low-Power 2532 Wireless Personal Area Network (6LoWPAN) Neighbor 2533 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2534 . 2536 Authors' Addresses 2538 Maria Ines Robles 2539 Universidad Tecno. Nac.(UTN)-FRM, Argentina / Aalto University, Finland 2541 Email: mariainesrobles@gmail.com 2542 Michael C. Richardson 2543 Sandelman Software Works 2544 470 Dawson Avenue 2545 Ottawa, ON K1Z 5V7 2546 CA 2548 Email: mcr+ietf@sandelman.ca 2549 URI: http://www.sandelman.ca/mcr/ 2551 Pascal Thubert 2552 Cisco Systems, Inc 2553 Building D 2554 45 Allee des Ormes - BP1200 2555 MOUGINS - Sophia Antipolis 06254 2556 FRANCE 2558 Phone: +33 497 23 26 34 2559 Email: pthubert@cisco.com