idnits 2.17.00 (12 Aug 2021) /tmp/idnits3058/draft-ietf-roll-useofrplinfo-33.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 (December 13, 2019) is 890 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) -- Looks like a reference, but probably isn't: '1' on line 1811 -- Looks like a reference, but probably isn't: '2' on line 1140 == Outdated reference: draft-ietf-6lo-ap-nd has been published as RFC 8928 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-anima-autonomic-control-plane has been published as RFC 8994 == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: draft-ietf-roll-unaware-leaves has been published as RFC 9010 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group M. Robles 3 Internet-Draft Aalto 4 Updates: 6553, 6550, 8138 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: June 15, 2020 P. Thubert 7 Cisco 8 December 13, 2019 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-33 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 June 15, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Language . . . . . . . . . . . . 5 65 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 67 4.1. Updates to RFC6550: Advertising External Routes with Non- 68 Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 69 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8 70 4.3. Updates to RFC6550: Indicating the new RPI in the 71 DODAG Configuration Option Flag. . . . . . . . . . . . . 11 72 4.4. Updates to RFC8138: Indicating the way to decompress with 73 the new RPI Option Type. . . . . . . . . . . . . . . . . 12 74 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 14 75 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 20 78 7.1.1. SM: Example of Flow from RAL to root . . . . . . . . 21 79 7.1.2. SM: Example of Flow from root to RAL . . . . . . . . 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 . . . . . . . . 23 82 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 23 83 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 24 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 . . . . . . . . . 28 89 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 29 90 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 30 91 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 31 92 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 32 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 Leafs . . . . . . . . . . . . 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 . . . . . . . 43 106 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 44 107 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 45 108 9. Operational Considerations of supporting 109 RUL-leaves . . . . . . . . . . . . . . . . . . . . . . . . . 46 110 10. Operational considerations of introducing 0x23 . . . . . . . 47 111 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 49 113 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 115 14.1. Normative References . . . . . . . . . . . . . . . . . . 52 116 14.2. Informative References . . . . . . . . . . . . . . . . . 54 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 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 GUA or ULA, but could 248 use the link-local addresses) of each node. If the packet must 249 traverse multiple hops, then it must be decapsulated at each hop, and 250 then re-encapsulated again in a similar fashion. 252 Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- 253 aware-nodes send information to the root about its parents. Thus, 254 the root know the topology, then the intermediate 6LRs do not 255 maintain routing state so that source routing is needed. 257 Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes 258 (6LRs) maintain routing state (of the children) so that source 259 routing is not needed. 261 Note: Due to lack of space in some figures (tables) we refers IPv6- 262 in-IPv6 as IP6-IP6. 264 3. RPL Overview 266 RPL defines the RPL Control messages (control plane), a new ICMPv6 267 [RFC4443] message with Type 155. DIS (DODAG Information 268 Solicitation), DIO (DODAG Information Object) and DAO (Destination 269 Advertisement Object) messages are all RPL Control messages but with 270 different Code values. A RPL Stack is shown in Figure 1. 272 +--------------+ 273 | Upper Layers | 274 | | 275 +--------------+ 276 | RPL | 277 | | 278 +--------------+ 279 | ICMPv6 | 280 | | 281 +--------------+ 282 | IPv6 | 283 | | 284 +--------------+ 285 | 6LoWPAN | 286 | | 287 +--------------+ 288 | PHY-MAC | 289 | | 290 +--------------+ 292 Figure 1: RPL Stack. 294 RPL supports two modes of Downward traffic: in storing mode (SM), it 295 is fully stateful; in non-storing mode (Non-SM), it is fully source 296 routed. A RPL Instance is either fully storing or fully non-storing, 297 i.e. a RPL Instance with a combination of storing and non-storing 298 nodes is not supported with the current specifications at the time of 299 writing this document. 301 4. Updates to RFC6553, RFC6550 and RFC8138 303 4.1. Updates to RFC6550: Advertising External Routes with Non-Storing 304 Mode Signaling. 306 Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to 307 indicate that the 6LR that generates the DAO redistributes external 308 targets into the RPL network. An external Target is a Target that 309 has been learned through an alternate protocol, for instance a route 310 to a prefix that is outside the RPL domain but reachable via a 6LR. 311 Being outside of the RPL domain, a node that is reached via an 312 external target cannot be guaranteed to ignore the RPL artifacts and 313 cannot be expected to process the [RFC8138] compression correctly. 314 This means that the RPL artifacts should be contained in an IP-in-IP 315 encapsulation that is removed by the 6LR, and that any remaining 316 compression should be expanded by the 6LR before it forwards a packet 317 outside the RPL domain. 319 This specification updates [RFC6550] to RECOMMEND that external 320 targets are advertised using Non-Storing Mode DAO messaging even in a 321 Storing-Mode network. This way, external routes are not advertised 322 within the DODAG and all packets to an external target reach the Root 323 like normal Non-Storing Mode traffic. The Non-Storing Mode DAO 324 informs the Root of the address of the 6LR that injects the external 325 route, and the root uses IP-in-IP encapsulation to that 6LR, which 326 terminates the IP-in-IP tunnel and forwards the original packet 327 outside the RPL domain free of RPL artifacts. This whole operation 328 is transparent to intermediate routers that only see traffic between 329 the 6LR and the Root, and only the Root and the 6LRs that inject 330 external routes in the network need to be upgraded to add this 331 function to the network. 333 A RUL is a special case of external target when the target is 334 actually a host and it is known to support a consumed Routing Header 335 and to ignore a HbH header as prescribed by [RFC8200]. The target 336 may have been learned through as a host route or may have been 337 registered to the 6LR using [RFC8505]. IP-in-IP encapsulation MAY be 338 avoided for Root to RUL communication if the RUL is known to process 339 the packets as forwarded by the parent 6LR without decapsulation. 341 In order to enable IP-in-IP all the way to a 6LN, it is beneficial 342 that the 6LN supports decapsulating IP-in-IP, but that is not assumed 343 by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a 344 packet SHOULD terminate the tunnel at a parent 6LR unless it is aware 345 that the RUL supports IP-in-IP decapsulation. 347 A node that is reachable over an external route is not expected to 348 support [RFC8138]. Whether a decapsulation took place or not and 349 even when the 6LR is delivering the packet to a RUL, the 6LR that 350 injected an external route MUST uncompress the packet before 351 forwarding over that external route. 353 4.2. Updates to RFC6553: Indicating the new RPI Option Type. 355 This modification is required to be able to send, for example, IPv6 356 packets from a RPL-Aware-Leaf to a RPL-unaware node through Internet 357 (see Section 7.2.1), without requiring IPv6-in-IPv6 encapsulation. 359 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 360 the Option Type field of the RPL Option, the two high order bits must 361 be set to '01' and the third bit is equal to '1'. The first two bits 362 indicate that the IPv6 node must discard the packet if it doesn't 363 recognize the Option Type, and the third bit indicates that the 364 Option Data may change in route. The remaining bits serve as the 365 Option Type. 367 +-------+-------------------+----------------+-----------+ 368 | Hex | Binary Value | Description | Reference | 369 + Value +-------------------+ + + 370 | | act | chg | rest | | | 371 +-------+-----+-----+-------+----------------+-----------+ 372 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 373 +-------+-----+-----+-------+----------------+-----------+ 375 Figure 2: Option Type in RPL Option. 377 This document illustrates that is is not always possible to know for 378 sure at the source that a packet will only travel within the RPL 379 domain or may leave it. 381 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 382 the outer IPv6 header chain could potentially impact core routers in 383 the internet. So at that time, it was decided to encapsulate any 384 packet with a RPL Option using IPv6-in-IPv6 in all cases where it was 385 unclear whether the packet would remain within the RPL domain. In 386 the exception case where a packet would still leak, the Option Type 387 would ensure that the first router in the Internet that does not 388 recognize the option would drop the packet and protect the rest of 389 the network. 391 Even with [RFC8138] that compresses the IPv6-in-IPv6 header, this 392 approach yields extra bytes in a packet which means consuming more 393 energy, more bandwidth, incurring higher chances of loss and possibly 394 causing a fragmentation at the 6LoWPAN level. This impacts the daily 395 operation of constrained devices for a case that generally does not 396 happen and would not heavily impact the core anyway. 398 While intention was and remains that the Hop-by-Hop header with a RPL 399 Option should be confined within the RPL domain, this specification 400 modifies this behavior in order to reduce the dependency on IPv6-in- 401 IPv6 and protect the constrained devices. Section 4 of [RFC8200] 402 clarifies the behaviour of routers in the Internet as follows: "it is 403 now expected that nodes along a packet's delivery path only examine 404 and process the Hop-by-Hop Options header if explicitly configured to 405 do so". 407 When unclear about the travel of a packet, it becomes preferable for 408 a source not to encapsulate, accepting the fact that the packet may 409 leave the RPL domain on its way to its destination. In that event, 410 the packet should reach its destination and should not be discarded 411 by the first node that does not recognize the RPL Option. But with 412 the current value of the Option Type, if a node in the Internet is 413 configured to process the Hop-by-Hop header, and if such node 414 encounters an option with the first two bits set to 01 and conforms 415 to [RFC8200], it will drop the packet. Host systems should do the 416 same, irrespective of the configuration. 418 Thus, this document updates the Option Type of the RPL Option 419 [RFC6553], abusively naming it RPI Option Type for simplicity, to 420 (Figure 3): the two high order bits MUST be set to '00' and the third 421 bit is equal to '1'. The first two bits indicate that the IPv6 node 422 MUST skip over this option and continue processing the header 423 ([RFC8200] Section 4.2) if it doesn't recognize the Option Type, and 424 the third bit continues to be set to indicate that the Option Data 425 may change en route. The five rightmost bits remain at 0x3. This 426 ensures that a packet that leaves the RPL domain of an LLN (or that 427 leaves the LLN entirely) will not be discarded when it contains the 428 RPL Option. 430 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 431 capable) receives a packet with an RPL Option, it should ignore the 432 Hop-by-Hop RPL Option (skip over this option and continue processing 433 the header). This is relevant, as it was mentioned previously, in 434 the case that there is a flow from RAL to Internet (see 435 Section 7.2.1). 437 This is a significant update to [RFC6553]. 439 +-------+-------------------+-------------+------------+ 440 | Hex | Binary Value | Description | Reference | 441 + Value +-------------------+ + + 442 | | act | chg | rest | | | 443 +-------+-----+-----+-------+-------------+------------+ 444 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 445 +-------+-----+-----+-------+-------------+------------+ 447 Figure 3: Revised Option Type in RPL Option. (*)represents this 448 document 450 Without the signaling described below, this change would otherwise 451 create a lack of interoperation (flag day) for existing networks 452 which are currently using 0x63 as the RPI Option Type value. A move 453 to 0x23 will not be understood by those networks. It is suggested 454 that RPL implementations accept both 0x63 and 0x23 when processing 455 the header. 457 When forwarding packets, implementations SHOULD use the same value as 458 it was received. This is required because, RPI Option Type can not 459 be changed by [RFC8200] - Section 4.2. It allows to the network to 460 be incrementally upgraded, and for the DODAG root to know which parts 461 of the network are upgraded. 463 When originating new packets, implementations SHOULD have an option 464 to determine which value to originate with, this option is controlled 465 by the DIO option described below. 467 The change of RPI Option Type from 0x63 to 0x23, makes all [RFC8200] 468 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 469 therefore no longer a necessity to remove the artifacts when sending 470 traffic to the Internet. This change clarifies when to use an IPv6- 471 in-IPv6 header, and how to address them: The Hop-by-Hop Options 472 Header containing the RPI MUST always be added when 6LRs originate 473 packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST 474 always be added when a 6LR find that it needs to insert a Hop-by-Hop 475 Options Header containing the RPL Option. The IPv6-in-IPv6 header is 476 to be addressed to the RPL root when on the way up, and to the end- 477 host when on the way down. 479 In the non-storing case, dealing with not-RPL aware leaf nodes is 480 much easier as the 6LBR (DODAG root) has complete knowledge about the 481 connectivity of all DODAG nodes, and all traffic flows through the 482 root node. 484 The 6LBR can recognize not-RPL aware leaf nodes because it will 485 receive a DAO about that node from the 6LR immediately above that 486 not-RPL aware node. This means that the non-storing mode case can 487 avoid ever using hop-by-hop re-encapsulation headers for traffic 488 originating from the root to the leafs. 490 The non-storing mode case does not require the type change from 0x63 491 to 0x23, as the root can always create the right packet. The type 492 change does not adversely affect the non-storing case. 494 4.3. Updates to RFC6550: Indicating the new RPI in the DODAG 495 Configuration Option Flag. 497 In order to avoid a Flag Day caused by lack of interoperation between 498 new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this 499 section defines a flag in the DIO Configuration Option, to indicate 500 when then new RPI Option Type can be safely used. This means, the 501 flag is going to indicate the value of Option Type that the network 502 is using for the RPL Option. Thus, when a node join to a network 503 will know which value to use. With this, RPL-capable nodes know if 504 it is safe to use 0x23 when creating a new RPL Option. A node that 505 forwards a packet with an RPI MUST NOT modify the Option Type of the 506 RPL Option. 508 This is done using a DODAG Configuration Option flag which will 509 signal "RPI 0x23 enable" and propagate through the network. 510 Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) 511 in the DIO Base Object. The flag is defined only for MOP value 512 between 0 to 6. For a MOP value of 7 or above, the flag MAY indicate 513 something different and MUST NOT be interpreted as "RPI 0x23 enable" 514 unless the specification of the MOP indicates to do so. 516 As stated in [RFC6550] the DODAG Configuration option is present in 517 DIO messages. The DODAG Configuration option distributes 518 configuration information. It is generally static, and does not 519 change within the DODAG. This information is configured at the DODAG 520 root and distributed throughout the DODAG with the DODAG 521 Configuration option. Nodes other than the DODAG root do not modify 522 this information when propagating the DODAG Configuration option. 524 Currently, the DODAG Configuration Option in [RFC6550] states: "the 525 unused bits MUST be initialize to zero by the sender and MUST be 526 ignored by the receiver". If the flag is received with a value zero 527 (which is the default), then new nodes will remain in RFC6553 528 Compatible Mode; originating traffic with the old-RPI Option Type 529 (0x63) value. If the flag is received with a value of 1, then the 530 option value for the RPL Option MUST be set to 0x23. 532 Bit number three of the flag field in the DODAG Configuration option 533 is to be used as shown in Figure 4 : 535 +------------+-----------------+---------------+ 536 | Bit number | Description | Reference | 537 +------------+-----------------+---------------+ 538 | 3 | RPI 0x23 enable | This document | 539 +------------+-----------------+---------------+ 541 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 542 day. 544 In case of rebooting, the node (6LN or 6LR) does not remember the RPI 545 Option Type, that is if the flag is set, so DIO messages sent by the 546 node would be set with the flag unset until a DIO message is received 547 with the flag set indicating the new RPI Option Type. The node sets 548 to 0x23 if the node supports this feature. 550 4.4. Updates to RFC8138: Indicating the way to decompress with the new 551 RPI Option Type. 553 This modification is required to be able to decompress the RPL Option 554 with the new Option Type of 0x23. 556 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 557 in section 6. A node that is decompressing this header MUST 558 decompress using the RPI Option Type that is currently active: that 559 is, a choice between 0x23 (new) and 0x63 (old). The node will know 560 which to use based upon the presence of the flag in the DODAG 561 Configuration Option defined in Section 4.3. E.g. If the network is 562 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 564 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 565 header. 567 There are potential significant advantages to having a single code 568 path that always processes IPv6-in-IPv6 headers with no conditional 569 branches. 571 In Storing Mode, for the examples of Flow from RAL to RUL and RUL to 572 RUL comprise an IPv6-in-IPv6 and RPI compressed headers. The use of 573 the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be 574 compressed with [RFC8138] section 7. Figure 5 illustrates the case 575 in Storing mode where the packet is received from the Internet, then 576 the root encapsulates the packet to insert the RPI. In that example, 577 the leaf is not known to support RFC 8138, and the packet is 578 encapsulated to the 6LR that is the parent and last hop to the final 579 destination. 581 +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... 582 |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP 583 |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 584 +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-... 585 <-4bytes-> <- RFC 6282 -> 586 No RPL artifact 588 Figure 5: RPI Inserted by the Root in Storing Mode 590 In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the 591 Root, so it is elided in the IP-in-IP 6LoRH. The destination is the 592 parent 6LR of the destination of the inner packet so it cannot be 593 elided. It is placed as the single entry in an SRH-6LoRH as the 594 first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In 595 that example, the type is 1 so the 6LR address is compressed to 2 596 bytes. It results that the total length of the SRH-6LoRH is 4 bytes. 597 Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 598 6LoRH is removed, all the router headers that precede it are also 599 removed. The Paging Dispatch [RFC8025] may also be removed if there 600 was no previous Page change to a Page other than 0 or 1, since the 601 LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and 602 in Page 1. The resulting packet to the destination is the inner 603 packet compressed with [RFC6282]. 605 5. Sample/reference topology 607 A RPL network in general is composed of a 6LBR, Backbone Router 608 (6BBR), 6LR and 6LN as leaf logically organized in a DODAG structure. 610 Figure 6 shows the reference RPL Topology for this document. The 611 letters above the nodes are there so that they may be referenced in 612 subsequent sections. In the figure, 6LR represents a full router 613 node. The 6LN is a RPL aware router, or host (as a leaf). 614 Additionally, for simplification purposes, it is supposed that the 615 6LBR has direct access to Internet and is the root of the DODAG, thus 616 the 6BBR is not present in the figure. 618 The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no 619 children hosts. 621 The leafs marked as RUL (G and J) are devices which do not speak RPL 622 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 623 DAC and efficient-ND only to participate in the network [RFC6775]. 624 In the document these leafs (G and J) are also referred to as an IPv6 625 node. 627 The 6LBR ("A") in the figure is the root of the Global DODAG. 629 +------------+ 630 | INTERNET ----------+ 631 | | | 632 +------------+ | 633 | 634 | 635 | 636 A | 637 +-------+ 638 |6LBR | 639 +-----------|(root) |-------+ 640 | +-------+ | 641 | | 642 | | 643 | | 644 | | 645 | B |C 646 +---|---+ +---|---+ 647 | 6LR | | 6LR | 648 +---------| |--+ +--- ---+ 649 | +-------+ | | +-------+ | 650 | | | | 651 | | | | 652 | | | | 653 | | | | 654 | D | E | | 655 +-|-----+ +---|---+ | | 656 | 6LR | | 6LR | | | 657 | | +------ | | | 658 +---|---+ | +---|---+ | | 659 | | | | | 660 | | +--+ | | 661 | | | | | 662 | | | | | 663 | | | I | J | 664 F | | G | H | | 665 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 666 | RAL | | RUL | | RAL | | RAL | | RUL | 667 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 668 +-------+ +-------+ +------+ +-------+ +-------+ 670 Figure 6: A reference RPL Topology. 672 6. Use cases 674 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 675 encapsulation are going to be analyzed for a number of representative 676 traffic flows. 678 This document assumes that the LLN is using the no-drop RPI Option 679 Type of 0x23. 681 The use cases describe the communication in the following cases: - 682 Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- 683 nodes with the Internet - Between RUL nodes within the LLN (e.g. see 684 Section 7.1.4) - Inside of the LLN when the final destination address 685 resides outside of the LLN (e.g. see Section 7.2.3). 687 The uses cases are as follows: 689 Interaction between Leaf and Root: 691 RAL to root 693 root to RAL 695 RUL to root 697 root to RUL 699 Interaction between Leaf and Internet: 701 RAL to Internet 703 Internet to RAL 705 RUL to Internet 707 Internet to RUL 709 Interaction between Leafs: 711 RAL to RAL 713 RAL to RUL 715 RUL to RAL 717 RUL to RUL 719 This document is consistent with the rule that a Header cannot be 720 inserted or removed on the fly inside an IPv6 packet that is being 721 routed. This is a fundamental precept of the IPv6 architecture as 722 outlined in [RFC8200]. 724 As the rank information in the RPI artifact is changed at each hop, 725 it will typically be zero when it arrives at the DODAG root. The 726 DODAG root MUST force it to zero when passing the packet out to the 727 Internet. The Internet will therefore not see any SenderRank 728 information. 730 Despite being legal to leave the RPI artifact in place, an 731 intermediate router that needs to add an extension header (e.g. RH3 732 or RPL Option) MUST still encapsulate the packet in an (additional) 733 outer IP header. The new header is placed after this new outer IP 734 header. 736 A corollary is that an RH3 or RPL Option can only be removed by an 737 intermediate router if it is placed in an encapsulating IPv6 Header, 738 which is addressed TO the intermediate router. When it does so, the 739 whole encapsulating header must be removed. (A replacement may be 740 added). This sometimes can result in outer IP headers being 741 addressed to the next hop router using link-local address. 743 Both the RPL Option and the RH3 headers may be modified in very 744 specific ways by routers on the path of the packet without the need 745 to add and remove an encapsulating header. Both headers were 746 designed with this modification in mind, and both the RPL RH3 and the 747 RPL Option are marked mutable but recoverable: so an IPsec AH 748 security header can be applied across these headers, but it can not 749 secure the values which mutate. 751 The RPI MUST be present in every single RPL data packet. 753 Prior to [RFC8138], there was significant interest in removing the 754 RPI for downward flows in non-storing mode. The exception covered a 755 very small number of cases, and causes significant interoperability 756 challenges, yet costed significant code and testing complexity. The 757 ability to compress the RPI down to three bytes or less removes much 758 of the pressure to optimize this any further 759 [I-D.ietf-anima-autonomic-control-plane]. 761 The earlier examples are more extensive to make sure that the process 762 is clear, while later examples are more concise. 764 The uses cases are delineated based on the following requirements: 766 The RPIhas to be in every packet that traverses the LLN. 768 - Because of the previous requirement, packets from the Internet 769 have to be encapsulated. 771 - A Header cannot be inserted or removed on the fly inside an IPv6 772 packet that is being routed. 774 - Extension headers may not be added or removed except by the 775 sender or the receiver. 777 - RPI and RH3 headers may be modified by routers on the path of 778 the packet without the need to add and remove an encapsulating 779 header. 781 - An RH3 or RPL Option can only be removed by an intermediate 782 router if it is placed in an encapsulating IPv6 Header, which is 783 addressed to the intermediate router. 785 - Non-storing mode requires downstream encapsulation by root for 786 RH3. 788 The uses cases are delineated based on the following assumptions: 790 This document assumes that the LLN is using the no-drop RPI Option 791 Type (0x23). 793 - Each IPv6 node (including Internet routers) obeys [RFC8200] RFC 794 8200, so that 0x23 RPI Option type can be safely inserted. 796 - All 6LRs obey RFC 8200 [RFC8200]. 798 - The RPI is ignored at the IPv6 dst node (RUL). 800 - In the uses cases, we assume that the RAL supports IP-in-IP 801 encapsulation. 803 - In the uses cases, we dont assume that the RUL supports IP-in-IP 804 encapsulation. 806 - Non-constrained uses of RPL are not in scope of this document. 808 - Compression is based on [RFC8138]. 810 - The flow label [RFC6437] is not needed in RPL. 812 7. Storing mode 814 In storing mode (SM) (fully stateful), the sender can determine if 815 the destination is inside the LLN by looking if the destination 816 address is matched by the DIO's Prefix Information Option (PIO) 817 option. 819 The following table (Figure 7) itemizes which headers are needed in 820 each of the following scenarios. It indicates if the IPv6-in-IPv6 821 header that is added, must be addressed to the final destination (the 822 RAL node that is the target(tgt)), to the "root" or if a hop-by-hop 823 header must be added (indicated by "hop"). In the hop-by-hop basis, 824 the destination address for the next hop is the link-layer address of 825 the next hop. 827 In cases where no IPv6-in-IPv6 header is needed, the column states as 828 "No". If the IPv6-in-IPv6 header is needed is a "must". 830 In all cases the RPI is needed, since it identifies inconsistencies 831 (loops) in the routing topology. In all cases the RH3 is not needed 832 because it is not used in storing mode. 834 In each case, 6LR_i are the intermediate routers from source to 835 destination. "1 <= i <= n", n is the number of routers (6LR) that 836 the packet goes through from source (6LN) to destination. 838 The leaf can be a router 6LR or a host, both indicated as 6LN. The 839 root refers to the 6LBR (see Figure 6). 841 +---------------------+--------------+------------+------------------+ 842 | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | 843 +---------------------+--------------+------------+------------------+ 844 | | RAL to root | No | No | 845 + +--------------+------------+------------------+ 846 | Leaf - Root | root to RAL | No | No | 847 + +--------------+------------+------------------+ 848 | | root to RUL | No | No | 849 + +--------------+------------+------------------+ 850 | | RUL to root | must | hop or root | 851 +---------------------+--------------+------------+------------------+ 852 | | RAL to Int | No | No | 853 + +--------------+------------+------------------+ 854 | Leaf - Internet | Int to RAL | must | RAL (tgt) | 855 + +--------------+------------+------------------+ 856 | | RUL to Int | must | hop or root | 857 + +--------------+------------+------------------+ 858 | | Int to RUL | must | 6LR | 859 +---------------------+--------------+------------+------------------+ 860 | | RAL to RAL | No | No | 861 + +--------------+------------+------------------+ 862 | | RAL to RUL | No | No | 863 + Leaf - Leaf +--------------+------------+------------------+ 864 | | RUL to RAL | must | RAL (tgt) | 865 + +--------------+------------+------------------+ 866 | | RUL to RUL | must | 6LR | 867 +---------------------+--------------+------------+------------------+ 869 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 871 7.1. Storing Mode: Interaction between Leaf and Root 873 In this section is described the communication flow in storing mode 874 (SM) between, 876 RAL to root 878 root to RAL 880 RUL to root 882 root to RUL 884 7.1.1. SM: Example of Flow from RAL to root 886 In storing mode, RFC 6553 (RPI) is used to send RPL Information 887 instanceID and rank information. 889 In this case the flow comprises: 891 RAL (6LN) --> 6LR_i --> root(6LBR) 893 For example, a communication flow could be: Node F --> Node D --> 894 Node B --> Node A root(6LBR) 896 The RAL (Node F) inserts the RPI, and sends the packet to 6LR (Node 897 D) which decrements the rank in the RPI and sends the packet up. 898 When the packet arrives at 6LBR (Node A), the RPI is removed and the 899 packet is processed. 901 No IPv6-in-IPv6 header is required. 903 The RPI can be removed by the 6LBR because the packet is addressed to 904 the 6LBR. The RAL must know that it is communicating with the 6LBR 905 to make use of this scenario. The RAL can know the address of the 906 6LBR because it knows the address of the root via the DODAGID in the 907 DIO messages. 909 The Table 1 summarizes what headers are needed for this use case. 911 +-------------------+---------+-------+----------+ 912 | Header | RAL src | 6LR_i | 6LBR dst | 913 +-------------------+---------+-------+----------+ 914 | Inserted headers | RPI | -- | -- | 915 | Removed headers | -- | -- | RPI | 916 | Re-added headers | -- | -- | -- | 917 | Modified headers | -- | RPI | -- | 918 | Untouched headers | -- | -- | -- | 919 +-------------------+---------+-------+----------+ 921 Table 1: SM: Summary of the use of headers from RAL to root 923 7.1.2. SM: Example of Flow from root to RAL 925 In this case the flow comprises: 927 root (6LBR) --> 6LR_i --> RAL (6LN) 929 For example, a communication flow could be: Node A root(6LBR) --> 930 Node B --> Node D --> Node F 931 In this case the 6LBR inserts RPI and sends the packet down, the 6LR 932 is going to increment the rank in RPI (it examines the instanceID to 933 identify the right forwarding table), the packet is processed in the 934 RAL and the RPI removed. 936 No IPv6-in-IPv6 header is required. 938 The Table 2 summarizes what headers are needed for this use case. 940 +-------------------+----------+-------+---------+ 941 | Header | 6LBR src | 6LR_i | RAL dst | 942 +-------------------+----------+-------+---------+ 943 | Inserted headers | RPI | -- | -- | 944 | Removed headers | -- | -- | RPI | 945 | Re-added headers | -- | -- | -- | 946 | Modified headers | -- | RPI | -- | 947 | Untouched headers | -- | -- | -- | 948 +-------------------+----------+-------+---------+ 950 Table 2: SM: Summary of the use of headers from root to RAL 952 7.1.3. SM: Example of Flow from root to RUL 954 In this case the flow comprises: 956 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 958 For example, a communication flow could be: Node A root(6LBR) --> 959 Node B --> Node E --> Node G 961 As the RPI extension can be ignored by the RUL, this situation is 962 identical to the previous scenario. 964 The Table 3 summarizes what headers are needed for this use case. 966 +-------------------+----------+-------+----------------------+ 967 | Header | 6LBR src | 6LR_i | RUL (IPv6 dst node) | 968 +-------------------+----------+-------+----------------------+ 969 | Inserted headers | RPI | -- | -- | 970 | Removed headers | -- | -- | -- | 971 | Re-added headers | -- | -- | -- | 972 | Modified headers | -- | RPI | -- | 973 | Untouched headers | -- | -- | RPI (Ignored) | 974 +-------------------+----------+-------+----------------------+ 976 Table 3: SM: Summary of the use of headers from root to RUL 978 7.1.4. SM: Example of Flow from RUL to root 980 In this case the flow comprises: 982 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) 984 For example, a communication flow could be: Node G --> Node E --> 985 Node B --> Node A root(6LBR) 987 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 988 the 6LR_1 will insert a RPI, encapsulated in a IPv6-in-IPv6 header. 989 The IPv6-in-IPv6 header can be addressed to the next hop (Node B), or 990 to the root (Node A). The root removes the header and processes the 991 packet. 993 The Figure 8 shows the table that summarizes what headers are needed 994 for this use case. [1] refers the case where the IPv6-in-IPv6 header 995 is addressed to the next hop (Node B). [2] refers the case where the 996 IPv6-in-IPv6 header is addressed to the root (Node A). 998 +-----------+------+--------------+-----------------+------------------+ 999 | Header | RUL | 6LR_1 | 6LR_i | 6LBR dst | 1000 | | src | | | | 1001 | | node | | | | 1002 +-----------+------+--------------+-----------------+------------------+ 1003 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | 1004 | headers | | | | | 1005 +-----------+------+--------------+-----------------+------------------+ 1006 | Removed | -- | -- | IP6-IP6(RPI)[1] |IP6-IP6(RPI)[1][2]| 1007 | headers | | | | | 1008 +-----------+------+--------------+-----------------+------------------+ 1009 | Re-added | -- | -- | -- | -- | 1010 | headers | | | | | 1011 +-----------+------+--------------+-----------------+------------------+ 1012 | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | 1013 | headers | | | | | 1014 +-----------+------+--------------+-----------------+------------------+ 1015 | Untouched | -- | -- | -- | -- | 1016 | headers | | | | | 1017 +-----------+------+--------------+-----------------+------------------+ 1019 Figure 8: SM: Summary of the use of headers from RUL to root. 1021 7.2. SM: Interaction between Leaf and Internet. 1023 In this section is described the communication flow in storing mode 1024 (SM) between, 1025 RAL to Internet 1027 Internet to RAL 1029 RUL to Internet 1031 Internet to RUL 1033 7.2.1. SM: Example of Flow from RAL to Internet 1035 RPL information from RFC 6553 may go out to Internet as it will be 1036 ignored by nodes which have not been configured to be RPI aware. 1038 In this case the flow comprises: 1040 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 1042 For example, the communication flow could be: Node F --> Node D --> 1043 Node B --> Node A root(6LBR) --> Internet 1045 No IPv6-in-IPv6 header is required. 1047 Note: In this use case it is used a node as leaf, but this use case 1048 can be also applicable to any RPL-aware-node type (e.g. 6LR) 1050 The Table 4 summarizes what headers are needed for this use case. 1052 +-------------------+---------+-------+------+----------------+ 1053 | Header | RAL src | 6LR_i | 6LBR | Internet dst | 1054 +-------------------+---------+-------+------+----------------+ 1055 | Inserted headers | RPI | -- | -- | -- | 1056 | Removed headers | -- | -- | -- | -- | 1057 | Re-added headers | -- | -- | -- | -- | 1058 | Modified headers | -- | RPI | -- | -- | 1059 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1060 +-------------------+---------+-------+------+----------------+ 1062 Table 4: SM: Summary of the use of headers from RAL to Internet 1064 7.2.2. SM: Example of Flow from Internet to RAL 1066 In this case the flow comprises: 1068 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 1070 For example, a communication flow could be: Internet --> Node A 1071 root(6LBR) --> Node B --> Node D --> Node F 1072 When the packet arrives from Internet to 6LBR the RPI is added in a 1073 outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address 1074 set to the RAL) and sent to 6LR, which modifies the rank in the RPI. 1075 When the packet arrives at the RAL the RPI is removed and the packet 1076 processed. 1078 The Figure 9 shows the table that summarizes what headers are needed 1079 for this use case. 1081 +-----------+----------+--------------+--------------+--------------+ 1082 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1083 | | src | | | | 1084 +-----------+----------+--------------+--------------+--------------+ 1085 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 1086 | headers | | | | | 1087 +-----------+----------+--------------+--------------+--------------+ 1088 | Removed | -- | -- | -- | IP6-IP6(RPI) | 1089 | headers | | | | | 1090 +-----------+----------+--------------+--------------+--------------+ 1091 | Re-added | -- | -- | -- | -- | 1092 | headers | | | | | 1093 +-----------+----------+--------------+--------------+--------------+ 1094 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1095 | headers | | | | | 1096 +-----------+----------+--------------+--------------+--------------+ 1097 | Untouched | -- | -- | -- | -- | 1098 | headers | | | | | 1099 +-----------+----------+--------------+--------------+--------------+ 1101 Figure 9: SM: Summary of the use of headers from Internet to RAL. 1103 7.2.3. SM: Example of Flow from RUL to Internet 1105 In this case the flow comprises: 1107 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1109 For example, a communication flow could be: Node G --> Node E --> 1110 Node B --> Node A root(6LBR) --> Internet 1112 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 1113 either to the root, or hop-by-hop such that the root can remove the 1114 RPI before passing upwards. The IPv6-in-IPv6 addressed to the root 1115 cause less processing overhead. On the other hand, with hop-by-hop 1116 the intermediate routers can check the routing tables for a better 1117 routing path, thus it could be more efficient and faster. 1118 Implementation should decide which approach to take. 1120 The originating node will ideally leave the IPv6 flow label as zero 1121 so that the packet can be better compressed through the LLN. The 1122 6LBR will set the flow label of the packet to a non-zero value when 1123 sending to the Internet, for details check [RFC6437]. 1125 The Figure 10 shows the table that summarizes what headers are needed 1126 for this use case. In the table, [1] shows the case when packet is 1127 addressed to the root. [2] shows the case when the packet is 1128 addressed hop-by-hop. 1130 +---------+-------+------------+--------------+-------------+--------+ 1131 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1132 | | src | | [i=2,...,n] | | dst | 1133 | | node | | | | | 1134 | | (RUL) | | | | | 1135 +---------+-------+------------+--------------+-------------+--------+ 1136 | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | 1137 | headers | | | [2] | | | 1138 +---------+-------+------------+--------------+-------------+--------+ 1139 | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | 1140 | headers | | | [2] | [1][2] | | 1141 +---------+-------+------------+--------------+-------------+--------+ 1142 | Re-added| -- | -- | -- | -- | -- | 1143 | headers | | | | | | 1144 +---------+-------+------------+--------------+-------------+--------+ 1145 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1146 | headers | | | [1] | | | 1147 +---------+-------+------------+--------------+-------------+--------+ 1148 |Untouched| -- | -- | -- | -- | -- | 1149 | headers | | | | | | 1150 +---------+-------+------------+--------------+-------------+--------+ 1152 Figure 10: SM: Summary of the use of headers from RUL to Internet. 1154 7.2.4. SM: Example of Flow from Internet to RUL. 1156 In this case the flow comprises: 1158 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1160 For example, a communication flow could be: Internet --> Node A 1161 root(6LBR) --> Node B --> Node E --> Node G 1163 The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The 1164 IPv6-in-IPv6 is addressed to the 6LR parent of the 6lR_i. 1166 Further details about this are mentioned in 1167 [I-D.ietf-roll-unaware-leaves], which specifies RPL routing for a 6LN 1168 acting as a plain host and not being aware of RPL. 1170 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1171 zero in order to aid in compression [RFC8138][RFC6437]. 1173 The Figure 11 shows the table that summarizes what headers are needed 1174 for this use case. 1176 +-----------+----------+--------------+--------------+--------------+ 1177 | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | 1178 | | src | | | | 1179 +-----------+----------+--------------+--------------+--------------+ 1180 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- | 1181 | headers | | | | | 1182 +-----------+----------+--------------+--------------+--------------+ 1183 | Removed | -- | -- | IP6-IP6(RPI) | -- | 1184 | headers | | | | | 1185 +-----------+----------+--------------+--------------+--------------+ 1186 | Re-added | -- | -- | -- | -- | 1187 | headers | | | | | 1188 +-----------+----------+--------------+--------------+--------------+ 1189 | Modified | -- | -- | -- | -- | 1190 | headers | | | | | 1191 +-----------+----------+--------------+--------------+--------------+ 1192 | Untouched | -- | -- | -- | -- | 1193 | headers | | | | | 1194 +-----------+----------+--------------+--------------+--------------+ 1196 Figure 11: SM: Summary of the use of headers from Internet to RUL. 1198 7.3. SM: Interaction between Leaf and Leaf 1200 In this section is described the communication flow in storing mode 1201 (SM) between, 1203 RAL to RAL 1205 RAL to RUL 1207 RUL to RAL 1209 RUL to RUL 1211 7.3.1. SM: Example of Flow from RAL to RAL 1213 In [RFC6550] RPL allows a simple one-hop optimization for both 1214 storing and non-storing networks. A node may send a packet destined 1215 to a one-hop neighbor directly to that node. See section 9 in 1216 [RFC6550]. 1218 When the nodes are not directly connected, then in storing mode, the 1219 flow comprises: 1221 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL 1222 dst (6LN) 1224 For example, a communication flow could be: Node F --> Node D --> 1225 Node B --> Node E --> Node H 1227 6LR_ia (Node D) are the intermediate routers from source to the 1228 common parent (6LR_x) (Node B). In this case, 1 <= ia <= n, n is the 1229 number of routers (6LR) that the packet goes through from RAL (Node 1230 F) to the common parent 6LR_x (Node B). 1232 6LR_id (Node E) are the intermediate routers from the common parent 1233 (6LR_x) (Node B) to destination RAL (Node H). In this case, 1 <= id 1234 <= m, m is the number of routers (6LR) that the packet goes through 1235 from the common parent (6LR_x) to destination RAL (Node H). 1237 It is assumed that the two nodes are in the same RPL Domain (that 1238 they share the same DODAG root). At the common parent (Node B), the 1239 direction of RPI is changed (from decreasing to increasing the rank). 1241 While the 6LR nodes will update the RPI, no node needs to add or 1242 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1244 The Table 5 summarizes what headers are needed for this use case. 1246 +---------------+--------+--------+---------------+--------+--------+ 1247 | Header | RAL | 6LR_ia | 6LR_x (common | 6LR_id | RAL | 1248 | | src | | parent) | | dst | 1249 +---------------+--------+--------+---------------+--------+--------+ 1250 | Inserted | RPI | -- | -- | -- | -- | 1251 | headers | | | | | | 1252 | Removed | -- | -- | -- | -- | RPI | 1253 | headers | | | | | | 1254 | Re-added | -- | -- | -- | -- | -- | 1255 | headers | | | | | | 1256 | Modified | -- | RPI | RPI | RPI | -- | 1257 | headers | | | | | | 1258 | Untouched | -- | -- | -- | -- | -- | 1259 | headers | | | | | | 1260 +---------------+--------+--------+---------------+--------+--------+ 1262 Table 5: SM: Summary of the use of headers for RAL to RAL 1264 7.3.2. SM: Example of Flow from RAL to RUL 1266 In this case the flow comprises: 1268 RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RUL 1269 (IPv6 dst node) 1271 For example, a communication flow could be: Node F --> Node D --> 1272 Node B --> Node E --> Node G 1274 6LR_ia are the intermediate routers from source (RAL) to the common 1275 parent (6LR_x) In this case, 1 <= ia <= n, n is the number of routers 1276 (6LR) that the packet goes through from RAL to the common parent 1277 (6LR_x). 1279 6LR_id (Node E) are the intermediate routers from the common parent 1280 (6LR_x) (Node B) to destination RUL (Node G). In this case, 1 <= id 1281 <= m, m is the number of routers (6LR) that the packet goes through 1282 from the common parent (6LR_x) to destination RUL. 1284 This situation is identical to the previous situation Section 7.3.1 1286 The Table 6 summarizes what headers are needed for this use case. 1288 +-----------+------+--------+---------------+--------+--------------+ 1289 | Header | RAL | 6LR_ia | 6LR_x(common | 6LR_id | RUL dst | 1290 | | src | | parent) | | | 1291 +-----------+------+--------+---------------+--------+--------------+ 1292 | Inserted | RPI | -- | -- | -- | -- | 1293 | headers | | | | | | 1294 | Removed | -- | -- | -- | -- | -- | 1295 | headers | | | | | | 1296 | Re-added | -- | -- | -- | -- | -- | 1297 | headers | | | | | | 1298 | Modified | -- | RPI | RPI | RPI | -- | 1299 | headers | | | | | | 1300 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1301 | headers | | | | | | 1302 +-----------+------+--------+---------------+--------+--------------+ 1304 Table 6: SM: Summary of the use of headers for RAL to RUL 1306 7.3.3. SM: Example of Flow from RUL to RAL 1308 In this case the flow comprises: 1310 RUL (IPv6 src node) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id 1311 --> RAL dst (6LN) 1313 For example, a communication flow could be: Node G --> Node E --> 1314 Node B --> Node D --> Node F 1316 6LR_ia (Node E) are the intermediate routers from source (RUL) (Node 1317 G) to the common parent (6LR_x) (Node B). In this case, 1 <= ia <= 1318 n, n is the number of routers (6LR) that the packet goes through from 1319 source to the common parent. 1321 6LR_id (Node D) are the intermediate routers from the common parent 1322 (6LR_x) (Node B) to destination RAL (Node F). In this case, 1 <= id 1323 <= m, m is the number of routers (6LR) that the packet goes through 1324 from the common parent (6LR_x) to the destination RAL. 1326 The 6LR_ia (ia=1) (Node E) receives the packet from the RUL (Node G) 1327 and inserts the RPI encapsulated in a IPv6-in-IPv6 header. The IPv6- 1328 in-IPv6 header is addressed to the destination RAL (Node F). 1330 The Figure 12 shows the table that summarizes what headers are needed 1331 for this use case. 1333 +---------+-----+------------+-------------+-------------+------------+ 1334 | Header |RUL | 6LR_ia | Common | 6LR_id | RAL | 1335 | |src | | Parent | | dst | 1336 | |node | | (6LRx) | | | 1337 +---------+-----+------------+-------------+-------------+------------+ 1338 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1339 | headers | | | | | | 1340 +---------+-----+------------+-------------+-------------+------------+ 1341 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1342 | headers | | | | | | 1343 +---------+-----+------------+-------------+-------------+------------+ 1344 | Re-added| -- | -- | -- | -- | -- | 1345 | headers | | | | | | 1346 +---------+-----+------------+-------------+-------------+------------+ 1347 | Modified| -- | -- |IP6-IP6(RPI) |IP6-IP6(RPI) | -- | 1348 | headers | | | | | | 1349 +---------+-----+------------+-------------+-------------+------------+ 1350 |Untouched| -- | -- | -- | -- | -- | 1351 | headers | | | | | | 1352 +---------+-----+------------+-------------+-------------+------------+ 1354 Figure 12: SM: Summary of the use of headers from RUL to RAL. 1356 7.3.4. SM: Example of Flow from RUL to RUL 1358 In this case the flow comprises: 1360 RUL (IPv6 src node)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> RUL 1361 (IPv6 dst node) 1363 For example, a communication flow could be: Node G --> Node E --> 1364 Node B --> Node A (root) --> Node C --> Node J 1366 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1367 router from the RUL source (Node G) to the root (6LBR) (Node A). In 1368 this case, "1 < ia <= n", n is the number of routers (6LR) that the 1369 packet goes through from the RUL to the root. 1371 6LR_id (Node C) are the intermediate routers from the root (Node A) 1372 to the destination RUL dst node (Node J). In this case, 1 <= id <= 1373 m, m is the number of routers (6LR) that the packet goes through from 1374 the root to destination RUL. 1376 The RPI is ignored at the RUL dst node. 1378 The 6LR_1 (Node E) receives the packet from the RUL (Node G) and 1379 inserts the RPI (RPI), encapsulated in an IPv6-in-IPv6 header 1380 directed to the root. The root removes the RPI and inserts a new RPI 1381 addressed to the 6LR father of the RUL. 1383 The Figure 13 shows the table that summarizes what headers are needed 1384 for this use case. 1386 +---------+------+-------+-------+---------+-------+-------+ 1387 | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | RUL | 1388 | | src | | | | | dst | 1389 | | node | | | | | node | 1390 +---------+------+-------+-------+---------+-------+-------+ 1391 | Inserted| -- |IP6-IP6|IP6-IP6| IP6-IP6 |IP6-IP6| -- | 1392 | headers | | (RPI )| (RPI) | (RPI2) | (RPI2)| | 1393 | | | | | | | | 1394 +---------+------+-------+-------+---------+-------+-------+ 1395 | Removed | -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| | 1396 | headers | | | (RPI) | (RPI1) | (RPI2)| | 1397 | | | | | | | | 1398 | | | | | | | | 1399 +---------+------+-------+-------+---------+-------+-------+ 1400 | Re-added| -- | -- | -- | -- | -- | -- | 1401 | headers | | | | | | | 1402 +---------+------+-------+-------+---------+-------+-------+ 1403 | Modified| -- | -- | | | | -- | 1404 | headers | | | | | | | 1405 | | | | | | | | 1406 +---------+------+-------+-------+---------+-------+-------+ 1407 |Untouched| -- | -- | -- | -- | -- | -- | 1408 | headers | | | | | | | 1409 +---------+------+-------+-------+---------+-------+-------+ 1411 Figure 13: SM: Summary of the use of headers from RUL to RUL 1413 8. Non Storing mode 1415 In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG 1416 root) has complete knowledge about the connectivity of all DODAG 1417 nodes, and all traffic flows through the root node. Thus, there is 1418 no need for all nodes to know about the existence of RPL-unaware 1419 nodes. Only the 6LBR needs to act if compensation is necessary for 1420 not-RPL aware receivers. 1422 The table (Figure 14) summarizes what headers are needed in the 1423 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 1424 header are to be inserted. It depicts the target destination address 1425 possible to a 6LN (indicated by "RAL"), to a 6LR (parent of a 6LN) or 1426 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1427 column states as "No". There is no expectation on RPL that RPI can 1428 be omitted, because it is needed for routing, quality of service and 1429 compression. This specification expects that is always a RPI 1430 Present. 1432 The leaf can be a router 6LR or a host, both indicated as 6LN 1433 (Figure 6). In the table (Figure 14) the (1) indicates a 6tisch case 1434 [RFC8180], where the RPI may still be needed for the instanceID to be 1435 available for priority/channel selection at each hop. 1437 +-----------------+--------------+-----+-----+------------+------------+ 1438 | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| 1439 | between | | | | | dst | 1440 +-----------------+--------------+-----+-----+------------+------------+ 1441 | | RAL to root | Yes | No | No | No | 1442 + +--------------+-----+-----+------------+------------+ 1443 | Leaf - Root | root to RAL | Yes | Yes | No | No | 1444 + +--------------+-----+-----+------------+------------+ 1445 | | root to RUL | Yes | Yes | must | 6LR | 1446 | | | (1) | | | | 1447 + +--------------+-----+-----+------------+------------+ 1448 | | RUL to root | Yes | No | must | root | 1449 +-----------------+--------------+-----+-----+------------+------------+ 1450 | | RAL to Int | Yes | No | No | No | 1451 + +--------------+-----+-----+------------+------------+ 1452 | Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | 1453 + +--------------+-----+-----+------------+------------+ 1454 | | RUL to Int | Yes | No | must | root | 1455 + +--------------+-----+-----+------------+------------+ 1456 | | Int to RUL | Yes | Yes | must | 6LR | 1457 +-----------------+--------------+-----+-----+------------+------------+ 1458 | | RAL to RAL | Yes | Yes | must | root/RAL | 1459 + +--------------+-----+-----+------------+------------+ 1460 | | RAL to RUL | Yes | Yes | must | root/6LR | 1461 + Leaf - Leaf +--------------+-----+-----+------------+------------+ 1462 | | RUL to RAL | Yes | Yes | must | root/RAL | 1463 + +--------------+-----+-----+------------+------------+ 1464 | | RUL to RUL | Yes | Yes | must | root/6LR | 1465 +-----------------+--------------+-----+-----+------------+------------+ 1467 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1468 RH3, IPv6-in-IPv6 encapsulation. 1470 8.1. Non-Storing Mode: Interaction between Leaf and Root 1472 In this section is described the communication flow in Non Storing 1473 Mode (Non-SM) between, 1475 RAL to root 1476 root to RAL 1478 RUL to root 1480 root to RUL 1482 8.1.1. Non-SM: Example of Flow from RAL to root 1484 In non-storing mode the leaf node uses default routing to send 1485 traffic to the root. The RPI must be included since it contains the 1486 rank information, which is used to avoid/detect loops. 1488 RAL (6LN) --> 6LR_i --> root(6LBR) 1490 For example, a communication flow could be: Node F --> Node D --> 1491 Node B --> Node A (root) 1493 6LR_i are the intermediate routers from source to destination. In 1494 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1495 packet goes through from source (RAL) to destination (6LBR). 1497 This situation is the same case as storing mode. 1499 The Table 7 summarizes what headers are needed for this use case. 1501 +-------------------+---------+-------+----------+ 1502 | Header | RAL src | 6LR_i | 6LBR dst | 1503 +-------------------+---------+-------+----------+ 1504 | Inserted headers | RPI | -- | -- | 1505 | Removed headers | -- | -- | RPI | 1506 | Re-added headers | -- | -- | -- | 1507 | Modified headers | -- | RPI | -- | 1508 | Untouched headers | -- | -- | -- | 1509 +-------------------+---------+-------+----------+ 1511 Table 7: Non-SM: Summary of the use of headers from RAL to root 1513 8.1.2. Non-SM: Example of Flow from root to RAL 1515 In this case the flow comprises: 1517 root (6LBR) --> 6LR_i --> RAL (6LN) 1519 For example, a communication flow could be: Node A (root) --> Node B 1520 --> Node D --> Node F 1521 6LR_i are the intermediate routers from source to destination. In 1522 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1523 packet goes through from source (6LBR) to destination (RAL). 1525 The 6LBR inserts an RH3, and a RPI. No IPv6-in-IPv6 header is 1526 necessary as the traffic originates with an RPL aware node, the 6LBR. 1527 The destination is known to be RPL-aware because the root knows the 1528 whole topology in non-storing mode. 1530 The Table 8 summarizes what headers are needed for this use case. 1532 +-------------------+----------+-----------+-----------+ 1533 | Header | 6LBR src | 6LR_i | RAL dst | 1534 +-------------------+----------+-----------+-----------+ 1535 | Inserted headers | RPI, RH3 | -- | -- | 1536 | Removed headers | -- | -- | RH3, RPI | 1537 | Re-added headers | -- | -- | -- | 1538 | Modified headers | -- | RPI, RH3 | -- | 1539 | Untouched headers | -- | -- | -- | 1540 +-------------------+----------+-----------+-----------+ 1542 Table 8: Non-SM: Summary of the use of headers from root to RAL 1544 8.1.3. Non-SM: Example of Flow from root to RUL 1546 In this case the flow comprises: 1548 root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1550 For example, a communication flow could be: Node A (root) --> Node B 1551 --> Node E --> Node G 1553 6LR_i are the intermediate routers from source to destination. In 1554 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1555 packet goes through from source (6LBR) to destination (RUL). 1557 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1558 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1559 but left there. As the RPI is added, then the IPv6 node which does 1560 not understand the RPI, will ignore it (following RFC8200), thus 1561 encapsulation is not necessary. 1563 The Figure 15 depicts the table that summarizes what headers are 1564 needed for this use case. 1566 +-----------+----------+--------------+----------------+----------+ 1567 | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | 1568 | | | i=(1,..,n-1) | |dst node | 1569 | | | | | (RUL) | 1570 +-----------+----------+--------------+----------------+----------+ 1571 | Inserted | RPI, RH3 | -- | -- | -- | 1572 | headers | | | | | 1573 +-----------+----------+--------------+----------------+----------+ 1574 | Removed | -- | -- | | -- | 1575 | headers | | | | | 1576 +-----------+----------+--------------+----------------+----------+ 1577 | Re-added | -- | -- | -- | -- | 1578 | headers | | | | | 1579 +-----------+----------+--------------+----------------+----------+ 1580 | Modified | -- | RPI, RH3 | RPI, | -- | 1581 | headers | | | RH3(consumed) | | 1582 +-----------+----------+--------------+----------------+----------+ 1583 | Untouched | -- | -- | -- | RPI, RH3 | 1584 | headers | | | | (both | 1585 | | | | | ignored) | 1586 +-----------+----------+--------------+----------------+----------+ 1588 Figure 15: Non-SM: Summary of the use of headers from root to RUL 1590 8.1.4. Non-SM: Example of Flow from RUL to root 1592 In this case the flow comprises: 1594 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dst 1596 For example, a communication flow could be: Node G --> Node E --> 1597 Node B --> Node A (root) 1599 6LR_i are the intermediate routers from source to destination. In 1600 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1601 packet goes through from source (RUL) to destination (6LBR). For 1602 example, 6LR_1 (i=1) is the router that receives the packets from the 1603 IPv6 node. 1605 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1606 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1607 following 6LRs. The RPI and the entire packet is consumed by the 1608 root. 1610 The Figure 16 shows the table that summarizes what headers are needed 1611 for this use case. 1613 +---------+----+-----------------+-----------------+-----------------+ 1614 | |RUL | | | | 1615 | Header |src | 6LR_1 | 6LR_i | 6LBR dst | 1616 | |node| | | | 1617 +---------+----+-----------------+-----------------+-----------------+ 1618 | Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- | 1619 | headers | | | | | 1620 +---------+----+-----------------+-----------------+-----------------+ 1621 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1622 | headers | | | | | 1623 +---------+----+-----------------+-----------------+-----------------+ 1624 | Re-added| -- | -- | -- | -- | 1625 | headers | | | | | 1626 +---------+----+-----------------+-----------------+-----------------+ 1627 | Modified| -- | -- |IPv6-in-IPv6(RPI)| -- | 1628 | headers | | | | | 1629 +---------+----+-----------------+-----------------+-----------------+ 1630 |Untouched| -- | -- | -- | -- | 1631 | headers | | | | | 1632 +---------+----+-----------------+-----------------+-----------------+ 1634 Figure 16: Non-SM: Summary of the use of headers from RUL to root 1636 8.2. Non-Storing Mode: Interaction between Leaf and Internet 1638 This section will describe the communication flow in Non Storing Mode 1639 (Non-SM) between: 1641 RAL to Internet 1643 Internet to RAL 1645 RUL to Internet 1647 Internet to RUL 1649 8.2.1. Non-SM: Example of Flow from RAL to Internet 1651 In this case the flow comprises: 1653 RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dst 1655 For example, a communication flow could be: Node F --> Node D --> 1656 Node B --> Node A --> Internet 1658 6LR_i are the intermediate routers from source to destination. In 1659 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1660 packet goes through from source (RAL) to 6LBR. 1662 This case is identical to storing-mode case. 1664 The IPv6 flow label should be set to zero to aid in compression 1665 [RFC8138], and the 6LBR will set it to a non-zero value when sending 1666 towards the Internet [RFC6437]. 1668 The Table 9 summarizes what headers are needed for this use case. 1670 +-------------------+---------+-------+------+----------------+ 1671 | Header | RAL src | 6LR_i | 6LBR | Internet dst | 1672 +-------------------+---------+-------+------+----------------+ 1673 | Inserted headers | RPI | -- | -- | -- | 1674 | Removed headers | -- | -- | -- | -- | 1675 | Re-added headers | -- | -- | -- | -- | 1676 | Modified headers | -- | RPI | -- | -- | 1677 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1678 +-------------------+---------+-------+------+----------------+ 1680 Table 9: Non-SM: Summary of the use of headers from RAL to Internet 1682 8.2.2. Non-SM: Example of Flow from Internet to RAL 1684 In this case the flow comprises: 1686 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 1691 6LR_i are the intermediate routers from source to destination. In 1692 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 an 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 10 summarizes what headers are needed for this use case. 1702 +-----------+----------+--------------+--------------+--------------+ 1703 | Header | Internet | 6LBR | 6LR_i | RAL dst | 1704 | | src | | | | 1705 +-----------+----------+--------------+--------------+--------------+ 1706 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1707 | headers | | (RH3,RPI) | | | 1708 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1709 | headers | | | | (RH3,RPI) | 1710 | Re-added | -- | -- | -- | -- | 1711 | headers | | | | | 1712 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1713 | headers | | | (RH3,RPI) | | 1714 | Untouched | -- | -- | -- | -- | 1715 | headers | | | | | 1716 +-----------+----------+--------------+--------------+--------------+ 1718 Table 10: Non-SM: Summary of the use of headers from Internet to RAL 1720 8.2.3. Non-SM: Example of Flow from RUL to Internet 1722 In this case the flow comprises: 1724 RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1725 dst 1727 For example, a communication flow could be: Node G --> Node E --> 1728 Node B --> Node A --> Internet 1730 6LR_i are the intermediate routers from source to destination. In 1731 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1732 packet goes through from source (RUL) to 6LBR, e.g. 6LR_1 (i=1). 1734 In this case the flow label is recommended to be zero in the IPv6 1735 node. As RPL headers are added in the IPv6 node packet, the first 1736 6LR (6LR_1) will add a RPI inside a new IPv6-in-IPv6 header. The 1737 IPv6-in-IPv6 header will be addressed to the root. This case is 1738 identical to the storing-mode case (see Section 7.2.3). 1740 The Figure 17 shows the table that summarizes what headers are needed 1741 for this use case. 1743 +---------+----+-------------+--------------+--------------+--------+ 1744 | Header |RUL | 6LR_1 | 6LR_i | 6LBR |Internet| 1745 | |src | | [i=2,..,n] | | dst | 1746 | |node| | | | | 1747 +---------+----+-------------+--------------+--------------+--------+ 1748 | Inserted| -- |IP6-IP6(RPI) | -- | -- | -- | 1749 | headers | | | | | | 1750 +---------+----+-------------+--------------+--------------+--------+ 1751 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1752 | headers | | | | | | 1753 +---------+----+-------------+--------------+--------------+--------+ 1754 | Re-added| -- | -- | -- | -- | -- | 1755 | headers | | | | | | 1756 +---------+----+-------------+--------------+--------------+--------+ 1757 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1758 | headers | | | | | | 1759 +---------+----+-------------+--------------+--------------+--------+ 1760 |Untouched| -- | -- | -- | -- | -- | 1761 | headers | | | | | | 1762 +---------+----+-------------+--------------+--------------+--------+ 1764 Figure 17: Non-SM: Summary of the use of headers from RUL to Internet 1766 8.2.4. Non-SM: Example of Flow from Internet to RUL 1768 In this case the flow comprises: 1770 Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) 1772 For example, a communication flow could be: Internet --> Node A 1773 (root) --> Node B --> Node E --> Node G 1775 6LR_i are the intermediate routers from source to destination. In 1776 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1777 packet goes through from 6LBR to RUL. 1779 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1780 6LBR will know the path, and will recognize that the final node is 1781 not an RPL capable node as it will have received the connectivity DAO 1782 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1783 header destination be the last 6LR. The 6LBR will set to zero the 1784 flow label upon entry in order to aid compression [RFC8138]. 1786 The Figure 18 shows the table that summarizes what headers are needed 1787 for this use case. 1789 +---------+--------+-------------+--------------+--------------+-----+ 1790 | Header |Internet| 6LBR | 6LR_1 | 6lR_i |RUL | 1791 | | src | | | (i=2,...,n) |dst | 1792 | | | | | |node | 1793 +---------+--------+-------------+--------------+--------------+-----+ 1794 | Inserted| -- | IPv6-in-IPv6| -- | -- | -- | 1795 | headers | | (RH3,RPI) | | | | 1796 +---------+--------+-------------+--------------+--------------+-----+ 1797 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1798 | headers | | | | (RH3,RPI)[1] | | 1799 +---------+--------+-------------+--------------+--------------+-----+ 1800 | Re-added| -- | -- | -- | -- | -- | 1801 | headers | | | | | | 1802 +---------+--------+-------------+--------------+--------------+-----+ 1803 | Modified| -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1804 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1805 +---------+--------+-------------+--------------+--------------+-----+ 1806 |Untouched| -- | -- | -- | -- | -- | 1807 | headers | | | | | | 1808 +---------+--------+-------------+--------------+--------------+-----+ 1810 Figure 18: Non-SM: Summary of the use of headers from Internet to RUL 1811 [1] The last 6LR before the IPv6 node. 1813 8.3. Non-SM: Interaction between Leafs 1815 In this section is described the communication flow in Non Storing 1816 Mode (Non-SM) between, 1818 RAL to RAL 1820 RAL to RUL 1822 RUL to RAL 1824 RUL to RUL 1826 8.3.1. Non-SM: Example of Flow from RAL to RAL 1828 In this case the flow comprises: 1830 RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst 1832 For example, a communication flow could be: Node F --> Node D --> 1833 Node B --> Node A (root) --> Node B --> Node E --> Node H 1834 6LR_ia are the intermediate routers from source to the root In this 1835 case, 1 <= ia <= n, n is the number of routers (6LR) that the packet 1836 goes through from RAL to the root. 1838 6LR_id are the intermediate routers from the root to the destination. 1839 In this case, "1 <= ia <= m", m is the number of the intermediate 1840 routers (6LR). 1842 This case involves only nodes in same RPL Domain. The originating 1843 node will add a RPI to the original packet, and send the packet 1844 upwards. 1846 The originating node must put the RPI (RPI1) into an IPv6-in-IPv6 1847 header addressed to the root, so that the 6LBR can remove that 1848 header. If it does not, then additional resources are wasted on the 1849 way down to carry the useless RPI. 1851 The 6LBR will need to insert an RH3 header, which requires that it 1852 add an IPv6-in-IPv6 header. It should be able to remove the 1853 RPI(RPI1), as it was contained in an IPv6-in-IPv6 header addressed to 1854 it. Otherwise, there may be a RPI buried inside the inner IP header, 1855 which should get ignored. The root inserts a RPI (RPI2) alongside 1856 the RH3. 1858 Networks that use the RPL P2P extension [RFC6997] are essentially 1859 non-storing DODAGs and fall into this scenario or scenario 1860 Section 8.1.2, with the originating node acting as 6LBR. 1862 The Figure 19 shows the table that summarizes what headers are needed 1863 for this use case. 1865 +---------+------------+----------+------------+----------+------------+ 1866 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL | 1867 | | src | | | | dst | 1868 +---------+------------+----------+------------+----------+------------+ 1869 | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | 1870 | headers | (RPI1) | |(RH3-> RAL, | | | 1871 | | | | RPI2) | | | 1872 +---------+------------+----------+------------+----------+------------+ 1873 | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| 1874 | headers | | | (RPI1) | | (RH3, | 1875 | | | | | | RPI2) | 1876 +---------+------------+----------+------------+----------+------------+ 1877 | Re-added| -- | -- | -- | -- | -- | 1878 | headers | | | | | | 1879 +---------+------------+----------+------------+----------+------------+ 1880 | Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- | 1881 | headers | | (RPI1) | | (RPI2) | | 1882 +---------+------------+----------+------------+----------+------------+ 1883 |Untouched| -- | -- | -- | -- | -- | 1884 | headers | | | | | | 1885 +---------+------------+----------+------------+----------+------------+ 1887 Figure 19: Non-SM: Summary of the use of headers for RAL to RAL. 1888 IP6-in-IP6 refers to IPv6-in-IPv6. 1890 8.3.2. Non-SM: Example of Flow from RAL to RUL 1892 In this case the flow comprises: 1894 RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node) 1896 For example, a communication flow could be: Node F --> Node D --> 1897 Node B --> Node A (root) --> Node B --> Node E --> Node G 1899 6LR_ia are the intermediate routers from source to the root In this 1900 case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 1902 6LR_id are the intermediate routers from the root to the destination. 1903 In this case, "1 <= ia <= m", m is the number of the intermediate 1904 routers (6LRs). 1906 As in the previous case, the RAL (6LN) will insert a RPI (RPI_1) 1907 header which must be in an IPv6-in-IPv6 header addressed to the root 1908 so that the 6LBR can remove this RPI. The 6LBR will then insert an 1909 RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id 1910 (6LR_id = m). 1912 The Figure 20 shows the table that summarizes what headers are needed 1913 for this use case. 1915 +-----------+---------+---------+---------+---------+---------+------+ 1916 | Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL | 1917 | | src | | | | | dst | 1918 | | node | | | | | node | 1919 +-----------+---------+---------+---------+---------+---------+------+ 1920 | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1921 | headers | (RPI1) | | (RH3, | | | | 1922 | | | | RPI2) | | | | 1923 +-----------+---------+---------+---------+---------+---------+------+ 1924 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1925 | headers | | | (RPI1) | | (RH3, | | 1926 | | | | | | RPI2) | | 1927 +-----------+---------+---------+---------+---------+---------+------+ 1928 | Re-added | -- | -- | -- | -- | -- | -- | 1929 | headers | | | | | | | 1930 +-----------+---------+---------+---------+---------+---------+------+ 1931 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1932 | headers | | (RPI1) | | (RH3, | | | 1933 | | | | | RPI2) | | | 1934 +-----------+---------+---------+---------+---------+---------+------+ 1935 | Untouched | -- | -- | -- | -- | -- | -- | 1936 | headers | | | | | | | 1937 +-----------+---------+---------+---------+---------+---------+------+ 1939 Figure 20: Non-SM: Summary of the use of headers from RAL to RUL. 1941 8.3.3. Non-SM: Example of Flow from RUL to RAL 1943 In this case the flow comprises: 1945 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 1946 --> RAL dst (6LN) 1948 For example, a communication flow could be: Node G --> Node E --> 1949 Node B --> Node A (root) --> Node B --> Node E --> Node H 1951 6LR_ia are the intermediate routers from source to the root. In this 1952 case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 1954 6LR_id are the intermediate routers from the root to the destination. 1955 In this case, "1 <= ia <= m", m is the number of the intermediate 1956 routers (6LR). 1958 This scenario is mostly identical to the previous one. The RPI 1959 (RPI1) is added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 1960 header addressed to the root. The 6LBR will remove this RPI, and add 1961 it's own IPv6-in-IPv6 header containing an RH3 header and an RPI 1962 (RPI2). 1964 The Figure 21 shows the table that summarizes what headers are needed 1965 for this use case. 1967 +-----------+------+---------+---------+---------+---------+---------+ 1968 | Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL | 1969 | | src | | | | | dst | 1970 | | node | | | | | node | 1971 +-----------+------+---------+---------+---------+---------+---------+ 1972 | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1973 | headers | | (RPI1) | | (RH3, | | | 1974 | | | | | RPI2) | | | 1975 +-----------+------+---------+---------+---------+---------+---------+ 1976 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1977 | headers | | | | (RPI1) | | (RH3, | 1978 | | | | | | | RPI2) | 1979 +-----------+------+---------+---------+---------+---------+---------+ 1980 | Re-added | -- | | -- | -- | -- | -- | 1981 | headers | | | | | | | 1982 +-----------+------+---------+---------+---------+---------+---------+ 1983 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1984 | headers | | | (RPI1) | | (RH3, | | 1985 | | | | | | RPI2) | | 1986 +-----------+------+---------+---------+---------+---------+---------+ 1987 | Untouched | -- | | -- | -- | -- | -- | 1988 | headers | | | | | | | 1989 +-----------+------+---------+---------+---------+---------+---------+ 1991 Figure 21: Non-SM: Summary of the use of headers from RUL to RAL. 1993 8.3.4. Non-SM: Example of Flow from RUL to RUL 1995 In this case the flow comprises: 1997 RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id 1998 --> RUL (IPv6 dst node) 2000 For example, a communication flow could be: Node G --> Node E --> 2001 Node B --> Node A (root) --> Node C --> Node J 2003 6LR_ia are the intermediate routers from source to the root. In this 2004 case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 2005 6LR_id are the intermediate routers from the root to the destination. 2006 In this case, "1 <= ia <= m", m is the number of the intermediate 2007 routers (6LR). 2009 This scenario is the combination of the previous two cases. 2011 The Figure 22 shows the table that summarizes what headers are needed 2012 for this use case. 2014 +---------+------+-------+-------+---------+-------+---------+------+ 2015 | Header | RUL | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | RUL | 2016 | | src | | | | | | dst | 2017 | | node | | | | | | node | 2018 +---------+------+-------+-------+---------+-------+---------+------+ 2019 | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 2020 | headers | | (RPI1)| | (RH3, | | | | 2021 | | | | | RPI2) | | | | 2022 +---------+------+-------+-------+---------+-------+---------+------+ 2023 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 2024 | headers | | | | (RPI1) | | (RH3, | | 2025 | | | | | | | RPI2) | | 2026 +---------+------+-------+-------+---------+-------+---------+------+ 2027 | Re-added| -- | -- | -- | -- | -- | -- | -- | 2028 | headers | | | | | | | | 2029 +---------+------+-------+-------+---------+-------+---------+------+ 2030 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 2031 | headers | | | (RPI1)| | (RH3, | | | 2032 | | | | | | RPI2)| | | 2033 +---------+------+-------+-------+---------+-------+---------+------+ 2034 |Untouched| -- | -- | -- | -- | -- | -- | -- | 2035 | headers | | | | | | | | 2036 +---------+------+-------+-------+---------+-------+---------+------+ 2038 Figure 22: Non-SM: Summary of the use of headers from RUL to RUL 2040 9. Operational Considerations of supporting RUL-leaves 2042 Roughly half of the situations described in this document involve 2043 leaf ("host") nodes that do not speak RPL. These nodes fall into two 2044 further categories: ones that drop a packet that have RPI or RH3 2045 headers, and ones that continue to process a packet that has RPI and/ 2046 or RH3 headers. 2048 [RFC8200] provides for new rules that suggest that nodes that have 2049 not been configured (explicitly) to examine Hop-by-Hop headers, 2050 should ignore those headers, and continue processing the packet. 2051 Despite this, and despite the switch from 0x63 to 0x23, there may be 2052 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 2053 drop packets that continue to have RPL artifacts in them. In 2054 general, such hosts can not be easily supported in RPL LLNs. 2056 There are some specific cases where it is possible to remove the RPL 2057 artifacts prior to forwarding the packet to the leaf host. The 2058 critical thing is that the artifacts have been inserted by the RPL 2059 root inside an IPv6-in-IPv6 header, and that the header has been 2060 addressed to the 6LR immediately prior to the leaf node. In that 2061 case, in the process of removing the IPv6-in-IPv6 header, the 2062 artifacts can also be removed. 2064 The above case occurs whenever traffic originates from the outside 2065 the LLN (the "Internet" cases above), and non-storing mode is used. 2066 In non-storing mode, the RPL root knows the exact topology (as it 2067 must be create the RH3 header), and therefore knows what the 6LR 2068 prior to the leaf. For example, in Figure 5, node E is the 6LR prior 2069 to the leaf node G, or node C is the 6LR prior to the leaf node J. 2071 traffic originating from the RPL root (such as when the data 2072 collection system is co-located on the RPL root), does not require an 2073 IPv6-in-IPv6 header (in either mode), as the packet is originating at 2074 the root, and the root can insert the RPI and RH3 headers directly 2075 into the packet, as it is formed. Such a packet is slightly smaller, 2076 but only can be sent to nodes (whether RPL aware or not), that will 2077 tolerate the RPL artifacts. 2079 An operator that finds itself with a lot of traffic from the RPL root 2080 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 2081 if the leaf is not tolerant of the RPL artifacts. Such an operator 2082 could otherwise omit this unnecessary header if it was certain of the 2083 properties of the leaf. 2085 As storing mode can not know the final path of the traffic, 2086 intolerant (that drop packets with RPL artifacts) leaf nodes can not 2087 be supported. 2089 10. Operational considerations of introducing 0x23 2091 This section describes the operational considerations of introducing 2092 the new RPI Option Type of 0x23. 2094 During bootstrapping the node gets the DIO with the information of 2095 RPI Option Type, indicating the new RPI in the DODAG Configuration 2096 Option Flag. The DODAG root is in charge to configure the current 2097 network to the new value, through DIO messages and when all the nodes 2098 are set with the new value. The DODAG should change to a new DODAG 2099 version. In case of rebooting, the node does not remember the RPI 2100 Option Type. Thus, the DIO is sent with a flag indicating the new 2101 RPI Option Type. 2103 The DODAG Configuration option is contained in a RPL DIO message, 2104 which contains a unique DTSN counter. The leaf nodes respond to this 2105 message with DAO messages containing the same DTSN. This is a normal 2106 part of RPL routing; the RPL root therefore knows when the updated 2107 DODAG Configuration Option has been seen by all nodes. 2109 Before the migration happens, all the RPL-aware nodes should support 2110 both values . The migration procedure it is triggered when the DIO 2111 is sent with the flag indicating the new RPI Option Type. Namely, it 2112 remains at 0x63 until it is sure that the network is capable of 0x23, 2113 then it abruptly change to 0x23. This options allows to send packets 2114 to not-RPL nodes, which should ignore the option and continue 2115 processing the packets. 2117 In case that a node join to a network that only process 0x63, it 2118 would produce a flag day as was mentioned previously. Indicating the 2119 new RPI in the DODAG Configuration Option Flag is a way to avoid the 2120 flag day in a network. It is recommended that a network process both 2121 options to enable interoperability. 2123 11. IANA Considerations 2125 This document updates the registration made in [RFC6553] Destination 2126 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2127 Figure 23. 2129 +-------+-------------------+------------------------+---------- -+ 2130 | Hex | Binary Value | Description | Reference | 2131 + Value +-------------------+ + + 2132 | | act | chg | rest | | | 2133 +-------+-----+-----+-------+------------------------+------------+ 2134 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2135 +-------+-----+-----+-------+------------------------+------------+ 2136 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2137 | | | | | |[RFCXXXX](*)| 2138 +-------+-----+-----+-------+------------------------+------------+ 2140 Figure 23: Option Type in RPL Option.(*)represents this document 2142 DODAG Configuration option is updated as follows (Figure 24): 2144 +------------+-----------------+---------------+ 2145 | Bit number | Description | Reference | 2146 +------------+-----------------+---------------+ 2147 | 3 | RPI 0x23 enable | This document | 2148 +------------+-----------------+---------------+ 2150 Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- 2151 day. 2153 12. Security Considerations 2155 The security considerations covered in [RFC6553] and [RFC6554] apply 2156 when the packets are in the RPL Domain. 2158 The IPv6-in-IPv6 mechanism described in this document is much more 2159 limited than the general mechanism described in [RFC2473]. The 2160 willingness of each node in the LLN to decapsulate packets and 2161 forward them could be exploited by nodes to disguise the origin of an 2162 attack. 2164 While a typical LLN may be a very poor origin for attack traffic (as 2165 the networks tend to be very slow, and the nodes often have very low 2166 duty cycles) given enough nodes, they could still have a significant 2167 impact, particularly if attack is targeting another LLN. 2168 Additionally, some uses of RPL involve large backbone ISP scale 2169 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2170 equipped with multiple 100Gb/s interfaces. 2172 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2173 LLN as described above will make sure that any attack that is mounted 2174 must originate from compromised nodes within the LLN. The use of 2175 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2176 alert the operator to the existence of the attack, as well as drop 2177 the attack traffic. As the RPL network is typically numbered from a 2178 single prefix, which is itself assigned by RPL, BCP38 filtering 2179 involves a single prefix comparison and should be trivial to 2180 automatically configure. 2182 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2183 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2184 communications between a new Pledge and the Join Registrar/ 2185 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2186 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2187 the RPL root to do careful filtering: it occurs only when the Join 2188 Coordinator is not co-located inside the RPL root. 2190 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2191 only be by a node within the LLN on another node within the LLN. 2192 Such an attack could, of course, be done directly. An attack of this 2193 kind is meaningful only if the source addresses are either fake or if 2194 the point is to amplify return traffic. Such an attack, could also 2195 be done without the use of IPv6-in-IPv6 headers using forged source 2196 addresses. If the attack requires bi-directional communication, then 2197 IPv6-in-IPv6 provides no advantages. 2199 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2200 about creating security issues. In the security section of 2201 [RFC2473], it was suggested that tunnel entry and exit points can be 2202 secured, via "Use IPsec". This recommendation is not practical for 2203 RPL networks. [RFC5406] goes into some detail on what additional 2204 details would be needed in order to "Use IPsec". Use of ESP would 2205 prevent RFC8183 compression (compression must occur before 2206 encryption), and RFC8183 compression is lossy in a way that prevents 2207 use of AH. These are minor issues. The major issue is how to 2208 establish trust enough such that IKEv2 could be used. This would 2209 require a system of certificates to be present in every single node, 2210 including any Internet nodes that might need to communicate with the 2211 LLN. Thus, "Use IPsec" requires a global PKI in the general case. 2213 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2214 IPv6 headers would in the general case scale with the square of the 2215 number of nodes. This is a lot of resource for a constrained nodes 2216 on a constrained network. In the end, the IPsec tunnels would be 2217 providing only BCP38-like origin authentication! That is, IPsec 2218 provides a transitive guarantee to the tunnel exit point that the 2219 tunnel entry point did BCP38 on traffic going in. Just doing BCP38 2220 origin filtering at the entry and exit of the LLN provides a similar 2221 level amount of security without all the scaling and trust problems 2222 of using IPsec as RFC2473 suggested. IPsec is not recommended. 2224 An LLN with hostile nodes within it would not be protected against 2225 impersonation with the LLN by entry/exit filtering. 2227 The RH3 header usage described here can be abused in equivalent ways 2228 (to disguise the origin of traffic and attack other nodes) with an 2229 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2230 attacker's RH3 header will not be seen by the network until it 2231 reaches the end host, which will decapsulate it. An end-host should 2232 be suspicious about a RH3 header which has additional hops which have 2233 not yet been processed, and SHOULD ignore such a second RH3 header. 2235 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2236 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2237 will see the second RH3 header and MAY choose to discard the packet 2238 if the RH3 header has not been completely consumed. A consumed 2239 (inert) RH3 header could be present in a packet that flows from one 2240 LLN, crosses the Internet, and enters another LLN. As per the 2241 discussion in this document, such headers do not need to be removed. 2242 However, there is no case described in this document where an RH3 is 2243 inserted in a non-storing network on traffic that is leaving the LLN, 2244 but this document should not preclude such a future innovation. It 2245 should just be noted that an incoming RH3 must be fully consumed, or 2246 very carefully inspected. 2248 The RPI, if permitted to enter the LLN, could be used by an attacker 2249 to change the priority of a packet by selecting a different 2250 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2251 It could also be that not all nodes are reachable in an LLN using the 2252 default instanceID, but a change of instanceID would permit an 2253 attacker to bypass such filtering. Like the RH3, a RPI is to be 2254 inserted by the RPL root on traffic entering the LLN by first 2255 inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will 2256 not be seen by the network. Upon reaching the destination node the 2257 RPI has no further meaning and is just skipped; the presence of a 2258 second RPI will have no meaning to the end node as the packet has 2259 already been identified as being at it's final destination. 2261 The RH3 and RPIs could be abused by an attacker inside of the network 2262 to route packets on non-obvious ways, perhaps eluding observation. 2263 This usage is in fact part of [RFC6997] and can not be restricted at 2264 all. This is a feature, not a bug. 2266 [RFC7416] deals with many other threats to LLNs not directly related 2267 to the use of IPv6-in-IPv6 headers, and this document does not change 2268 that analysis. 2270 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2271 attack on another part of the LLN, while disguising the origin of the 2272 attack. The mechanism can even be abused to make it appear that the 2273 attack is coming from outside the LLN, and unless countered, this 2274 could be used to mount a Distributed Denial Of Service attack upon 2275 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2276 such attacks already seen in the real world. 2278 If an attack comes from inside of LLN, it can be alleviated with SAVI 2279 (Source Address Validation Improvement) using [RFC8505] with 2280 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2281 traffic with an address that is not registered, and the registration 2282 process checks for topological correctness. Notice that there is an 2283 L2 authentication in most of the cases. If an attack comes from 2284 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2285 but by construction, the RH3 can typically only address nodes within 2286 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2287 considered an attack (see RFC6554, section 3). 2289 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2290 through the RPL root to perform this attack. To counter, the RPL 2291 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2292 simpler solution), or it SHOULD walk the IP header extension chain 2293 until it can inspect the upper-layer-payload as described in 2294 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2295 on the source addresses of all IP headers that it examines in both 2296 directions. 2298 Note: there are some situations where a prefix will spread across 2299 multiple LLNs via mechanisms such as the one described in 2300 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2301 needs to take this into account, either by exchanging detailed 2302 routing information on each LLN, or by moving the BCP38 filtering 2303 further towards the Internet, so that the details of the multiple 2304 LLNs do not matter. 2306 13. Acknowledgments 2308 This work is done thanks to the grant given by the StandICT.eu 2309 project. 2311 A special BIG thanks to C. M. Heard for the help with the 2312 Section 4. Much of the redaction in that section is based on his 2313 comments. 2315 Additionally, the authors would like to acknowledge the review, 2316 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2317 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Benjamin Kaduk, 2318 Matthias Kovatsch, Charlie Perkins, Alvaro Retana, Peter van der 2319 Stok, Xavier Vilajosana, Eric Vyncke and Thomas Watteyne. 2321 14. References 2323 14.1. Normative References 2325 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2326 Defeating Denial of Service Attacks which employ IP Source 2327 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2328 May 2000, . 2330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2331 Requirement Levels", BCP 14, RFC 2119, 2332 DOI 10.17487/RFC2119, March 1997, 2333 . 2335 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2336 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2337 2010, . 2339 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2340 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2341 DOI 10.17487/RFC6282, September 2011, 2342 . 2344 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2345 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2346 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2347 Low-Power and Lossy Networks", RFC 6550, 2348 DOI 10.17487/RFC6550, March 2012, 2349 . 2351 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2352 Power and Lossy Networks (RPL) Option for Carrying RPL 2353 Information in Data-Plane Datagrams", RFC 6553, 2354 DOI 10.17487/RFC6553, March 2012, 2355 . 2357 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2358 Routing Header for Source Routes with the Routing Protocol 2359 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2360 DOI 10.17487/RFC6554, March 2012, 2361 . 2363 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2364 of IPv6 Extension Headers", RFC 7045, 2365 DOI 10.17487/RFC7045, December 2013, 2366 . 2368 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2369 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2370 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2371 . 2373 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2374 "IPv6 over Low-Power Wireless Personal Area Network 2375 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2376 April 2017, . 2378 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2379 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2380 May 2017, . 2382 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2383 (IPv6) Specification", STD 86, RFC 8200, 2384 DOI 10.17487/RFC8200, July 2017, 2385 . 2387 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2388 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2389 January 2019, . 2391 14.2. Informative References 2393 [DDOS-KREBS] 2394 Goodin, D., "Record-breaking DDoS reportedly delivered by 2395 >145k hacked cameras", September 2016, 2396 . 2399 [I-D.ietf-6lo-ap-nd] 2400 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2401 "Address Protected Neighbor Discovery for Low-power and 2402 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2403 progress), April 2019. 2405 [I-D.ietf-6lo-backbone-router] 2406 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2407 Backbone Router", draft-ietf-6lo-backbone-router-13 (work 2408 in progress), September 2019. 2410 [I-D.ietf-6tisch-dtsecurity-secure-join] 2411 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2412 6tisch-dtsecurity-secure-join-01 (work in progress), 2413 February 2017. 2415 [I-D.ietf-anima-autonomic-control-plane] 2416 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2417 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2418 plane-21 (work in progress), November 2019. 2420 [I-D.ietf-anima-bootstrapping-keyinfra] 2421 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2422 and K. Watsen, "Bootstrapping Remote Secure Key 2423 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2424 keyinfra-30 (work in progress), November 2019. 2426 [I-D.ietf-intarea-tunnels] 2427 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2428 Architecture", draft-ietf-intarea-tunnels-10 (work in 2429 progress), September 2019. 2431 [I-D.ietf-roll-unaware-leaves] 2432 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 2433 draft-ietf-roll-unaware-leaves-07 (work in progress), 2434 November 2019. 2436 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2437 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2438 December 1998, . 2440 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2441 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2442 December 1998, . 2444 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2445 Control Message Protocol (ICMPv6) for the Internet 2446 Protocol Version 6 (IPv6) Specification", STD 89, 2447 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2448 . 2450 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2451 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2452 February 2009, . 2454 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2455 "IPv6 Flow Label Specification", RFC 6437, 2456 DOI 10.17487/RFC6437, November 2011, 2457 . 2459 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2460 Bormann, "Neighbor Discovery Optimization for IPv6 over 2461 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2462 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2463 . 2465 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2466 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2467 in Low-Power and Lossy Networks", RFC 6997, 2468 DOI 10.17487/RFC6997, August 2013, 2469 . 2471 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2472 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2473 2014, . 2475 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2476 and M. Richardson, Ed., "A Security Threat Analysis for 2477 the Routing Protocol for Low-Power and Lossy Networks 2478 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2479 . 2481 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2482 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2483 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2484 May 2017, . 2486 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2487 Perkins, "Registration Extensions for IPv6 over Low-Power 2488 Wireless Personal Area Network (6LoWPAN) Neighbor 2489 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2490 . 2492 Authors' Addresses 2494 Maria Ines Robles 2495 Aalto University, Finland 2497 Email: mariainesrobles@gmail.com 2499 Michael C. Richardson 2500 Sandelman Software Works 2501 470 Dawson Avenue 2502 Ottawa, ON K1Z 5V7 2503 CA 2505 Email: mcr+ietf@sandelman.ca 2506 URI: http://www.sandelman.ca/mcr/ 2508 Pascal Thubert 2509 Cisco Systems, Inc 2510 Building D 2511 45 Allee des Ormes - BP1200 2512 MOUGINS - Sophia Antipolis 06254 2513 FRANCE 2515 Phone: +33 497 23 26 34 2516 Email: pthubert@cisco.com